Create the new role of issuee

[David-Chadwick]

There is still confusion in some quarters about the roles of subject and holder, possibly because sometimes these roles belong to the same entity, and sometimes to different entities and, in the case of holder, maybe to a series of entities as the VC is transferred from entity to entity. This proposal is to create a new role of issuee, which is fixed (permanently assigned) and always refers to the entity that receives the VC from the issuer. The following should help to clarify these roles as follows:

1. The issuer issues the VC to the issuee (always) and may optionally insert the issuee's identifier into the VC. (Note we could make issuee plural if people think that the same VC can be simultaneously issued to two or more entities.)
2. The issuer inserts its own identifier into the VC it issues (always)
3. The issuer issues the VC about one or more subjects (always) and may optionally insert the subject's (or subjects') identifier(s) into the VC.
4. The holder is a transient entity and refers to whoever holds a VC at any given point in time. An issuer, verifier, subject, issuee and other third party can at various times be the holder of a VC. The VC never contains the identifier of the holder as the holder is transient whilst the VC is persistent.

[TallTed]

I wrote and reordered these as I did with intention. Among other things, inline parenthetical notations suggest afterthoughts, which should not play a part in a proposal such as this. I've made further tweaks to cover your formerly 3, now 4, points, here —

1. The issuer always immutably inserts its own identifier into any VC it issues.

2. The issuer always issues a VC to one or more issuees, and optionally immutably inserts the identifier(s) of the issuee(s) into the VC.

3. The issuer always issues a VC about one or more subjects, and optionally immutably inserts the identifier(s) of the subject(s) into the VC.

4. The issuer never inserts the identifier of the holder as such, as a VC is persistent while its holder(s) is/are transient, referring to whoever holds a VC at any given point in time. The holder of a VC might at various times also be — or never be — its issuer, subject, issuee, verifier, and/or other known or unknown third parties.

---

Regarding multiple issuees — an organization might keep a "chrono" file as a "CC" or "BCC", along with the generally understood recipient. This would be particularly common in the world of capital investments, where it's important to be able to document whether a stock purchase or sale was initiated before associated private information was received... to demonstrate that the purchase or sale did not represent illegal insider trading.

[David-Chadwick]

Thanks Ted. Its looking good

[SmithSamuelM]

@TallTed +1

[agropper]

Apologies if this is a stupid question, but can someone clearly explain why VCs need to include any entity other than issuer and subject?

…

On Wed, Oct 5, 2022 at 1:57 PM Samuel Smith ***@***.***> wrote: @TallTed <https://github.com/TallTed> +1 — Reply to this email directly, view it on GitHub <#942 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YNY5764V3GUDQWRNODWBW6PDANCNFSM6AAAAAAQ5XAVNY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[David-Chadwick]

What if the issuer has the need to provide proof of issuance to a specific entity? Then in that case the issuer would need to include the identifier of the issuee in the issued credential.

[SmithSamuelM]

One way to address this is to define Other role pairings that represent the properties of different transactions.

For example. In ACDC we use a Discloser-Disclosee model. The Discloser is the one disclosing a VC to a second party who is the recipient of that disclosure, AKA the Disclosee. So, for example, when that disclosure must be protected in some way Then we can define a transaction type that provides such protection, independent of the Issuer/Issuee or Subject model. In such a protected disclosure, the Disclosee must first agree to terms of use imposed by the Discloser before disclosure, This is usually bootstrapped with what we call a MetaData VC that includes whatever meta-data about the eventual disclosure VC is needed to be agreed upon by the Discloser/Disclosee prior to Disclosure.

In some cases, the Issuer is also the Discloser, so a protected disclosure would also provid proof of Disclosure to a specific entity, the Disclosee.

If the Discloser is also the Issuer and the Disclosee is also the Issuee, then the proof of disclosure is also proof of issuance to a specific issuee.

Indeed when we separated Disclosure from Issuance, we solved many of the other problems with the VC data model.

