termsOfUse is insufficiently specified

[msporny]

@TallTed wrote:

I continue to believe that termsOfUse (whether in VC or VP) is insufficiently specified, as there has been no discussion of its possible values, which are clearly meant/desired to be processed by machine — not human — which can only happen if those potential values are explicitly defined, or are at least restricted to URIs which dereference to machine processable details. In other words, termsOfUse MUST be defined to not permit human-language obligations/permissions/prohibitions.

Originally posted by @TallTed in #1004 (comment)

[msporny]

We had meant termsOfUse to be machine processable, which is why we based usage on the Open Digital Rights Language. We should revisit the discussion given that so much time has passed, many of the people that participated in that discussion have moved on, and ODRL didn't get the uptake we were expecting.

[David-Chadwick]

ODRL is not the only technology that uses this type of processing. Access control systems such as XACML also have similar concepts and machinery that automatically process obligations and prohibitions. But in the VCDM we should not be expected to define any machine processable language. This will be done by applications that use the VCDM. Rather the VCDM should document the generic intention of this property. I think the current text expresses this generic intention rather well, but we can wordsmith it if the general intention is not articulated well enough for some of us.

[iherman]

The issue was discussed in a meeting on 2023-04-04

• no resolutions were taken

View the transcript

1.10. termsOfUse is insufficiently specified (issue vc-data-model#1010)

See github issue vc-data-model#1010.

Kristina Yasuda: About termsOfUse. Any volunteers?.

Markus Sabadello: Phil-ASU: I'm interested in this. Statement of interest by the individual that the credential should be used in a particular way. This is a clear indiciation to the receiving person. If they choose to not follow that, it could invoke a governance process to deal with a violation..

David Chadwick: I'm interested in this. We are already using this in real life..
… Tangentially this is related to nonTransferable we discussed earlier..

Kristina Yasuda: Do you both want to be assigned?.

Markus Sabadello: Phil-ASU: Yes, both is good..

Kerri Lemoie: In what order are we sorting the list as we go through them?.

Ted Thibodeau Jr.: Kerri_Lemoie -- least-recently-updated. see https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc+no%3Aassignee.

Kerri Lemoie: Thanks @TallTed.

[hendersonweb]

Hello everyone, Was there any decision taken based on the usage of termsOfUse. Because in the v1 VC Data model it is stated that this attribute is at risk. Because in Gaia-X Trust Concept for Federations, it has been proposed to verify the trust of federations. And TRAIN Infrastructure has also demonstrated how this can be used to verify the institutional trust of the Issuer. So it would be good to keep this attribute both for VC and VP.

[OR13]

Its marked at risk...

• https://w3c.github.io/vc-data-model/#terms-of-use
• https://w3c.github.io/vc-data-model/#reserved-extension-points

Its also in the extensions list... It should be removed from the spec, if there is no provable interop on it.

[iherman]

The issue was discussed in a meeting on 2023-06-28

• no resolutions were taken

View the transcript

2.3. termsOfUse is insufficiently specified (issue vc-data-model#1010)

See github issue vc-data-model#1010.

Brent Zundel: #1010 terms of use insufficiently specified. This may be overtaken by events. Currently at re: ToU is the group decided if there aren't two independent implementations they get moved to the extensions list (reserved terms table).
… already marked at risk. Will be closed in the event that these sections are removed. Is that correct?

Manu Sporny: you're more or less right as far as I can tell :).

Brent Zundel: marked before CR but not much work until we have to decide. If there is an implementation, great!

[iherman]

The issue was discussed in a meeting on 2023-07-26

• no resolutions were taken

View the transcript

3.1. termsOfUse is insufficiently specified (issue vc-data-model#1010)

See github issue vc-data-model#1010.

Brent Zundel: 1010 was raised by manu and assigned to pdl_asu.

Phillip Long: There was a conversation when the issue was created, but not much discussion since then.

Manu Sporny: Terms of Use is labelled as 'at risk', so it will be removed unless work is done on it.

Joe Andrieu: I don't understand who is bound to the terms of use in our three-party system.

Brent Zundel: +1 Joe, all that you say indicates we really need to see a spec.

Joe Andrieu: I think it's far more complicated than anything we've done so far, so I don't think we're ready. However I think we should keep it reserved.

Ted Thibodeau Jr.: I think it is OK to go into CR with only one implementation.

Brent Zundel: It sounds like the section of the specification to do with Terms of Use ought to be removed, because there is nothing concrete to describe. Leaving it in the reserved terms is best while we experiment.

Manu Sporny: +1 to brent's summary, that sounded accurate to me.

Joe Andrieu: For all the terms that we have reserved, we should explain what we intend to use them for.

Manu Sporny: https://w3c.github.io/vc-data-model/#reserved-extension-points.

Manu Sporny: We can use the description from 1.1 if it gets removed during CR.

[hendersonweb]

Its marked at risk...

• https://w3c.github.io/vc-data-model/#terms-of-use
• https://w3c.github.io/vc-data-model/#reserved-extension-points

Its also in the extensions list... It should be removed from the spec, if there is no provable interop on it.

In gaia-x it has been used to establish trust across cross-domains and also in ebsi it has also been used to reference the trust of the issuer. So we have two potential implementations on it.

[TallTed]

Direct link to termsOfUse definition in EBSI Verifiable Attestations.

@hendersonweb — It would be great if you could help with a pointer to the gaia-x implementation!

[hendersonweb]

@TallTed The Gaia-x trust concept development is in process. The following link will provide details.

[TallTed]

@hendersonweb -- That page is troubling.

Every VC that is issued by an entity that claims to be in a certain Trust Framework must contain a standard Terms of Use property (according to W3C Verifiable Credentials Data Model 1.0). The Terms of Use contains the DNS names of the trust framework(s) that the issuer claims to be a member of. For this, there must be defined at least one “trustScheme”, as in the following example: "trustScheme": ["example.federation1.com", "partners.federation2.de"].

The Terms of Use property was never required by the VCDM1.0, nor did it specify "DNS names of trust frameworks" as values.

Do you have contacts in that group? It would likely benefit all of them and us if someone from that group could join in our work, here.

[hendersonweb]

@TallTed ya your right exactly. VCDM1.0 doesn't specify that termsofUse have to be used to specify dns names. But TRAIN based on this paper provides details how trust can be established using termsofUse object. Since gaia-x federation services is planning to use TRAIN as trust implementation model it is required to include DNS names on termsOfUse. Does this help?

I'm also a contributor in gaia-x icam working group but i can also inform some other colleagues so they could also plan to join the discussion.

[OR13]

#1010 (comment)

Lets be careful claiming "termsOfUse" aka "https://www.w3.org/2018/credentials#termsOfUse" is being used in an interoperable manner ...

• https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L81

What kinds of tests will we need to add to ensure that "VerifiableAccreditation" is interpreted consistently?

Is "VerifiableAccreditation" a type like "JsonSchema" or "StatusList2021Entry" which is understood in an interoperable way today?

Should we bundle it in the v2 context? like we are doing for credentialSchema and credentialStatus predicates, so that termsOfUse has at least 1 usable RDF Class that comes pre installed?

[TallTed]

Regrettably, "that paper", "A novel approach to establish trust in verifiable credential issuers in Self-sovereign identity ecosystems using TRAIN", was written to use a property which was defined and designed differently in the VCDM than the definition and use set out in that paper.

The VCDM was built with extensibility in mind, but this extensibility is designed to use both WG predefined extension points (typically, reserved property names) in specific ways and implementer-defined properties in less-specific ways. It is not meant to repurpose defined properties to hold values that are entirely distinct from the values we have defined those properties to hold.

Certainly, termsOfUse (which is typically an issuer's restriction on a recipients use of something) does not translate to anything about trust (translating into recipients' trust in issuers and their issued data) in my mental dictionaries and models, and I daresay the same will be true for most participants in the relevant W3C Working and Community Groups. I am sad to see that it was (and perhaps still is) apparently not true for David Chadwick, a listed author, who has also been a participant in the relevant WGs & CGs.

Unexpected things will happen if that paper's designs are put into broad use, and its users run into users of the VCDM as designed and specified. I can make no predictions of those things, aside from hoping there will be a lot of processes flagging errors and aborting their activities when unexpected values are found in termsOfUse, etc.

[David-Chadwick]

@TallTed Perhaps you should re-read the definition of ToU from the v1 DM. I have copied it here for you

"Terms of use can be utilized by an issuer or a holder to communicate the terms under which a verifiable credential or verifiable presentation was issued."

In the TRAIN case, the issuer is stating the trust framework terms and conditions under which the VC was issued, by referring to the trusted authority by its DNS name.

And again from the v1 DM:

"The value of the termsOfUse property MUST specify one or more terms of use policies under which the creator issued the credential or presentation. If the recipient (a holder or verifier) is not willing to adhere to the specified terms of use, then they do so on their own responsibility and might incur legal liability if they violate the stated terms of use. Each termsOfUse value MUST specify its type, for example, IssuerPolicy, and MAY specify its instance id. The precise contents of each term of use is determined by the specific termsOfUse type definition. "

In the TRAIN case, the issuer issued the VC under the policy specified by the trust scheme operator according to the type "https://train.trust-scheme.de/info". You need to consult the TRAIN documentation to understand the precise semantics of this URL.

No unexpected things will happen, because a verifier will either understand the type "https://train.trust-scheme.de/info" and know how to proceed, or will not understand the type and therefore will not know the semantics of this particular terms of use. This is the case for all ToUs (and indeed for all extension points - the verifier must understand the type of the extension point or it cannot process the extension).

[TallTed]

@David-Chadwick -- Please explain how a recipient of a VC with a termsOfUse property value of a domain name may look up what the definition of that policy is, in order to determine how they should proceed, especially mechanically, but also manually.

Remember -- The holder of a VC may present it to anyone as verifier. There is no requirement that such a recipient verifier be part of the TRAIN ecosystem, and I see no clear way for such a verifier to discover upon receipt of a TRAIN-focused VC that they are expected to be such.

[David-Chadwick]

The information about the trust scheme, its policies and procedures, are pointed to from the ETSI standard trust list created by the trusted authority of the particular domain name. And the URL of this trust list can be automatically obtained from the DNS. (And there are possibly open source libraries that know how to process ETSI standard trust lists since they are well used in Europe, being part of the EIDAS standards). Of course there is a certain amount of background knowledge that is needed in order to understand what is an ETSI standard trust list, and how TRAIN uses this. (In the same way that anyone receiving a VC needs to have a certain amount of background knowledge about JSON-LD, the VC-DM, cryptographic proofs etc.). But once an implementation has this knowledge built into it, then it can look at the ToU type, see that it understands it, then obtain the DNS name of the trust scheme operator, and see if it trusts this particular operator. If it does it can then automatically determine if the VC issuer is trusted or not. We have successfully implemented the entire scheme, so that a verifier that has TRAIN built into it, can determine globally which issuers are trusted.
I suggest you start by reading the papers that have been published about TRAIN and ETSI standard trust lists.

[TallTed]

"Anyone receiving a (JSON-LD) VC" should be able to "follow their nose" through standard exploration of self-documenting RDF. I do not see this being possible for the ETSI, EIDAS, TRAIN setup discussed here.

I suggest you start by reading the papers that have been published about TRAIN and ETSI standard trust lists.

Your suggestion is actually that I start by researching what those papers are, and then seek out where I may be able to freely read and/or download them, and then read them.

I submit that requiring me (or any recipient of a TRAIN-based VC) to do all that is in itself an argument in support of my prior points.

[David-Chadwick]

Getting back to the nub of this issue, it is about having a ToU that is machine processable. The current TRAIN ToU is precisely that. The verifier code for a verifier that supports TRAIN simply needs to do the following:

1. Check if the ToU type is recognised and if it is, jump to the code that processes this recognised type.
2. If no ToU type is set to "https://train.trust-scheme.de/info", jump to Not Trusted.
3. ToU is set to "https://train.trust-scheme.de/info".
4. Check that any of the listed DNS names are in its configured list of trusted authorities.
5. If there is a trusted authority, then call the TRAIN open source API to ask it if the issuer is trusted by this trusted scheme authority.
6. The TRAIN API will return trusted or not trusted (see the API spec for more details of the call parameters and responses). If trusted, continue processing the VC. If not trusted jump to Not Trusted.
7. If there is no recognised trusted authority, jump to Not trusted.
   Not Trusted
   A strict verifier that only accepts VCs from trusted issuers will discard the VC.
   A permissive verifier will ask the human operator (if there is one) if they want to continue processing a VC from an untrusted issuer.

[iherman]

The issue was discussed in a meeting on 2023-08-30

• no resolutions were taken

View the transcript

4.7. termsOfUse is insufficiently specified (issue vc-data-model#1010)

See github issue vc-data-model#1010.

Brent Zundel: termsOfUse insufficiently specified.
… can anyone give us an update.

David Chadwick: I think we got to the text in the space should be generic enough to allow anyone to specify their own terms of use with their own URI.
… and for testing we want something more than generic URI.
… we want specific URI for the type, which we can actually test for.
… I think we're at this state now.
… I think we can now write specific tests with specific URIs and we could have different implementations that understand that type and can process it.

Joe Andrieu: pl-asu: I think David said it well.

David Chadwick: the issue was that we needed something machine processable and not just a reference to a description.
… now we have a way to test out David's idea.

Manu Sporny: I'm confused about where we are on this topic.

Brent Zundel: +1 to being confused.

Manu Sporny: we made ... we had a consensus that the reserve term is going to be removed if we don't have a spec with two implementations by end of CR.
… the other way to do it is that we have multiple implementations and there is functional interoperability.
… where are we as a group. have we decided on one way or another.

Orie Steele: +1 manu.

Sebastian Crane: I was going to propose something complicated, but in the interest of time, I'll yield to David.

Manu Sporny: to be clear, I'm fine w/ either way forward... we just need to pick a direction. :) -- the first one is more stringent than the second.

David Chadwick: manu didn't quite catch what I said. There will be two implementations that are interoperable.

Manu Sporny: great, thanks DavidC -- that makes things easy.

---

[MizukiSonoko]

Sorry for interrupting to discussion.

I am the maintainer of "Precondition Policy" and added spec to the Specification of TermOfUse.
https://w3c.github.io/vc-specs-dir/#terms-of-use

As my understanding, currently we are debating whether the ToU should be removed.
If the issue is whether ToU that is machine processable or not, I believe Precondition Policy is service independent and machine verifiable.

In addition, if ToU is deleted, how should a requirement like the Precondition Policy (a requirement to Verifiy VCs with unclear precondition and stipulate liability for problems caused by them) be realized?

[David-Chadwick]

The first paragraph of terms of use is OK as is, namely

Terms of use can be utilized by an issuer or a holder to communicate the terms under which a verifiable credential or verifiable presentation was issued. The issuer places their terms of use inside the verifiable credential . The holder places their terms of use inside a verifiable presentation . This specification defines a termsOfUse property for expressing terms of use information.

It is suggested that following paragraph is modified along the following lines to better agree with the initial paragraph.

Examples for the value of the termsOfUse property may be to tell the verifier:
i) what actions it is required to perform (an obligation ), not allowed to perform (a prohibition ), or allowed to perform (a permission ) if it is to accept the verifiable credential or verifiable presentation;
ii) what procedures were used in issuing the verifiable credential, for example, by providing a pointer to the location where these procedures can be found, or naming the standard that defines these procedures.

[iherman]

The issue was discussed in a meeting on 2023-09-14

• no resolutions were taken

View the transcript

5.3. termsOfUse is insufficiently specified (issue vc-data-model#1010)

See github issue vc-data-model#1010.

David Chadwick: The Terms Of Use should be automatically processable, and it should be more general. I've added some draft text. If there is agreement on that, I'll create a PR.

Manu Sporny: seabass: I know I haven't done background reading on this... would like to discuss w/ DavidC on this topic.

Manu Sporny: DavidC: Waiting on hearing more from you.

Brent Zundel: We'll look forward to feedback, and move on now.

[MizukiSonoko]

I agree

Examples for the value of the termsOfUse property may be to tell the verifier:
i) what actions it is required to perform (an obligation ), not allowed to perform (a prohibition ), or allowed to perform (a permission ) if it is to accept the verifiable credential or verifiable presentation;
ii) what procedures were used in issuing the verifiable credential, for example, by providing a pointer to the location where these procedures can be found, or naming the standard that defines these procedures.

As a suggestion
How about clearly stating what the responsibility will be if a verifier neglects they duties or does something that is prohibited, and to what extent the Issuer will cover any damages that may arise?

i) what actions it is required to perform (an obligation )
ii) what actions it is not allowed to perform (a prohibition)
iii) what actions it is allowed to perform (a permission)
and
iv) what extent the Issuer will cover any damages that may arise (a disclaimer)

