Add definition of Issuee #1468

David-Chadwick · 2024-03-27T16:35:06Z

Add issuee and changes due to adding it

dlongley · 2024-03-27T17:28:24Z

index.html

+[=claims=], and transmitting the [=verifiable credential=] to the
+[=issuee=]. Example issuers include corporations, non-profit organizations,


Hmm, it could be that an issuer hands the credential to some party other than the issuee as the first holder. And that party will / is expected to perform delivery to the issuee. At least, I would expect people to think that the issuee is different from this intermediary. I worry that this change reduces something more general to a specific case where the issuer interacts directly with the "issuee" whereas the previous text allowed for there to be any number of intermediaries.

If an issuer issues into a repository managed by a third party that holds the credentials for later pickup by eventual recipients -- is that third party the issuee ... or are those recipients the issuees?

Issuers may also issue directly onto public lists, where I don't think the "public list" would be considered an "issuee", but it would be a "holder". There may be no "issuee" in this case ... right?

I think we would need different language here around the "issuee" case being a more specific case (even if it happens quite often) of the more general model. So the issuer always issues to a holder, which may / may not be expressed or recognized as an issuee?

@dlongley — Good questions! Definitely need to be addressed!

(Such questions are part of why I suggested there be an issue [per repo] for this, as comments on an issue will be more visible in the future than inline PR review comments.)

After submitting this PR, I (privately) raised with Manu the issue of making changes to our multiple documents now and he recommended waiting for this PR to be resolved before making any changes to any other of our documents

TallTed

It's a start...

TallTed · 2024-03-27T17:27:35Z

index.html

+[=claims=], and transmitting the [=verifiable credential=] to the
+[=issuee=]. Example issuers include corporations, non-profit organizations,


Is there only one issuee, by definition?

Or could the issuer simultaneously transmit the VC to multiple issuees?

Suggested change

[=claims=], and transmitting the [=verifiable credential=] to the

[=issuee=]. Example issuers include corporations, non-profit organizations,

[=claims=], and transmitting the [=verifiable credential=] to an

[=issuee=]. Example issuers include corporations, non-profit organizations,

I believe that all current protocols are 1 to 1 and not 1 to many

I believe that all current protocols are 1 to 1 and not 1 to many

But is that a necessary restriction, to be enshrined in this standard? I think one-to-many is, and should be preserved as, a possibility.

TallTed · 2024-03-27T17:32:01Z

index.html

+[=verifiable credentials=] from an [=issuer=]. An issuee is a subclass
+of the holder role.


Suggested change

[=verifiable credentials=] from an [=issuer=]. An issuee is a subclass

of the holder role.

[=verifiable credentials=] directly from an [=issuer=]. The issuee

role is a subclass of the [=holder=] role.

The word "directly" is not in the current text so I suggest not to make this change.
I accept your changes to the role sentence, thanks.

I thought that this sentence would be sufficient to tell the reader that all issuees are holders, but not all holders are issuees. That is the meaning of subclassing.

The word "directly" is what ensures that the issuee does not receive the VC from an intermediary holder ... Or is such a relay possible in your mental model? Is issuee defined simply as "the entity identified as such within the VC", rather than reflecting anything about the VC's passage from issuer to (holder to) issuee??

Maybe an issuee is one or more entities that an issuer can opt to explicitly identify as intended holders -- and that's all that needs to be said. I don't expect us to come to consensus on any text that reduces the generality we have today around the flow of VCs, but text that identifies some special (and particularly useful) case of holder roles on top of it is probably acceptable.

TallTed · 2024-03-27T17:36:16Z

index.html

+        <dt><dfn class="export" data-lt="issuee|issuee's">issuee</dfn></dt>
+        <dd>
+A role an [=entity=] performs when it receives a [=verifiable credential=] from
+the [=issuer=].
        </dd>


Does this overlap/repeat lines 376-382?
Does the data-lt attribute value (now snigular, plural, and possessive) need to include the (singular) string within the <dfn>?

Suggested change

<dt><dfn class="export" data-lt="issuee|issuee's">issuee</dfn></dt>

<dd>

A role an [=entity=] performs when it receives a [=verifiable credential=] from

the [=issuer=].

</dd>

<dt><dfn class="export" data-lt="issue|issuees|issuee's">issuee</dfn></dt>

<dd>

A role an [=entity=] performs when it receives a [=verifiable credential=] directly

from an [=issuer=].

</dd>

I am not sure the proposed change to the data-lt is correct. Lets discuss at a WG meeting.
Again, "directly" is not in the current text, so I prefer not to make this change.

I am not sure the proposed change to the data-lt is correct. Lets discuss at a WG meeting.

Fine.

Again, "directly" is not in the current text, so I prefer not to make this change.