Contractually protected disclosure, selective disclosure, partial disclosure, confidential disclosure, consent of use after disclosure. These all are primarily between any party who happens to be the Discloser, which party may or may not be the Issuer, or Issuee, or subject, or any other role.

Confusing the process of Disclosure of a VC with the process of issuance, subjectification, or presentation is problematic.

Instead by clearly modeling disclosure as its own exchange protocol, we avoid that confusion.

[SmithSamuelM]

The PAC principle says that we can have Privacy, Authenticity, and Confidentiality in an exchange of information but not all at once. We have to layer them and prioritize them. In ACDC and in the new ToIP stack the prioritization is
Authenticity First, Then Confidentiality Second, and Privacy Third.
So we have an authentication layer. We can then wrap that optionally in a confidentiality layer, We can then wrap those is in an optional privacy-preserving layer. The roles of the parties in each layer are specific to that layer. The same identifier may be instantiated to have a role in all three layers or not. It depends. The upper layers can refer back down to the lower layers but, the lower layers should not ever need to refer up to a higher layer. This approach clearly separates the roles and avoids ambiguity. The subjectification layer (VC subject) is a opaque payload of the lower layers.

Treating the subjectification layer (where semantic web constructs come into play) as an opaque payload to the lower layers make the privacy preserving layer work best. The roles that identifiers play in the lower layers are all metadata with respect to the VC subject. This is not at all changed even when the Identifier that is the VC subject is the same as one of the layer role identifiers. So for example, Issuer/Issuee operates differently from Discloser/Disclosee. An can use and Issuer/Issuee to convey an entitlement relationship between Issuer/Issuee that is independent of the Discloser/Disclosee relationship which may be about confidentiality and terms of use (privacy).

[SmithSamuelM]

With this layered model, it makes it much easier to discuss serialization formats. Everything in the PAC layers is metadata that is not part of the message payload.

But when using a document model of a message. the metadata could be in its own section of the document. This complicates cryptographic proofs and as a result, should be our last choice but could be done.

Better yet would be to put the metadata into an envelope for the message and even use layered envelopes which is the tried and true model for protocols in general.

Or the meta-data could be included in distinct syntactically framed and serializable headers or footers separate from the message body (a hybrid model).

Or the metadata could be provided as attachments in a streaming message model.

All of these serialization formats can share the exact same layering semantic for roles (and the identifiers that play those roles) at each layer. All that differs is the concrete representation of a given serialization that conveys the associated metadata.

The opaque payload is now free to be whatever it wants to be. It can be fully RDF with pure semantics for RDF.

To elaborate:

Issuance proofs that provide authenticity of issuance are in the authenticity layer, not in the payload.

Disclosure and presentation proofs are in the confidentiality and privacy layers but can reference identifiers already authenticated by the authenticity layer. None of these are in the payload.

Entitlements (authorizations) of identifiers are a proper sublayer to the authenticity layer. The business logic details associated with the downstream use of such entitlements can be part of the opaque payload. But always, the metadata essential to the upstream verification of the authentication, authorization, and subsequent presentation of such an entitlement belongs properly in the PAC layers that support the payload layer.

This provides a clean separation of concerns.

[msporny]

Also -1 to issuee -- mostly because this overlaps heavily with the "holder binding" work that @awoie is doing and it doesn't sound like the people suggesting this proposal have talked to the people working on the "holder binding" work. Don't spend your time on a PR yet as it'll probably be -1'd unless it has high alignment w/ the "holder binding" work that @awoie is leading.

[dwaite]

My concern is that a single property will not be robust enough. In particular, issuees tend to have their own properties - including the relationships with the subject(s) and issuer(s?), and any additional information needed for them to do a presentation proof. In some cases, the issuer may even try to convey whether or not that party is expected to issue statements about another party having a relationship to the original subject(s) or credential.

