Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add definition of Issuee #1468

Closed
wants to merge 2 commits into from
Closed

Add definition of Issuee #1468

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
3d86e9c
Add definition of Issuee
David-Chadwick Mar 27, 2024
0c20b3c
Update diagrams/ecosystem.svg
David-Chadwick Apr 2, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 17 additions & 4 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -370,9 +370,15 @@ <h3>Ecosystem Overview</h3>
<dd>
A role an [=entity=] performs 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,
[=claims=], and transmitting the [=verifiable credential=] to the
[=issuee=]. Example issuers include corporations, non-profit organizations,
Comment on lines +373 to +374
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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,

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +373 to +374
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

trade associations, governments, and individuals.
</dd>
<dt>[=issuee=]</dt>
<dd>
A role an [=entity=] might perform by receiving one or more
[=verifiable credentials=] from an [=issuer=]. An issuee is a subclass
of the holder role.
Comment on lines +380 to +381
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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??

Copy link
Contributor

@dlongley dlongley Apr 1, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

</dd>
<dt>[=subject=]</dt>
<dd>
Expand Down Expand Up @@ -420,6 +426,8 @@ <h3>Ecosystem Overview</h3>
</figcaption>
</figure>

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

<p class="note">
<a href="#roles"></a> above provides an example ecosystem in which to ground the
rest of the concepts in this specification. Other ecosystems exist, such as
Expand Down Expand Up @@ -584,13 +592,18 @@ <h2>Terminology</h2>
this document to other specifications. This specification decouples the
[=identity provider=] concept into two distinct concepts: the [=issuer=]
and the [=holder=].
</dd>
<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>
Comment on lines +596 to 600
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

<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
Comment on lines 601 to 604
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

[=claims=], and transmitting the [=verifiable credential=] to a
[=holder=].
[=claims=], and transmitting the [=verifiable credential=] to the
[=issuee=].
</dd>
Comment on lines +605 to 607
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See discussion above

<dt><dfn data-lt="named graphs">named graph</dfn></dt>
<dd>
Expand Down