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 github 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 github 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 github 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 GitHub's idea of "best match". :-/ Hopefully, still helpful.

• https://github.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.

[iherman]

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

• no resolutions were taken

View the transcript

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

See github issue vc-data-model#1467.

See github pull request vc-data-model#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.

---

[David-Chadwick]

@TallTed I agree with most of your text, apart from this

The issuee can, but is
not required to, store such [=verifiable credentials=] in its [=repository=]

Q. Is a holder required to store the VC in its repository? If not, how is it a holder? If it is, since an issuee is a subclass of a holder then it must also be required to store the VC in its repository

[David-Chadwick]

@brentzundel This issue is still being discussed. It is not unusual for an issue to only have a couple of people discussing it, and it should not be closed until they have come to a resolution. So can I kindly ask you to keep the issue open until a resolution has been found, which can then be presented to the WG.

[TallTed]

Q. Is a holder required to store the VC in its repository? If not, how is it a holder? If it is, since an issuee is a subclass of a holder then it must also be required to store the VC in its repository

Where do we say that a holder is required to store a VC in its [credential] repository?

(struck out portions moved to #1475)

(Also note: we define repository but not credential repository. Bare repository is used 3 times in the text; credential repository is used 4 times. I think all occurrences of the bare repository should be changed to credential repository.)

In trying to answer my question above, I discovered that we have two competing definitions for holder (and several other things) — in 1.2 Ecosystem Overview (which I think should either point to the other section, or exactly duplicate the other definition) and 2. Terminology (which I think is meant to be authoritative).

As to the answer to my question, I find that the latter definition includes "Holders store their credentials in credential repositories." This does not read to me as a requirement (since there's no MUST, nor even a SHOULD).

(struck out portions moved to #1475)

Then, the definition of repository — "A program, such as a storage vault or personal verifiable credential wallet, that stores and protects access to holders' verifiable credentials." Can I not store a VC in a simple filesystem directory, that is on my personal storage device? I thought I could...

[brentzundel]

@brentzundel This issue is still being discussed. It is not unusual for an issue to only have a couple of people discussing it, and it should not be closed until they have come to a resolution. So can I kindly ask you to keep the issue open until a resolution has been found, which can then be presented to the WG.

This issue has been discussed very thoroughly, primarily in issue #942, which was closed due to lack of consensus to make the change.
This new discussion does not introduce any new data that justifies spending additional WG time on the topic. That said, I have given the group several weeks of additional time to pursue consensus anyway. I still plan to close this issue and the related PR on 16 April 2024 if consensus has not been found by then.

[David-Chadwick]

@brentzundel This discussion is valuable as it is revealing other issues in our definitions besides the omission of issuee. For example see #1475 . So please do not close this until all the issues have been teased out and resolved as your statement "This new discussion does not introduce any new data" is not correct.

[David-Chadwick]

We need to revisit the definition of holder to determine whether a holder must store verifiable credentials or not. If not, what does it mean to be a holder if you do not store VCs in a credential repository? What are you holding?

[brentzundel]

Rather than closing this issue, I am marking it as future
Conversation can continue as participants have time and interest, but we won't take time during the current iteration of the VCWG to discuss it.

[David-Chadwick]

@brentzundel Thankyou. When @TallTed and myself agree on some text we can forward it to the WG for consideration.

[David-Chadwick]

Now that we have updated the definitions of holder, issuer and verifier, the addition of issuee becomes trivial. Specifically we simply change the definition of issuer from

A role an [=entity=] can perform by asserting [=claims=] about one or more
[=subjects=], creating a [=verifiable credential=] from these [=claims=], and
transmitting the [=verifiable credential=] to a [=holder=]. Example issuers
include corporations, non-profit organizations, trade associations, governments,
and individuals.

to

A role an [=entity=] can perform by asserting [=claims=] about one or more
[=subjects=], creating a [=verifiable credential=] from these [=claims=], and
transmitting the [=verifiable credential=] to the [=issuee=]. Example issuers
include corporations, non-profit organizations, trade associations, governments,
and individuals.

The definition of issuee then simply becomes

A role an [=entity=] performs when it obtains one or more [=verifiable
credentials=] from an [=issuer=]. The [=issuee=] role is a subclass of the [=holder=] role.