removes mention of termsOfUse with verifiable presentations

[kdenhartog]

Since the verifiable presentation term context did not include the property the solution we've ended up on is to remove this portion
of the text from the current specification and it will be readded back in in Version 2 when we can update the contexts.

---

Preview | Diff

[kdenhartog]

fixes issue #776

[brentzundel]

I wonder if this PR will make the termsOfUse section more confusing by removing the presentation example (editorial change, no problem), but doesn't remove the text that explains that presentations can have a termsOfUse property (substantive change, maybe v1.2, but probably v2).
I think that rather than removing the example, it may be better to add a note that says there is a bug in the @context file such that it doesn't support termsOfUse in presentations even though the spec does, so implementers who wish to use this property will need to add termsOfUse to their own context for presentations.

[kdenhartog]

I wonder if this PR will make the termsOfUse section more confusing by removing the presentation example (editorial change, no problem), but doesn't remove the text that explains that presentations can have a termsOfUse property (substantive change, maybe v1.2, but probably v2).
I think that rather than removing the example, it may be better to add a note that says there is a bug in the @context file such that it doesn't support termsOfUse in presentations even though the spec does, so implementers who wish to use this property will need to add termsOfUse to their own context for presentations.

Yeah that's something I was thinking about as well when I was working on this. You stating that makes me think it's actually probably the better direction. I'll get a second PR open on that today so that we can decide which is preferred method during the review period.

[kdenhartog]

I did some investigation into how this would work before creating the second PR. As far as I'm able to tell extending the contexts to support the term in the Verifiable Presentation wouldn't work as defined. Since the termsOfUse property is already defined within the V1 context it appears to create a term conflict because the termsOfUse property is protected in the VC document. If someone can link me to an example that shows a valid JSON-LD document extending to make this property available, I'll go ahead and write up the second PR to support that.

At this point though, I'm not convinced the extension method is a valid path forward.

[David-Chadwick]

I think that rather than removing the example, it may be better to add a note that says there is a bug in the @context file such that it doesn't support termsOfUse in presentations even though the spec does, so implementers who wish to use this property will need to add termsOfUse to their own context for presentations.

This is my favoured approach. The intention was always that ToU should be in presentations. So we should point out there is a bug in the "at context" rather than remove the example and any mention of ToU in presentations

[kdenhartog]

I think that rather than removing the example, it may be better to add a note that says there is a bug in the @context file such that it doesn't support termsOfUse in presentations even though the spec does, so implementers who wish to use this property will need to add termsOfUse to their own context for presentations.

This is my favoured approach. The intention was always that ToU should be in presentations. So we should point out there is a bug in the "at context" rather than remove the example and any mention of ToU in presentations

I agree, but I couldn't find a way that "implementers who wish to use this property will need to add termsOfUse to their own context for presentations" could actually go about doing this because terms are being protected. If someone can show me a document with it working then I can switch that over. I just didn't want to suggest that route if it's not actually usable.

[David-Chadwick]

One solution might be to define PToU (Presentation Terms Of Use) in VCv2 as a differently named (or alias) property for VPs with the same semantics as the existing ToU for VCs.
On a related note, we already have to supplement the existing ToU context definition for VCs, when we add our our properties to ToUs. So clearly the existing ToU is not immutable.

[kdenhartog]

One solution might be to define PToU (Presentation Terms Of Use) in VCv2 as a differently named (or alias) property for VPs with the same semantics as the existing ToU for VCs.
On a related note, we already have to supplement the existing ToU context definition for VCs, when we add our our properties to ToUs. So clearly the existing ToU is not immutable.

Do you have an example document of this that I can play around with to see it working? I'm almost certain we can figure out a working solution for it, but after about an hour of trying I gave up and figured I'd rely on someone to point me in the right direction on it. If we can extend it I'd much prefer that because the termsOfUse feature reads as half baked with this current deletion.

[David-Chadwick]

This is the URL that was used in the TRAIN project to define the context for the trust scheme that is embedded in the ToU
https://essif-lab.pages.grnet.gr/interoperability/eidas-generic-use-case/contexts/train-trustScheme.jsonld
Currently we have not used ToUs in VPs, only in VCs.

[dlongley]

@kdenhartog,

As far as I'm able to tell extending the contexts to support the term in the Verifiable Presentation wouldn't work as defined. Since the termsOfUse property is already defined within the V1 context it appears to create a term conflict because the termsOfUse property is protected in the VC document.