[David-Chadwick]

@MizukiSonoko I don't think that disclaimers can be automatically processed by verifiers, although they could be displayed to a human user as information. Given that my proposed revised text is only giving examples of terms of use, we do not need to elaborate it any further (unless you have a different class of example that could be added to the list)

[MizukiSonoko]

@David-Chadwick

Sorry, the name (disclaimer) was not good word.
My assumption is that this is an action taken when not good situation,
such as when an obligation is not fulfilled, or when a prohibition is performed.
so verifiers can process automatically
If there is a prohibition or obligation, I don't think it will be effective unless there is a clause for when it is broken.

[iherman]

The issue was discussed in a meeting on 2023-09-26

• no resolutions were taken

View the transcript

2.2. termsOfUse is insufficiently specified (issue vc-data-model#1010)

See github issue vc-data-model#1010.

Phillip Long: We don't have David but he said something about a use case in the EU and another person added something into this discussion around obligations around steps a processor must take.
… David modified that slightly, that's where we stand at the moment. He did list a set of steps that would be appropriate to follow with one thumbs up -- that's where it sits.
… I don't know if it's sufficiently specified with that comment and Mizuki's comment.

Kristina Yasuda: Is there sufficient interest from the WG to work on this?

Phillip Long: David seemed very interested and the effort from TRAIN being part of it.
… Ted, if you have something to add that would be great.

Ted Thibodeau Jr.: I don't have a lot to add, but David is enthusiastic -- we could do a lot more on this topic and a single implementation is insufficient, I don't think David's been involved with two.

Manu Sporny: Given the amount of work that has gone into it here, and that's not much, I hate to say it, I don't think it will survive. I know that Isaac Henderson, who worked on the TRAIN stuff used this extension point. I think two independent implementations was the bar ... if TRAIN has that, we can keep it, but if not, by the end of CR, it gets cut.
… The people that want to see it happen have to step up with two independent implementations during CR.

Kristina Yasuda: I think even before two independent implementations, the issue here is that "what" to implement is underspecified. Unless we better define terms of use itself, I don't think we can even ask for implementations.
… If there are no objections ... I would do pending close and see if anyone can do a PR within a week or so.

Manu Sporny: https://w3c.github.io/vc-data-model/#terms-of-use.

Manu Sporny: So I think we have people claiming it was specified well enough for them to write a spec and do implementations for TRAIN. I'm concerned about closing it, issue 1010 is in the spec now under terms of use and if we close it ... well, we still have it marked as a feature at risk. It feels we need an issue to track it.
… That's my concern, tracking its status.

Dmitri Zagidulin: I was just going to say, in regard terms of use being insufficiently specified that won't be enough ... but with other properties it's been sufficient for others to find it useful to create implementations.
… A lot of our VC properties are loosely defined, maybe just having implementations is sufficient ... I'm not sure?

Kristina Yasuda: You're not sure the property is underspecified?

Dmitri Zagidulin: No, I'm not sure we don't have this same situation with other properties.

Ted Thibodeau Jr.: The degree to which this is underspecified, I think this is greater than most if not all others.
… The idea that is expressed for terms of use was that it was going to somehow be technologically enforceable and it was going to be clear enough for humans to work with.
… And with it being a complete hand wave as it stands, I don't think it even requires that it be a URI. That would make it at least self-describing and systems have to be able to do something with it or pass the information back to the human operator. That's not here yet.
… The TRAIN project, to the extent they've worked with it, I'm afraid have followed David down the road and what they did will work within their system but I don't think they have a spec that others could use to interoperate with them.

Kristina Yasuda: If the WG agrees with Ted that terms of use as it is now is underspecified, I think I do -- either we work on it until it's well defined or we have to end up removing it.
… I think the question is: Do we work on it to define it better or do we remove it?

Manu Sporny: Where terms of use came from ... is that there was another W3C WG that was doing open digital rights -- and it would allow machine processable terms of uses, etc. and that spec is arguable dead now.
… We built terms of use to work on top of ODRL and that ended up not being a thing. The only thing that could save this is the TRAIN work -- and with everything else in the WG, I don't see anyone working enough on it to ensure it survives.
… It doesn't seem we have people committing to fully specify it. I'm a bit in favor of removing it at this point for that reason.

Kristina Yasuda: Ok, moving on... but we can't close it until there is a PR to remove it or a PR to build up on it.
… I will do a PR to remove it from the VCDM and we'll see how that goes.

Manu Sporny: +0.5 on PR to remove :).