This (something which the WG needs to decide) seems more important to discuss in a WG call than the data-lt change (which is strictly a question of the technicalities of that attribute, and can be answered by anyone more versed in the finer points of ReSpec magic.)

-1 to "directly" -- the meaning is vague.

Is the use of a proxy to receive the credential "directly"? Is the use of a browser to receive it into a digital wallet "directly"? Is the use of a hold-and-pickup-later service "directly"? ... and if we explain what "directly" means, does it add value to the understand-ability of the text?

OK. So, issuee is a role assigned to an entity (not performed by that entity, as no action on that entity's part is required), which assignment, made by the issuer of a VC, is achieved by including a claim that sets (a? the?) value of the issuee property to an identifier of that entity.

By that definition, transmission of the VC to that entity isn't required, which means that the issuee is not necessarily a holder.

(And there's enough hashing out happening through suggestions on this PR that the discussion should probably be moved to an issue or a non-suggestion thread, because the suggestions will vanish if merged, and become hard to see if resolved.)

@TallTed - Good suggestion. The issue is #1467 . I have moved the proposed definition to this issue so that we can continue the discussion there and hence record all the arguments for posterity.

TallTed · 2024-03-27T17:44:03Z

index.html

        <dt><dfn class="export" data-lt="issuers|issuer's">issuer</dfn></dt>
        <dd>
 A role an [=entity=] can perform by asserting [=claims=] about one or
 more [=subjects=], creating a [=verifiable credential=] from these


As above, does this echo/repeat lines 369-372?
Does the data-lt attribute value (now singular, plural, and possessive) need to include the (singular) string within the <dfn>?

Suggested change

<dt><dfn class="export" data-lt="issuers|issuer's">issuer</dfn></dt>

<dd>

A role an [=entity=] can perform by asserting [=claims=] about one or

more [=subjects=], creating a [=verifiable credential=] from these

<dt><dfn class="export" data-lt="issuer|issuers|issuer's">issuer</dfn></dt>

<dd>

A role an [=entity=] can perform by asserting [=claims=] about one or

more [=subjects=], creating a [=verifiable credential=] from these

I have not made any edits to this text, so this should be a separate PR on the current CR.

TallTed · 2024-03-27T17:44:07Z

index.html

+[=claims=], and transmitting the [=verifiable credential=] to the
+[=issuee=].
        </dd>


As above, does this echo/repeat lines 373-376?

Suggested change

[=claims=], and transmitting the [=verifiable credential=] to the

[=issuee=].

</dd>

[=claims=], and transmitting the [=verifiable credential=] to an

[=issuee=].

</dd>

See discussion above

TallTed · 2024-03-27T17:49:58Z

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.

decentralgabe

I like the direction of this PR. I believe language should be added that clarifies the relation (or distinction) between issue and holder. Something like "an issuee can be a holder, but a holder may not be an issuee" with examples for each.

TallTed · 2024-03-27T18:50:02Z

[@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 · 2024-03-27T20:23:52Z

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 · 2024-03-28T17:45:52Z

[@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 · 2024-03-28T18:33:21Z

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

David-Chadwick · 2024-03-29T15:16:04Z

index.html

+[=verifiable credentials=] from an [=issuer=]. An issuee is a subclass
+of the holder role.


The word "directly" is not in the current text so I suggest not to make this change.
I accept your changes to the role sentence, thanks.

David-Chadwick · 2024-03-29T15:16:35Z

index.html

@@ -420,6 +426,8 @@ <h3>Ecosystem Overview</h3>
          </figcaption>
        </figure>

+[PR NOTE. Figure 1 will need updating to replace Holder with Issuee/Holder]
+


This note can be removed now, as Figure 1 has been updated.

I'm a strong -1 to updating the diagram to introduce two terms for a single block in the diagram. This will confuse readers -- "Well, which one is it... 'holder' or 'issuee', or is it both?"

Note: This doesn't mean I'm averse to defining the term, but introducing it as a top-level term will harm more than it helps.

David-Chadwick · 2024-03-29T15:18:21Z

index.html

+        <dt><dfn class="export" data-lt="issuee|issuee's">issuee</dfn></dt>
+        <dd>
+A role an [=entity=] performs when it receives a [=verifiable credential=] from
+the [=issuer=].
        </dd>


I am not sure the proposed change to the data-lt is correct. Lets discuss at a WG meeting.
Again, "directly" is not in the current text, so I prefer not to make this change.

David-Chadwick · 2024-03-29T15:19:30Z

index.html

        <dt><dfn class="export" data-lt="issuers|issuer's">issuer</dfn></dt>
        <dd>
 A role an [=entity=] can perform by asserting [=claims=] about one or
 more [=subjects=], creating a [=verifiable credential=] from these


I have not made any edits to this text, so this should be a separate PR on the current CR.

David-Chadwick · 2024-03-29T15:19:47Z

index.html

+[=claims=], and transmitting the [=verifiable credential=] to the
+[=issuee=].
        </dd>


See discussion above

msporny

I'm currently a -1 to the definition of "issuee". Just because we can subclass new terms doesn't mean we should, especially when we only use the term in a handful of places in the specification.

The mistake that many communities make is defining LOTS of terminology and acronyms and then insisting that those on the periphery of the community learn those terms as well. The more special terminology we have, the harder it becomes to grok the ecosystem we're describing.

I suggest that "issuee" falls into this category of a subclass term that does not add much value. IOW, I don't know what problem defining "issuee" is solving, but I can certainly see what problem it is creating.

The use in the specification is minimal, and when used, it doesn't really clarify much.

jandrieu

We should not change the holder definition in this way.

We have a considerable legacy of a three-party model. Issuees are already covered by holders as a role. Adding this additional language, IMO, does not clarify. It only obfuscates, as you can see with the extended conversation about what the term means, its multiplicity, whether the issuee is the first recipient or intended initial recipient, etc.

We should not make these changes.

decentralgabe · 2024-04-02T17:15:38Z

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

Someone who is in possession of the credential – holder
Someone who is in possession of the credential, who the credential has been issued to – cryptographic holder
Someone who is in possession of the credential, who the credential is about (subject) – holder subject

diagrams/ecosystem.svg

Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>

jandrieu · 2024-04-03T14:55:11Z

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.

Someone who is in possession of the credential – holder

Agreed. This is the current definition.

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.

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 · 2024-04-03T15:56:47Z

Please continue this discussion in the issue
#1467
then the results of the discussion can be copied back to this PR

iherman · 2024-04-03T16:06:52Z

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?

brentzundel · 2024-04-09T15:15:15Z

Please see #1467 (comment)

iherman · 2024-04-10T16:08:54Z

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.

msporny · 2024-04-16T15:01:26Z

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

Add definition of Issuee

3d86e9c

Add issuee and changes due to adding it

David-Chadwick requested review from msporny, iherman, selfissued and decentralgabe as code owners March 27, 2024 16:35

msporny requested review from BigBlueHat, dlongley, jandrieu, longpd, dmitrizagidulin, andresuribe87, Wind4Greg, TallTed, brianorwhatever, brentzundel and KDean-GS1 March 27, 2024 17:14

dlongley suggested changes Mar 27, 2024

View reviewed changes

TallTed suggested changes Mar 27, 2024

View reviewed changes

Wind4Greg approved these changes Mar 27, 2024

View reviewed changes

decentralgabe reviewed Mar 27, 2024

View reviewed changes

David-Chadwick commented Mar 29, 2024

View reviewed changes

msporny requested changes Apr 2, 2024

View reviewed changes

KDean-GS1 approved these changes Apr 2, 2024

View reviewed changes

jandrieu requested changes Apr 2, 2024

View reviewed changes

TallTed reviewed Apr 2, 2024

View reviewed changes

diagrams/ecosystem.svg Outdated Show resolved Hide resolved

Update diagrams/ecosystem.svg

0c20b3c

Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>

David-Chadwick mentioned this pull request Apr 2, 2024

Add issuee definition #1467

Open

decentralgabe linked an issue Apr 2, 2024 that may be closed by this pull request

Add issuee definition #1467

Open

brentzundel added the pending close Close if no objection within 7 days label Apr 9, 2024

msporny closed this Apr 16, 2024

msporny added the CR1 This item was processed during CR1 label Apr 16, 2024

		[=claims=], and transmitting the [=verifiable credential=] to the
		[=issuee=]. Example issuers include corporations, non-profit organizations,

		[=verifiable credentials=] from an [=issuer=]. An issuee is a subclass
		of the holder role.

Add definition of Issuee #1468

Add definition of Issuee #1468

Conversation

David-Chadwick commented Mar 27, 2024 • edited by pr-preview bot

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TallTed left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dlongley Apr 1, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TallTed commented Mar 27, 2024

decentralgabe left a comment

Choose a reason for hiding this comment

TallTed commented Mar 27, 2024

decentralgabe commented Mar 27, 2024

TallTed commented Mar 28, 2024

TallTed commented Mar 28, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

msporny left a comment

Choose a reason for hiding this comment

jandrieu left a comment

Choose a reason for hiding this comment

decentralgabe commented Apr 2, 2024

jandrieu commented Apr 3, 2024

David-Chadwick commented Apr 3, 2024

iherman commented Apr 3, 2024

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

brentzundel commented Apr 9, 2024

iherman commented Apr 10, 2024

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

msporny commented Apr 16, 2024

David-Chadwick commented Mar 27, 2024 •

edited by pr-preview bot

dlongley Apr 1, 2024 •

edited