Since a credential can have multiple statements about different subjects, would it instead make sense to describe an issuee as another subject in a single credential, or possibly via a second credential?

[David-Chadwick]

@dwaite You dont need to worry about this. The proposal is that the issuee will be an object in the same way that the issuer and subject are. So the issuer will be able to record anything about the issuee that it needs to.

[RieksJ]

What if the issuer has the need to provide proof of issuance to a specific entity? Then in that case the issuer would need to include the identifier of the issuee in the issued credential.

I don't buy the argument, as it is of the form: I need X because there might be a situation in which I need X, but that I do not specify.

Apart from that, the mere fact that an issuee is added to a VC does not constitute proof that the VC was actually issued to such an issuee, so the example is flawed.

Can you perhaps provide a realistic, real-world example, that demonstrates that actual (not theoretical) need of the proposal, and also some arguments that convincingly show there's no viable alternative?

[RieksJ]

It seems to me as if we're leaping into all sorts of tech discussions to provide 'solutions' without taking the time to ponder what the actual problem is, what (other) solutions already exist or could be made to exist, and then make an informed decision.

For one: suppose a VC would contain an issuee field. As VCs can be moved around ad libitum (anyone can be the holder of such a VC), that might pose some privacy (GDPR) issues. There might be other practical drawbacks. Stuff like this needs to be considered, too.

[RieksJ]

At the start of the issue, @David-Chadwick wrote:

There is still confusion in some quarters about the roles of subject and holder, possibly because sometimes these roles belong to the same entity, and sometimes to different entities and, in the case of holder, maybe to a series of entities as the VC is transferred from entity to entity. This proposal is to create a new role of issuee, which is fixed (permanently assigned) and always refers to the entity that receives the VC from the issuer.

I think that this confusion is caused by

