Add issuee definition

[David-Chadwick]

There have been a number of discussions and pieces of text when the use of the term holder has not been precise enough, since it is the first holder that is specifically being addressed in these cases, rather than any holder.
The proposal is to add the definition of issuee to the data model, it being the first holder that the issuer issues the VC to.
The proposal is also to review the various CRs from the group and to use the newly defined term where it is appropriate to do so (rather than the existing use of holder, or first holder or other phrase that implies the issuee).
This will be a non-normative change to the DM, since there will not be any protocol messages that refer to the issuee.

[David-Chadwick]

Here is the straw man proposal for the definition of issuee, so that we can discuss it here and then move the agreed upon definition to the PR #1468

A role an [=entity=] performs when it is the intended recipient of 
a [=verifiable credential=] from
the [=issuer=] and stores the [=verifiable credential=] in its [=repository=]. 
The issuee role is a subclass of the [=holder=] role.

And here is the straw man proposal for changing the definition of issuer.

A role an [=entity=] performs by asserting [=claims=] about zero, one or
more [=subjects=], creating a [=verifiable credential=] from these
[=claims=], and transmitting the [=verifiable credential=], directly 
or indirectly, to the [=issuee=].

[iherman]

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

• no resolutions were taken

View the transcript

2.4. Add issuee definition (issue vc-data-model#1467)

See issue vc-data-model#1467.

David Chadwick: Yes. One of the issues, is does the issuer issue the credential directly or indirectly?
… currently the text doesn't have anything one way or another.
… we should bring that up to the WG.
… irrespective of the definition of issuee, should we talk about direct/indirect issuees?

Ted Thibodeau Jr.: I think that's a different discussion. Should be a different issue and we can talk about it on its own.

Manu Sporny: One of the concerns I have about adding terminology is that it becomes harder for people to talk about the system.
… I agree there is a concept of an issuee, and I wouldn't oppose mentioning that in the spec, but changing the three-party model is problematic.
… sometimes the distinctions matter, sometimes not.

Greg Bernstein: +1.

Manu Sporny: if we add to many special terms it harms adoption because its harder to explain what we are doing.
… I don't think the juice is worth the squeeze.
… Its fine if we want to talk about issuees as subclass of holder, but creating a new term and injecting it throughout is problematic.

Dave Longley: +1 to manu.

Ivan Herman: I feel uneasy about the whole discussion.
… As far as I can see, the term and possible changes are in a non-normative section, but we are in CR.
… we are not supposed to come up with new features without a good technical reason.

Gabe Cohen: I see a label of CR1.
… do you suggest we close this, Ivan?

Ivan Herman: non-normative language is fine, but normative language can be in a second CR but still needs a good reason. But I'm not the technical expert.

Gabe Cohen: I think with the new issue, we might benefit from seeing where the discussion might lead.

Dave Longley: I don't think the current text has any issues wrt direct/indirect language. It was the potential introduction of issuee where that created potential problems.
… the current text is not prescriptive about those things, so we should be careful if we add that.
… I wouldn't have an issue with talking about special cases, subclasses, etc. but probably not a good idea to modify the generic core text.

Dave Longley: +1 to avoid confusing / changing the primary roles and language around it.

Joe Andrieu: not a big fan of introducing issuee in a way that confuses the three primary roles...we talk about it at a high level and also subclassing. we know it is the holder who is presenting. we can talk about these distinctions (when the holder receives, presents)...
… our architecture we need to retain given the process.

Dave Longley: +1 to Joe.

Gabe Cohen: scribe.

David Chadwick: As a result, I already removed it from the diagram.
… . Also, agreed that the changes are non normative.
… The other thing is that its there because the role does exist. It's always been there.
… because we've not mentioned it. I'd be happy if we don't make it a formal definition, but say somewhere that the issuee is a subclass of holder.
… I think the term should be in the VCDM since it is used elsewhere.

Gabe Cohen: Thanks, David. Everyone, please chime in on the issue.

[iherman]

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

• no resolutions were taken

View the transcript

2.3. Add definition of Issuee (pr vc-data-model#1468)

See pull request vc-data-model#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 issue vc-data-model#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?

[TallTed]

All existing mentions of issuee within HTML spec docs can be found with this search (which regrettably gets extra things like issueEvent, which I can find no way to exclude). I probably should have sorted the results by least-recently-updated; instead, each of these bullet sub-lists are sorted by 's idea of "best match". :-/ Hopefully, still helpful.

• https://.com/search?q=issuee++user%3Aw3c+language%3AHTML&type=pullrequests&ref=advsearch

There is only one instance in the main branch of one document, the VCDM itself —

• vc-data-model/index.html

  Line 4068 in 1ab385f

  attributes such as `initialRecipient` (a/k/a `issuee`), `presenter`,

There are other instances in issues (all on the VCDM) —

• open
  • Add issuee definition #1467
  • Authorized Presenters #1359
• closed
  • Create the new role of issuee #942
  • Clarification needed on the ease of deducing that a subject is the holder. #959
  • Entities and Parties #1173
  • nonTransferable Property questions #960
  • "bound"/"binding" terminology is a significantly stronger relationship than is actually present between VCs and their Subjects *or* Holders #821
  • Representing Multi Issuer Credentials in the VCDM #932
  • Clarification on when a credentialRefresh service should be used #1020
  • Define "prover" in addition to "holder". #902
  • Securing the VC Data Model with JOSE #971
  • W3C VC-LD Specification and Layered VC Specification: = interoperability at the application layer of layered spec #982
  • ACDC (Authentic Chained Data Containers) in VC DM 2.0 #895
  • Making explicit the binding of the holder to a VC #923
  • Representing Mutli Subject Credentials in the VCDM #931
  • Explicit reference should be added about binding the VC to the holder #789
  • Determine interoperable way for Holder to make claims directly in VPs #860
  • more clarity around the id field in the VC data model #973
  • notTransferable property not defined in @context #731

— and PRs (most on the VCDM; one each on BitStringStatusList and UseCases) —

• open
  • Add definition of Issuee #1468
• draft
  • Address Jeffrey Yasskin's review comments that are Editorial #1464
• merged
  • Add confidenceMethod to table of reserved terms and v2 @context #1142
  • Add table of reserved properties #1082
  • Add privacy considerations about status message updates/alterations. vc-bitstring-status-list#156
• closed (not merged)
  • Non-transferable use case vc-use-cases#127
  • Add confidence method to VCDM #1054
  • Add nonTransferable property to credentials vocab #969
  • Making explicit the binding of the holder to a VC #795

[TallTed]

@jandrieu said

Jamming two nouns together and pretending its a new noun most likely doesn't help ... We could say "presenter holder" or "recipient holder"

I think you're right about jamming two nouns together. However, I think we can change one of those nouns into a verb which can then serve as an adjective, e.g., "presenting holder" or "receiving holder", and these compound nouns can then provide some additional clarity in discussion of the passage of a VC/VP.

[David-Chadwick]

@TallTed Thankyou for doing the search. Would you like to suggest changes to the straw man text above?

[TallTed]

This is a blend of the issuee above, and my own earlier straw man. Note that no actions are required of the issuee; this is purely a passive role, based entirely on the actions of the issuer.

A sub-role into which a [=holder=] is cast when an [=issuer=] indicates they
are an intended [=holder=] of a [=verifiable credential=], typically through
one of the [=claims=] in the [=verifiable credential=]. The issuee can, but is
not required to, store such [=verifiable credentials=] in its [=repository=]
(which may be a wallet or similar software). If the issuee is not identified
directly as such in one of the [=claims=] of a [=verifiable credential=], or
indirectly through a [=claim=] in another [=verifiable credential=] [=issued=]
by same [=issuer=], the issuee of that [=verifiable credential=] cannot be
known except by its [=issuer=].

I think no changes will be needed to the definition of issuer.

I also think authorized presenter does quite have not the same meaning, and some additional wordsmithing on another definition (probably in another issue or few, to drive another PR or few) will likely be needed to cover all the purposes for which issuee has ben suggested.

I also think that we need definition input and buy-in from more than just you and I, if this is to get into the document.

[brentzundel]

While there is obviously interest from some parties to continue exploring an issuee property, there is not clear consensus in the group to do this now.

We discussed it rather thoroughly in #942 and could not find consensus, which led to that issue being closed.
I am not seeing any new information that justifies once again discussing the role of issuee here.

I believe this issue and the related PR #1468 should be closed.
Unless there is clear consensus from the group to make the changes recommended in #1468 within 7 days, I will be closing this issue and that PR.