The fact that termsOfUse is defined in a type-scoped context for VerifiableCredential shouldn't be an issue here. The issue, I'd think, is that VerifiablePresentation does not define termsOfUse and you can't just redefine VerifiablePresentation to include it (and you can't "append" term definitions to an existing type-scoped context).

What you can do (without running afoul of the @protection rules) is add a new type like TermsOfUseVerifiablePresentation, include a termsOfUse term definition in its type-scoped context, and then anyone creating a VerifiablePresentation that wants to use the term would need to include the additional type in the VP: {"type": ["VerifiablePresentation", "TermsOfUseVerifiablePresentation"], ...}.

[kdenhartog]

@kdenhartog,

As far as I'm able to tell extending the contexts to support the term in the Verifiable Presentation wouldn't work as defined. Since the termsOfUse property is already defined within the V1 context it appears to create a term conflict because the termsOfUse property is protected in the VC document.

The fact that termsOfUse is defined in a type-scoped context for VerifiableCredential shouldn't be an issue here. The issue, I'd think, is that VerifiablePresentation does not define termsOfUse and you can't just redefine VerifiablePresentation to include it (and you can't "append" term definitions to an existing type-scoped context).

What you can do (without running afoul of the @protection rules) is add a new type like TermsOfUseVerifiablePresentation, include a termsOfUse term definition in its type-scoped context, and then anyone creating a VerifiablePresentation that wants to use the term would need to include the additional type in the VP: {"type": ["VerifiablePresentation", "TermsOfUseVerifiablePresentation"], ...}.

That's what I was thinking as well and I couldn't get it working. I think the reason was actually an issue with how I was looking to extend it. I'll give it another go since your point made it obvious to me now where I was likely making the mistake.

[kdenhartog]

Ok I tried this again and found a way to do this. It was definitely not intuitive, so I'll work the example context in to show how this could be done.

[msporny]

Ok I tried this again and found a way to do this. It was definitely not intuitive, so I'll work the example context in to show how this could be done.

I'm taking 14 day merge off of this until we have a PR that's ready to go.

[wyc]

@kdenhartog to close after the other PR is opened.

[iherman]

The issue was discussed in a meeting on 2021-08-11

• no resolutions were taken

View the transcript

3.2. removes mention of termsOfUse with verifiable presentations (pr vc-data-model#787)

See github pull request #787.

Kyle Den Hartog: this needs to be closed after back and forth conversations. I found a way to fix this and will add a PR for that.

Brent Zundel: should close once we have a PR merged

Wayne Chang: I'll add a note for that

[kdenhartog]

I decided rather than fuss around with closing and opening PRs here, I would just force push to update this branch. Was easy enough to do, so this should be ready for review again taking into account the suggestions from @brentzundel

[kdenhartog]

I've re-added the label for this. We didn't say if we needed to resend an email for that, so to error on the side of caution I did so in this email: https://lists.w3.org/Archives/Public/public-credentials/2021Aug/0200.html

It's a one time occurrence because we were going to close this one and open a new one, so I figured that's the best way to handle this scenario. I don't expect that every change to a PR will require an email and a reset to the 14 day merge, but I'll leave that to the chairs to decide.

[msporny]

I'm a bit wary of this change... more in review comments requesting changes.

[msporny]

Upon further reading, need a few changes in this PR for it to line up with the rest of the spec.

[kdenhartog]

Thanks @msporny and @dlongley for the reviews. I've updated everything to align with your feedback.

[kdenhartog]

awaiting re-review from @msporny to make sure he's satisfied with the changes before merging

[chaals]

Noting that the explanatory diagram includes termsOfUse, I'm watching this in relation to #786 but I think that given the grahp doesn't manage namespacing, and is an example, I would leave the termsOfUse there.

Although it is trivial to generate a version with it removed if the group prefers to do that.

[kdenhartog]

Noting that the explanatory diagram includes termsOfUse, I'm watching this in relation to #786 but I think that given the grahp doesn't manage namespacing, and is an example, I would leave the termsOfUse there.

That's where the PR has headed now as well, so I like the idea of leaving it in the graph in #786

[iherman]

The issue was discussed in a meeting on 2021-08-25

• no resolutions were taken

View the transcript

4.2. removes mention of termsOfUse with verifiable presentations (pr vc-data-model#787)

See github pull request #787.

Brent Zundel: summarised that ToU is said to be in presentations but this is not described properly. ie. there is a bug in the spec

Manu Sporny: approves the merge of this PR and it is after the 14 day review

[kdenhartog]

There's a linked issue with the Errata label, removing the Errata and Editorial labels from the PR