search

w3c / vc-data-model

W3C Verifiable Credentials v2.0 Specification
https://w3c.github.io/vc-data-model/
Other
290 stars 106 forks source link

Add definition of Issuee #1468

Closed David-Chadwick closed 5 months ago

David-Chadwick commented 6 months ago

Add issuee and changes due to adding it

Preview | Diff

TallTed commented 6 months ago

This PR only addresses the VCDM, not any of the connected documents. Again, I recommend opening one issue (and associated PR) per repo, and cross linking those issues.

TallTed commented 6 months ago

[@decentralgabe] Something like "an issuee can be a holder, but a holder may not be an issuee" with examples for each.

That (inaccurate) comment shows that such language is definitely needed. An accurate version of that statement would be "All issuees are holders, but many holders are not issuees" (a la "all squares are rectangles, but many rectangles are not squares").

Something like this might be a start --

An [=issuee=] is a [=holder=] that received a [=verifiable credential=] directly
from its [=issuer=]. A [=holder=] may receive a [=verifiable credential=] from its
[=issuer=], its [=issuee=], or any other [=holder=]. A [=verifiable credentials=]
might or might not identify its [=issuee=] as one of its [=claims=]. If not so
identified, the [=issuee=] cannot be known with certainty.
decentralgabe commented 6 months ago

All issuees are holders, but many holders are not issuees

In my understanding, one can be an issuee without being a holder. I can create a credential as an issuer about someone (issuee) and not give it to them.

Holder speaks to possession. Issuee speaks to intention (whether the party is identified or not).

TallTed commented 6 months ago

[@decentralgabe] In my understanding, one can be an issuee without being a holder. I can create a credential as an issuer about someone (issuee) and not give it to them.

In that scenario, you, as an issuer, have created a credential about someone (who is a/the subject of that credential). Since you haven't given it to them, I don't think they're an issuee. I'm not sure whether you, as the issuer of the VC, can also be the issuee, or are just a holder, until you pass that VC to someone else, who (I think) would need to be identified as issuee within the VC for others to usefully and reliably treat them as such.

Holder speaks to possession. Issuee speaks to intention (whether the party is identified or not).

I don't quite understand your use-case/user-story.

I can't imagine a scenario where discussing an unidentified issuee is useful.

There is always an issuee, who receives the VC from the issuer, but I think that an issuee who is not identified as such within the VC cannot be usefully referenced as the issuee by anyone other than the issuer, and even their reference seems questionably useful to me.

Perhaps you could offer a concrete change to my suggested paragraph?

And/or discuss issuee with @David-Chadwick, hopefully in a public space, so we can all benefit from that conversation?

TallTed commented 6 months ago

It would have been better to say this in the opening comment of this PR. But better late than never.

THis PR #1468 is intended to fix (partially) Issue #1467

decentralgabe commented 6 months ago

As an alternative I would propose clarifying what "holder" means in different scenarios. A holder is...

  1. Someone who is in possession of the credential – holder
  2. Someone who is in possession of the credential, who the credential has been issued to – cryptographic holder
  3. Someone who is in possession of the credential, who the credential is about (subject) – holder subject
jandrieu commented 5 months ago

As an alternative I would propose clarifying what "holder" means in different scenarios. A holder is...

This might be a good avenue to help clear up confusion, but I'm not sure your language hits the mark.

  1. Someone who is in possession of the credential – holder

Agreed. This is the current definition.

  1. Someone who is in possession of the credential, who the credential has been issued to – cryptographic holder

Unfortunately, we cryptography can't prove who a credential was issued to. All it can prove is that a current party has access to a cryptographic secret that can prove control over the identifier used for one of the subjects. WHO the initial VC is "issued to" in the sense of "issuee" is the hard problem of confidenceMethod. We can't blithely assert that the secret holder is the issuee. Because, in fact, the controller of an identifier may not be involved in the issuance of a VC using that identifier. Presuming that they are is beyond the guarantees of the spec.

  1. Someone who is in possession of the credential, who the credential is about (subject) – holder subject

This is a subject who is a holder. Jamming two nouns together and pretending its a new noun most likely doesn't help with the confusion. The subject may not be the controller of the identifier. They may not be the holder.

We have to be exceptionally careful about the implied guarantees. If you are making a statement about the subject, use "subject". If making a statement about the holder, use "holder". At no point, to my consideration, does it seem better to say "subject holder" rather than just "subject".

I have the same stylistic take on using the term "presenter" and "recipient" to describe the momentary role of a holder when performing those tasks. We could say "presenter holder" or "recipient holder" but since "holder" is well-defined, referring to the "presenter" or the "recipient" simply highlights the action taken by that role, without confusion, IMO. The extra words certainly don't make it easier to read. In fact, I think it makes it more confusing. Concise language is good language.

IMO, confidenceMethod dealt with this appropriately, given issuers a standard way to tell verifiers how they might establish confidence that the presenter of a VC is, in fact, one of the subjects of that VC.

David-Chadwick commented 5 months ago

Please continue this discussion in the issue https://github.com/w3c/vc-data-model/issues/1467 then the results of the discussion can be copied back to this PR

iherman commented 5 months ago

The issue was discussed in a meeting on 2024-04-03

View the transcript #### 2.3. Add definition of Issuee (pr vc-data-model#1468) _See github pull request [vc-data-model#1468](https://github.com/w3c/vc-data-model/pull/1468)._ **David Chadwick:** Heads up. The PR exists for the issuee property, but Ted asked to move the discussion back to the issue. … because we lose the comments in the PR when it is resolved. … So, lets talk about the PR in the issue. **Ivan Herman:** can you add the issue reference in the minutes? **David Chadwick:** 1467. _See github issue [vc-data-model#1467](https://github.com/w3c/vc-data-model/issues/1467)._ **Gabe Cohen:** might be useful to add a comment to the PR stating that. **David Chadwick:** It's there, but it's buried in the middle. **Ted Thibodeau Jr.:** let's talk about in the issue, then we implement it in the PR (or in a new PR), which likely would be different. **Gabe Cohen:** David would you like to discuss this?
brentzundel commented 5 months ago

Please see https://github.com/w3c/vc-data-model/issues/1467#issuecomment-2045437624

iherman commented 5 months ago

The issue was discussed in a meeting on 2024-04-10

View the transcript #### 2.6. Add issuee definition (issue vc-data-model#1467) _See github issue [vc-data-model#1467](https://github.com/w3c/vc-data-model/issues/1467)._ _See github pull request [vc-data-model#1468](https://github.com/w3c/vc-data-model/pull/1468)._ **Brent Zundel:** ok, we're at time, thanks everyone. … before we close, I do want to note issue 1467, I made a chair statement on that, I'm not seeing any new info that justifies the conversation taking further time. … that said, if in the comments of the issue and the resulting PR, if people can come to consensus on the way forward, I won't step in the way. … I'm just not seeing consensus form. ---
msporny commented 5 months ago

7 days marked as pending close with no objections, closing.