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 https://github.com/w3c/vc-data-model/issues/942#issuecomment-1268756347, 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).

[iherman]

The issue was discussed in a meeting on 2023-04-04

• no resolutions were taken

View the transcript

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

See github issue vc-data-model#942.

Kristina Yasuda: By DavidC. Anyone willing to take this one?.

David Chadwick: I don't think holder binding solves this issue, because holder binding is part of credential subject. My issue is about the "issuee"..
… An issuer should be able to say who he issued the credential to, if it's not the subject..

Oliver Terbu: We definitely need to revisit this and compare it, and find out if the current proposal works for the issue. In that case we should get more clarity on the use case, otherwise the need for the new property isn't clear..
… You can assign me, and I will find out.

[TallTed]

[@SmithSamuelM] The current VC model is filled with such layer violations because it intentionally flattens layers it should not flatten

I (and I presume, the other members of the VCWG) would appreciate it if you could spell out the layers and problematic flattenings you see, in one or more focused issues, along with any suggestions you might have toward un-flattening and otherwise fixing them.

[agropper]

I too hope we have a discussion of the layers and potential problems.

For example, verifiable credentials must not impede delegation either for issue or verification.

[SmithSamuelM]

@TallTed

I (and I presume, the other members of the VCWG) would appreciate it if you could spell out the layers and problematic flattenings you see, in one or more focused issues, along with any suggestions you might have toward un-flattening and otherwise fixing them.

Will do!

[awoie]

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.

@David-Chadwick Can you describe a use case that requires us to define this new issuee property? If we cannot come up with a use case that requires issuee as a new property, I'd say we should close this issue since I couldn't see support for this property in this discussion so far.

[TallTed]

I think that issuee can deliver what many are wanting to get from the mis-named "holder binding". issuee can be defined simply, as the "initial holder to whom the issuer issues a VC". issuee (or something similar) can be a property (metadata) of the VC, and/or it can be a claim/assertion within the VC (i.e., part of the payload). A verifier can check that the holder entity presenting the VC/VP (a/k/a the presenter, simply defined as "the holder who presents a VP/VC to a verifier") is identified as the same entity specified as the issuee, as part of the verifier's business logic.

[awoie]

I think that issuee can deliver what many are wanting to get from the mis-named "holder binding". issuee can be defined simply, as the "initial holder to whom the issuer issues a VC". issuee (or something similar) can be a property (metadata) of the VC, and/or it can be a claim/assertion within the VC (i.e., part of the payload). A verifier can check that the holder entity presenting the VC/VP (a/k/a the presenter, simply defined as "the holder who presents a VP/VC to a verifier") is identified as the same entity specified as the issuee, as part of the verifier's business logic.

@TallTed Are you proposing to use issuee instead of what is proposed in PR #1054 ? Or do you want to combine what is proposed in PR #1054 with the issuee property? I cannot see how issuee without additional info can provide information to the verifier that can be used to validate that the presenter is the issuee and not somebody who just copied the VC.