• the VCDM spec using ambiguous definitions (for example, it isn't clear whether issuer, holder, and verifier are roles that can be played by people/organizations (parties), or that they are technical roles performed by IT/digital components. This is relevant because a single party can use different/many wallets/agents to issue, request, receive and process VCs/VPs. And since you cannot sue digital components, you need to know whether e.g. a holder or issuer refers to a party (that you can sue), or to a digital component, in which case you need to somehow figure out on behalf of what party it acts (so that you may sue that party).
• people using terms that are specified in ways that are inconsistent with the provided definitions. For example, the text quoted above (but there are many other examples in pretty much every issue) the terms subject and holder are both taken to be roles. For holder ("A role an entity can perform by asserting claims about one or more subjects"), that is in line with the VCDM definition, but subject is not a role, but "a thing about which claims are made".

A solution for such confusion would then be

• to do some more work on the definitions of VCDM terminology,
• for all of us to use terms in a way that is consistent with the definition, or refer to the authoritative source for the term if it comes from outside VCDM
• to stimulate each other to actually do the above.

[SmithSamuelM]

@RieksJ

For one: suppose a VC would contain an issuee field. As VCs can be moved around ad libitum (anyone can be the holder of such a VC), that might pose some privacy (GDPR) issues. There might be other practical drawbacks. Stuff like this needs to be considered, too.

The way we handle this privacy protection problem is to place the Issuee identifier (when there is one) in the attributes section of the ACDC. The attributes section may be privacy protected and selectively disclosable. This enables the Discloser (who may or may not have the same identifier as the Issuee) to first contractually protect the later disclosure of the Issuee identifier. If the potentical or candidate Disclosee does not agree to protect this contingent disclosure then the Disclosee will not ever see the Issuee identifier and therefore cannot link the Issuee to the Discloser.

The current VCDM does not currently have the granularity to separate Disclosers and Disclosees from other roles like Issuers and Issuees. So I agree completely with your request that we better define roles. But simply defining roles won't solve the hard problem, which is that we need graduated Disclosure and that requires defining a Disclosure transaction that is a supporting layer to the VCDM.

[David-Chadwick]

@RieksJ "Can you perhaps provide a realistic, real-world example, that demonstrates that actual (not theoretical) need of the proposal, and also some arguments that convincingly show there's no viable alternative?" If you look through the plastic cards in your physical wallet you will see some of them that state "not transferrable" or similar. The inclusion of the issuee field, with the same id as the holder who presents the VP, unambiguously shows that the VC has not been transferred since issuance (regardless of the subject). Subject=holder does not unambiguously show who the issuer issued the VC to, only that the subject of the VC is the current holder.

[RieksJ]

@David-Chadwick I understand your example of a card being "not transferrable" to be a situation in which a verifier can establish that the person presenting the card is the one from which the card should not be transferred. I don't see how that necessarily implies that the card could not be transferred to that person (i.e.: MUST have been issued to that person). It's perfectly ok for my wife to pick up a non-transferrable card that only I could use. True, an issuer may decide to limit its issuing process such that the card would only be issued to the person to which it pertains, but they would also issue it to another person provided (s)he is mandated by the first person to collect it.

An alternative, more generic solution is proposed in #760.

[awoie]

The proposal is about introducing a new role issuee that is inserted by the issuer at the time of issuance. IMO, this can be a part of the larger holder binding feature. imo, we could define such a new normative role including an optional property in the VC that can be used by the verifier to verify the link between the presenter, the VCs and the issuee of the VC. I'm supportive of this property as long as it can be kept flexible enough to support other issuee types than cryptographic identifiers such as DIDs. I would assume there could be a registry approach that allows registration of issuee types where each type definition explains how the link between the presenter, the issuee material and the VP can be verified to enable verifiers to enforce certain policies..

[David-Chadwick]

I propose that the issuee is an object, in the same way that issuer and subject is. So in effect, it can contain any properties such as id, type etc

[TallTed]

[@David-Chadwick] I propose that the issuer is an object, in the same way that issuer and subject is.

Probably that's meant to propose that the issuee is an object?

[SmithSamuelM]

In ACDC we normatively define an optional Issuee identifier. The Issuer of an ACDC may designate an Issuee by including the Issuee identifier in the Issuee field. The semantics of what the Issuee represents is ACDC dependent. But the structure of having a normative Issuee enables things like delegation for example.

ACDC chaining normatively recognizes a chain of Issuer to Issuee to Issuer and so forth via its normative edges. For example. If The Issuer of a given ACDC designates an Issuee. And then another ACDC chains to that given ACDC and the Issuer of this latter chaining ACDC is also the Issuee of the given chained ACDC then there is a normative structural verifiable relationship from the Issuee of one ACDC as the Issuer of another ACDC. This structure can be used as the basis of a delegation chain or chain of authority or chain of authorization. The chaining ACDC can require an unbroken chain or not via a given edge. This is a property of the edge. Edges have properties that make it easier to lock down the tooling for verifying the structure of a chained or treed set of ACDCs.

The semantics of the chain is ACDC dependent. What is normative is the chaining structure. To make it easier on the tooling for verifying chains we don't allow the Issuee or Issuer fields to be objects but instead have ancilliary objects that can provide additional properties when needed. The normative JSON schema required for each ACDC makes it clear what all the fields represent nonetheless. The edges themselves can specify the schemas for linked ACDCs so the whole chain can be structurally verified and issuance proofs verified (and when applicable, presentation proofs verified) before any business logic on the values need ever be applied.

[David-Chadwick]

@SmithSamuelM Since issuer is already an object in the VCDM, then it makes sense that issuee is also an object. Getting their ids is not a problem. It is simply issuer.id and issuee.id. So I see no reason to separate the ids out from the objects.

[SmithSamuelM]

@David-Chadwick Yes, given that an Issuer is an object, consistency would say also make the Issuee an object. But you overlooked the fact that in ACDC, neither the Issuer nor Issuee is an object. They are identifiers. A better approach would be to make both identifiers. I.e Not make the Issuee an object merely because the Issuer is also an object. This is just repeating the same layering violation.
In a layered approach, one does not include stuff (i.e. other properties) in a lower layer unless that stuff is absolutely essential to the function of that layer. Flexibility, in this case, is not beneficial. So in ACDC, we cleanly separate what we need for proof of issuance from other claims about the issuer, should there be any. IMHO The current VC model suffers poorly because it does not follow good layering practices. One of the sure signs of breaking layering is allowing unessential data to leak into a layer. The current VC model is filled with such layer violations because it intentionally flattens layers it should not flatten (IMHO).

[RieksJ]

@awoie: you're faster than I could update my post above, in which I added that it seems natural for a party that creates a scheme/context for bachelor degrees to not only define the fields for the degree, but also the issuee field, because that party would recognize the value of having it. No need to standardize this up-front. My guess is that if it turns out to be important, there will be a de-facto 'standard', or it will get in later in the VCDM (or whereever else)

[awoie]

@awoie: you're faster than I could update my post above, in which I added that it seems natural for a party that creates a scheme/context for bachelor degrees to not only define the fields for the degree, but also the issuee field, because that party would recognize the value of having it. No need to standardize this up-front. My guess is that if it turns out to be important, there will be a de-facto 'standard', or it will get in later in the VCDM (or whereever else)

IMO, the issuee field would have to be defined by some other party since the term might be used with bachelor degrees or something completely else like a driving license. It is important who provides the vocab and who defines the IRI for the term because this is how semantic interop is established. If every party hosts their own vocab and defines with their own IRIs then this is fine but all of them include one for issuee it would semantically always mean something different. Which is why we are creating a VCDM vocab in W3C to allow parties to reuse those terms.

[RieksJ]

I didn't think I was suggesting that every issuer of a bachelor degree would specify its own vocab. Apart from that, it also would not work, because verifiers would have a difficult time creating presentation requests if every issuer would create and maintain its own schemes for every kind of credential it would issue.

I think that different domains (already!) have their own schemes that somehow are used by most, if not all, parties in that domain. If the issuee field isn't specified in the "https://www.w3.org/2018/credentials/v1" scheme, it might well be defined in the scheme that is specific for the domain, if the parties that control that scheme do find it useful. Would that be unrealistic?

[David-Chadwick]

The proposal is that the issuee property is an optional property that is specified in the VCDM so that those implementations that want to use it can use it. There are a significant number of WG members who would like this property to be standardised. There does not need to be a majority of the WG in favour of using this property because it is optional. But if is a minority of WG members stop concensus being reached then they are effectively vetoing what the majority would like. Therefore I propose that a vote be taken to see how many WG members would like this optional property to be defined and how many members would not like it to be defined.

[OR13]

I don't believe we should do this, and I believe this issue should be closed.

[brentzundel]

chair hat off, I don't believe we should do this, and I believe this issue should be closed.

[TallTed]

I have no argument against creation of issuee, and some small support for its creation, as I believe that may prevent some number of further trips around the track we've already trod several times in other issues.

[iherman]

The issue was discussed in a meeting on 2023-07-12

• no resolutions were taken

View the transcript

5.6. Create the new role of issuee (issue vc-data-model#942)

See github issue vc-data-model#942.

Brent Zundel: recommends, creation of a new role.
… issuee, assigned to oliver.

Manu Sporny: -1 to a new role.
… every time we try, everyone seems to push back.
… not clear we need a new role, seems more non normative text would help, and this could be post PR.
… we can explain the behavior better in post CR.

Brent Zundel: POLL: Should we create a new 'Issuee' role?

Manu Sporny: -1 to new issuee role.

Oliver Terbu: -1.

Brent Zundel: -1.

Joe Andrieu: -1.

Ivan Herman: 0.

Dave Longley: -1.

Phillip Long: -1.

Orie Steele: -1 to new issuee role.

Ted Thibodeau Jr.: 0.

Gabe Cohen: -1, but think we should clarify "holder".

Kevin Griffin: 0.

Brent Zundel: seems we should do this post CR, with editorial changes.

Manu Sporny: correct.

Brent Zundel: 13 open issues not triaged remain.
… we need to keep making progress.
… if you want to demo during TPAC, contact the chairs.

---

[brentzundel]

changing the name of the issue to reflect the current plan to add non-normative text better clarifying holder

[iherman]

The issue was discussed in a meeting on 2024-01-17

• no resolutions were taken

View the transcript

2.5. Clarify role of Holder (was: Create the new role of issuee) (issue vc-data-model#942)

See github issue vc-data-model#942.

Brent Zundel: Is there still clarification around the role of holder that is necessary?
… I feel pretty confident about what a "holder" is...
… Do we need to do anything or close it?

Manu Sporny: +1 to close it, don't need more.

Brent Zundel: Anyone on call opposed to pending close?
… Hearing no opposition, I'll mark it "pending close".

[TallTed]

changing the name of the issue to reflect the current plan to add non-normative text better clarifying holder
... I feel pretty confident about what a "holder" is...

I don't think this issue has ever been about clarity about the "holder" role. It's about the initial holder, the "issuee", the original recipient from the "issuer".

If we specify (or at least, reserve) an "issuee" property, a number of concerns that are discussed in the VERY LONG thread above will be resolved (or at least, set up for resolution) for all implementers/users. I think that would be a win.

I am concerned that if we don't specify (or at least, reserve, with some non-normative description of the expected future specification), multiple implementers will each implement something different for the same purpose, and so not interoperate on that purpose. I think that would be a lose.

[agropper]

A standard largely built on a chain-of-custody assumption has incalculable unintended consequences. As Ted and others have said, we have choices. Formally discussing and documenting the chain-of-custody model for VCs by defining terms such as "issuee" is a step in the right direction. Adrian

…

On Thu, Jan 18, 2024 at 3:33 PM Ted Thibodeau Jr ***@***.***> wrote: changing the name of the issue to reflect the current plan to add non-normative text better clarifying holder ... I feel pretty confident about what a "holder" is... I don't think this issue has ever been about clarity about the "holder" role. It's about the *initial* holder, the "issuee", the original recipient from the "issuer". If we specify (or at least, reserve) an "issuee" property, a number of concerns that are discussed in the VERY LONG thread above will be resolved (or at least, set up for resolution) for all implementers/users. I think that would be a win. I am concerned that if we *don't* specify (or at least, reserve, with some non-normative description of the expected future specification), multiple implementers will each implement something *different* for the same purpose, and so not interoperate on that purpose. I think that would be a lose. — Reply to this email directly, view it on GitHub <#942 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YMEJTGXLYDXU33L3JDYPGBKBAVCNFSM6AAAAAAQ5XAVN2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJZGE3DGOJSHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jandrieu]

I don't understand what you're getting at Adrian. VCs are not built on chain-of-custody. They are built on attestations. Those attestations can be independently verified. And in some use cases the presenter can cryptographically establish assurances that they are the subject. There is no "chain" involved.

…

-j

On Thu, Jan 18, 2024, at 5:35 PM, Adrian Gropper wrote: A standard largely built on a chain-of-custody assumption has incalculable unintended consequences. As Ted and others have said, we have choices. Formally discussing and documenting the chain-of-custody model for VCs by defining terms such as "issuee" is a step in the right direction. Adrian On Thu, Jan 18, 2024 at 3:33 PM Ted Thibodeau Jr ***@***.***> wrote: > changing the name of the issue to reflect the current plan to add > non-normative text better clarifying holder > ... I feel pretty confident about what a "holder" is... > > I don't think this issue has ever been about clarity about the "holder" > role. It's about the *initial* holder, the "issuee", the original > recipient from the "issuer". > > If we specify (or at least, reserve) an "issuee" property, a number of > concerns that are discussed in the VERY LONG thread above will be resolved > (or at least, set up for resolution) for all implementers/users. I think > that would be a win. > > I am concerned that if we *don't* specify (or at least, reserve, with > some non-normative description of the expected future specification), > multiple implementers will each implement something *different* for the > same purpose, and so not interoperate on that purpose. I think that would > be a lose. > > — > Reply to this email directly, view it on GitHub > <#942 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AABB4YMEJTGXLYDXU33L3JDYPGBKBAVCNFSM6AAAAAAQ5XAVN2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJZGE3DGOJSHE> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#942 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABNTT4SZLHSOERG6EUA65LYPHEVXAVCNFSM6AAAAAAQ5XAVN2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJZGQ4TIMZZGA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Joe Andrieu, PMP ***@***.*** +1(805)705-8651 http://blog.joeandrieu.com

[agropper]

I agree with you, Joe. As you say, there are subjects and presenters. Holders should be irrelevant and using the term instead of using presenter is imprecise and confusing. It leads to thinking that DHS, for example, might not issue a VC to a wallet or other user agent compiled from source by a subject. If so, what's the difference between a certified wallet and chain-of-custody? Adrian On Thu, Jan 18, 2024 at 10:44 PM Joe Andrieu ***@***.***> wrote:

…

I don't understand what you're getting at Adrian. VCs are not built on chain-of-custody. They are built on attestations. Those attestations can be independently verified. And in some use cases the presenter can cryptographically establish assurances that they are the subject. There is no "chain" involved. -j On Thu, Jan 18, 2024, at 5:35 PM, Adrian Gropper wrote: > > > A standard largely built on a chain-of-custody assumption has incalculable > unintended consequences. As Ted and others have said, we have choices. > Formally discussing and documenting the chain-of-custody model for VCs by > defining terms such as "issuee" is a step in the right direction. > > Adrian > > On Thu, Jan 18, 2024 at 3:33 PM Ted Thibodeau Jr ***@***.***> > wrote: > > > changing the name of the issue to reflect the current plan to add > > non-normative text better clarifying holder > > ... I feel pretty confident about what a "holder" is... > > > > I don't think this issue has ever been about clarity about the "holder" > > role. It's about the *initial* holder, the "issuee", the original > > recipient from the "issuer". > > > > If we specify (or at least, reserve) an "issuee" property, a number of > > concerns that are discussed in the VERY LONG thread above will be resolved > > (or at least, set up for resolution) for all implementers/users. I think > > that would be a win. > > > > I am concerned that if we *don't* specify (or at least, reserve, with > > some non-normative description of the expected future specification), > > multiple implementers will each implement something *different* for the > > same purpose, and so not interoperate on that purpose. I think that would > > be a lose. > > > > — > > Reply to this email directly, view it on GitHub > > < #942 (comment)>, > > or unsubscribe > > < https://github.com/notifications/unsubscribe-auth/AABB4YMEJTGXLYDXU33L3JDYPGBKBAVCNFSM6AAAAAAQ5XAVN2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJZGE3DGOJSHE> > > . > > You are receiving this because you were mentioned.Message ID: > > ***@***.***> > > > > — > Reply to this email directly, view it on GitHub < #942 (comment)>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AABNTT4SZLHSOERG6EUA65LYPHEVXAVCNFSM6AAAAAAQ5XAVN2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJZGQ4TIMZZGA>. > You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> > -- Joe Andrieu, PMP ***@***.*** +1(805)705-8651 http://blog.joeandrieu.com — Reply to this email directly, view it on GitHub <#942 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YIET3V7FUAE3REMVLLYPHT2FAVCNFSM6AAAAAAQ5XAVN2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJZGY2DKMBVGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[brentzundel]

As @TallTed rightly points out, this thread is primarily about whether or not to add the role of Issuee
It is my opinion that we currently do not have consensus to add this role, but I'm happy to be proven wrong.

If there is clear consensus within 7 days that the group wants to add or reserve Issuee, then we can continue working toward resolving this issue with a PR, otherwise I am going to close it.

[TallTed]

@brentzundel changed the title Calrify role of Holder (was: Create the new role of issuee) Clarify role of Holder (was: Create the new role of issuee) on Jul 13, 2023

Perhaps the title change should be reverted (back to Create the new role of issuee), given

this thread is primarily about whether or not to add the role of Issuee

[TallTed]

(for the future)

Issuee is a shadow-role, filled by the first Holder who gets a VC from an Issuer.
Presenter is likewise a shadow-role, filled by the Holder who presents a VP to a Verifier.

[iherman]

The issue was discussed in a meeting on 2024-01-31

• no resolutions were taken

View the transcript

2.5. Create the new role of issuee (issue vc-data-model#942)

See github issue vc-data-model#942.

Brent Zundel: As I recall things, please correct me ... as I recall things, we did not come to consensus as a group about creating the new role of Issuee. It was proposed to the group, we had long conversations about it, but ultimately the group could not come to agreement on doing this.
… As Kristina mentioned with her comment -- there was no consensus in the group for that. The issue was then adjusted to be about adjusting the holder property to talk a little bit about it. This conversation has gone on for a long time and my recollection is we don't have consensus to add Issuee as a new role...

Manu Sporny: agree w/ brent's summary.

Brent Zundel: ... and unless everyone on this call disagrees then I'm happy to close it out.

Joe Andrieu: Thanks, the main issue --- I wanted to bring it up and let David have this moment to try and speak against it.

Manu Sporny: To underscore ... I agree with your recollection, Brent, I think that's where the group is and wouldn't personally want a new role in the ecosystem.

Dave Longley: I didn't think it made sense as a role, but perhaps a property.

Brent Zundel: The extension model allows issuee to be added as a property.

David Chadwick: Can we please record that this role has always existed.

Brent Zundel: I appreciate your view on this but it's not mentioned by name as a role in the spec, so it's a new role.

David Chadwick: Just because it wasn't listed doesn't mean it hasn't existed. The issuer has always issued the credential to the issuee, it's just English grammar if you like, it's just not documented as such.

Ted Thibodeau Jr.: issuee is a shadow-role, filled by the first holder who gets a VC from an issuer.

Brent Zundel: I appreciate that perspective and I disagree with it, my chair hat off, as a contributor, I don't think that's the case.

Ted Thibodeau Jr.: As I said in a few places, included in that issue, I don't have anything against defining this term, whether it's fully defined and in the spec or just reserved and I would suggest reserving that label issuee for future use. It does always exist and has existed as David says, we haven't highlighted it.

David Chadwick: Thankyou Ted.

Ted Thibodeau Jr.: It's just the first holder of the VC.
… Having it, would resolve some issues to address some issues that are elsewhere in these documents and we've gone in circles because we didn't have this term to use.

Manu Sporny: I'm still a -1 to add this, I get what both David and Ted are saying, yes the concept has always existed since the dawn of time since the first VC was issued by an issuer and handed to the first holder, the issuee.
… I don't think we have consensus, a strong -1 to add this at this time, I don't think it's helpful.

Joe Andrieu: I'm a -1 as well, the vernacular fact that you might refer to the first holder as an issuee doesn't create a new role, they are still a holder. Adding it as a role to the list of roles would make it a new role. When the holder presents a VC we could call them a presenter, but that doesn't mean we add it as a role, as it confuses the simple 3-party model that highlights the difference with VCs and previous phone-home architectures.

[David-Chadwick]

I would rather say that the issuee role is a subclass of the holder role. All issuees are holders, but not all holders are issuees.

[OR13]

Please do not add another role.

[brentzundel]

I am still seeing no consensus to add the Issuee role. I am therefore closing this issue.