Open David-Chadwick opened 6 months ago
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=].
The issue was discussed in a meeting on 2024-04-03
The issue was discussed in a meeting on 2024-04-03
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.
There is only one instance in the main branch of one document, the VCDM itself —
There are other instances in issues (all on the VCDM) —
— and PRs (most on the VCDM; one each on BitStringStatusList and UseCases) —
@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.
@TallTed Thankyou for doing the search. Would you like to suggest changes to the straw man text above?
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.
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.
The issue was discussed in a meeting on 2024-04-10
@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
@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.
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 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.
@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.
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?
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.
@brentzundel Thankyou. When @TallTed and myself agree on some text we can forward it to the WG for consideration.
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.
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.