Manu Sporny: (noting that there will have to be a counter-PR to keep it in the spec).

Dmitri Zagidulin: will it still be on the 'reserved' list?

Dmitri Zagidulin: if removed?

Manu Sporny: yes, it should be reserved if removed...

Manu Sporny: (that's what the current issue text says).

Kristina Yasuda: Yes, I will do a PR to remove it and move it to the reserved list, thank you, everyone.

[hendersonweb]

@msporny I would like to have clarification on two independent implementations. Does it mean TRAIN with termsofUse being used in different use cases and projects? or termsofUse being used in TRAIN and another implmentation like EBSI?

[iherman]

@msporny I would like to have clarification on two independent implementations. Does it mean TRAIN with termsofUse being used in different use cases and projects? or termsofUse being used in TRAIN and another implmentation like EBSI?

The latter.

[David-Chadwick]

This has been addressed in PR #1295

[David-Chadwick]

p.s. there are 3 independent implementations of the EBSI TOU, by walt.id, igrant.io, bc gov.
https://walt.id/ebsi
https://igrant.io/ebsi.html
https://www.bcdiploma.com/en/blog/ebsi-verifiable-credentials

[lalc]

p.s. there are 3 independent implementations of the EBSI TOU, by walt.id, igrant.io, bc gov. https://walt.id/ebsi https://igrant.io/ebsi.html https://www.bcdiploma.com/en/blog/ebsi-verifiable-credentials

Note that there are more usecases than ESSPASS and diploma (Labour cards) that uses it today. Also all EBSI wallets, i believe support it. Full list is here: https://ec.europa.eu/digital-building-blocks/wikis/display/EBSI/Conformant+wallets

[Sakurann]

it was pointed out in #1285.

5.6 Terms of Use

The note here talks about delegating a verifiable credential, but that's the only mention of delegating in the document. What's it mean?

[Sakurann]

I would not be comfortable closing this issue without addressing this question.

[lineko]

Suggestion to edit the AT RISK notice:

https://w3c.github.io/vc-data-model/#terms-of-use

Existing text:

This feature is at risk and will be removed from the specification if at least two independent, interoperable implementations are not demonstrated for a single extension type by the end of the Candidate Recommendation Phase.

Suggested edit:
This feature is at risk and will be removed from the specification unless at least two independent, interoperable implementations are demonstrated for a single extension type by the end of the Candidate Recommendation Phase.

[David-Chadwick]

Concerning the term 'delegating', it occurred twice in the VCDMv2, once in the ToU text and once in the trust model section. I have now removed it from the ToU section so that it only occurs in the trust model section.

[alenhorvat]

Hi. With two other projects, we're discussing demonstrating the use of termsOfUse. Is there a deadline?
The same applies to the "evidence" claim.

[msporny]

@alenhorvat wrote:

Hi. With two other projects, we're discussing demonstrating the use of termsOfUse. Is there a deadline? The same applies to the "evidence" claim.

The "deadline" is "by the end of the Candidate Recommendation period", which we haven't even entered yet... but plan to enter before the end of the year. We expect the Candidate Recommendation period to last until March/April 2024.

[clehner]

I think at some point(s) processing should abort if the type of termsOfUse is not recognized; since no one can agree to terms of use without understanding them. I am not sure if such processing (understanding/agreement/use – "consent") is part of algorithms/processes in this specification (I guess not comparison/validation/verification of credentials, or determination of holder/subject relationship/identity) but it is implied in this section that use limits are expected to apply to verifiers and holders. (my comment/opinion as implementer and former invited expert)

[TallTed]

[@clehner] I think at some point(s) processing should abort if the type of termsOfUse is not recognized; since no one can agree to terms of use without understanding them.

I think this falls into business logic, and is thus out of scope for these documents. That said, we could probably include such an advisory to verifiers. I would ask for draft text to help speed that along, but I guess you're no longer appropriately affiliated as "implementer and former invited expert".

[iherman]

The issue was discussed in a meeting on 2023-11-01

• no resolutions were taken

View the transcript

2.6. termsOfUse is insufficiently specified (issue vc-data-model#1010)

See github issue vc-data-model#1010.

See github pull request vc-data-model#1295.

Brent Zundel: may just need a has-PR label. My understanding is it has a PR.
… Question for the group is, Does PR 1295 address this issue?

Manu Sporny: I don't think it does because of Kristina's comment.

Manu Sporny: Kristina is pointing out that there remains an issue: #1010 (comment).

Manu Sporny: The note talks about delegating a credential. That is the only mention of delegation in the document. What does this mean in terms of use. David would have to address this in the PR and I don't think he addresses it.

Phillip Long: I don't recall delegation being relevant to this PR.

Brent Zundel: I think it the concern is relevant. Its currently assigned to you, david and Kristina. Question is what action is going to be taken to address that concern.

David Chadwick: There is something wrong with the timing. Missed yesterdays.

Ivan Herman: There are changes with the clock.

David Chadwick: Apologize for being late. On terms of use, I did put changes in this morning to address all of Ted concerns except one which we should discuss. Regarding delegation, I removed from the terms of use, so there is no mention now.

Brent Zundel: That answers the question. This issue is now addressed fully by PR 1295.
… Can we jump back to 1295 and get to a point to merge this.
… David, can you point to the changes requested by TallTed that you did not accept.

David Chadwick: He added a big long paragraph about relationship between issuers and verifiers. I disagreed with this. The whole point is that the verifier can get an credential from an issues, but the trusted third party can vouch for it. So I think the text was not correct.

Ted Thibodeau Jr.: On this particular sentence, its editorial and advisory text, so it doesn't need in depth processing. However the explanation just given is the minimum needed. That is approximately what I had added. I dont think we will get this processed through oral conversation. I did respond to the latest change to the PR this morning.
… There were numerous editorial changes. The line before my modification said the terms of use property should be automatically processed by the verifier. But there is no language to describe how. Its just insufficient.

Joe Andrieu: +1 for removing automated requirement.

Manu Sporny: +1 to remove the automated requirement.

David Chadwick: Im happy to remove that sentence because we dont have this language around other properties. Its implicit in all the properties.

Ted Thibodeau Jr.: Unless we are expecting humans to process, the intent is for automated processing.

David Chadwick: +1 JoeAndrieu

Ted Thibodeau Jr.: also in my addition: "Future enhancements of this extension may include defining values and/or structures of termsOfUse property values such that any verifier may understand termsOfUse property values without prior relationship or communication with the issuer.".

Phillip Long: +1 to the type telling you what is or is not automatable. And +1 to remove the automated statement.

Ted Thibodeau Jr.: TermsOfUse being an extension point makes it "not like all the other properties", it's only "like all the other extension points".

Manu Sporny: +1 to Joe. We should remove the statement. I think we do intend this to be automatically processable, we just don't have an example today. Saying we should and not providing a mechanism is problematic. Lets just stay silent.

Dmitri Zagidulin: Similar to what manu said. This is not about whether the field should be manual or automatic. This is an extension point so the processing should be part of the extension spec. Not the main spec.

David Chadwick: We already implemented automatic processing of the ToU in the NGI Atlantic project.

Brent Zundel: thanks for involvement.

[msporny]

PR #1295 has been merged, which addresses the original issue, and which removed the "delegation" language concern raised in #1010 (comment). Closing.