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](https://github.com/w3c/vc-data-model/issues/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.

[TallTed]

There's a gordian (cough) tangle between #942, #1054, #821, #902, and maybe others. I don't think that any of these can be resolved on its own.

This may warrant a special topic call. Though, it might still be too soon for that.

issuee is at least more than a boolean (unlike nonTranferable)!

issuee identifies an entity, just as any means of attaching a VC to a specific holder would have to do. Strong AuthN is needed for all related interactions — getting a VC issued, presenting that VC, presenting a VP derived from that VC, etc. — regardless of what property/ies is/are used to identify that entity nor what mechanism(s) is/are then used to prove, confirm, or increase confidence that the entity trying to do whatever (receive, present, etc.) is such an identified entity.

[awoie]

_There's a gordian (cough) tangle between #942, #1054, #821, #902, and maybe others. I don't think that any of these can be resolved on its own._

This may warrant a special topic call. Though, it might still be too soon for that.

issuee is at least more than a boolean (unlike nonTranferable)!

issuee identifies an entity, just as any means of attaching a VC to a specific holder would have to do. Strong AuthN is needed for all related interactions — getting a VC issued, presenting that VC, presenting a VP derived from that VC, etc. — regardless of what property/ies is/are used to identify that entity nor what mechanism(s) is/are then used to prove, confirm, or increase confidence that the entity trying to do whatever (receive, present, etc.) is such an identified entity.

@TallTed I don't understand where the strong authN requirement comes from for all "related" interactions. Can you elaborate why you think there is this requirement? We haven't defined issuee yet and the only definition of issuee is that the issuer indicates the first holder using that property. I cannot see why this would require strong authentication in all cases? IMO, whether or not strong authentication is used is a verifier decision, not a issuer's decision. I wouldn't object to issuee but I cannot see the need for it and I don't think it is required for holder binding/confirmation method.

[TallTed]

"Holder binding" is at best a misnomer, and at worst misleading in ways that I think are likely to break multiple security features of VC infrastructure. PLEASE stop using it.

"Confirmation method" is not far from "holder binding". It does not provide "confirmation" in the ways that users are all-but-certain to believe it does, by which I mean "confirmation" of one or more assertions in the payload. It doesn't matter how we officially define this thing; the label "confirmation" will carry implicit though unintended meaning. Please also stop using this label.

If you want to "bind" (or, I think better, "restrict presentation or other use of") a VC to a specific holder, you need a way for that specific holder to be authenticated. If you want them to be the initial holder, to whom the VC is initially issued, then that AuthN is required at issuance. Regardless of what holder you want to restrict this VC to, strong AuthN is required when they try to present or otherwise make use of it. Yes, the verifier may choose not to use strong AuthN but they must equally have the ability to choose/require strong AuthN, which means it must be possible to achieve.

The above is mostly just a rephrasing of my prior writing, which you quoted, but may not have read or understood fully. Maybe the rephrasing delivers better understanding?

[SmithSamuelM]

As many of you already know, in layered protocol design one guiding design principle is that each layer do one thing and one thing well. This becomes even more important when that one thing is related to some security property, like secure attribution (authentication) or entitlement (authorization). The reason is that any ambiguity, optionality, or flexibility in that one thing becomes an avenue for attack. We want to isolate the function of the layer in as tight and locked down manner as possible. We want to clearly identify its dependencies and make sure there is no equivocation about the semantics of those dependencies. This usually means that we precisely define the function of the layer which includes precisely defining the data that belongs in the layer because it's the data the function depends on. Mixing data from other layers is not precision. Mixing functionality from other layers is not precision. So the easy layer violations are when we mix data and functionality from multiple layers into each other. So flattening layers is the opposite of precision and one flat layer is antithetical to the goals of layered protocol design.

The foregoing does not mean that higher layers can't share information. The same dependency might be a dependency for multiple layers so it might be shared or copied depending on how data is managed across layers. But each layer isolates its dependencies.

The VC data model is not a layered design. One can interpret it in a layered fashion but that interpretation is not universal and hence can't be depended on, so its not precise and as a result interoperability suffers.

Clearly a VC must have an issuer. But we don't precisely define what that means. We have an issuer object that can have multiple fields and the meaning of those fields is not precisely defined, nor are the set of fields.

But cryptographically if we want to prove something was issued by an Issuer i.e. make secure attribution of the VC. Then there are only so many ways we can do that and none of them require multiple fields or not at least any fields that are extraneous to the cryptographic algorithm used to prove issued by an Issuer where the Issuer is a cryptographically derived identifier. A cryptographically derived identifier is necessary and sufficient. So even allowing the concept of an Issuer object is a layer violation when the layer's function is to prove issued by an Issuer where the Issuer is a cryptographically derived identifier. There may be other layers that need to know other things about the issuer besides prooving cryptographically issued by but those layers are free to add that information but it is a layer violation to include it in the secure attribution layer.

An Issuee on the other hand is not needed to prove Issued-Bybut to prove Issued-To. A cryptographic proof of issued to needs no other information that the cryptograhically derived identifier of the Issuee as the target of the issued-to, i.e secure targeting of the issuance. The Issuee identifier is necessary and sufficient. Any other information about the Issuee is extraneous to the function of the Issued-too secure targeting layer. So having an Issuee has an object with other fields is a layer violation. Other information about the Issuee may be needed by the functions of other layers so it belongs in those layers but not in the secure targeting layer.

Given that we have a secure target identifier (Issuee) we can add other layers like an entitlement layer (authorization) that provides the functionality of a delegation or authority to the Issuee. One use of such a layer is for the Issuee to present cryptographic proof of control of the Issuee identifier in order to realize the entitlement. This could be done by the Issuee signing the presentation of the entitlement that was originally signed by the Issuer that granted the entitlement.

Other proofs of authenticity may be required in some circumstances and those proofs may beprovided out of band or in band but by a different layer. But usually, all other proofs depend on the cryptographic proof as the first factor.

Its very clear that holder ambiguity can be disambiguated in most cases because what we are calling the holder is in those cases really a target identifier that is the Issued To Identifier. In many of those cases the Issuee is a grantee of an entitlement but that is provided by yet another layer.

In some cases, the so called holder is not targeted, but then the semantics of a presenter who is not a target must be solved with some other mechanism. And usually that is Oout of Band to the VC itself. Hence the ambiguity.

But an Issuee solves 90% of the seminal use cases (at least).

[SmithSamuelM]

One of the strongest reasons to use layering in security directed protocol is to support granular confidentiality and privacy of the information. When layers are flattened then its pathologically problematic to simultaneously make authenticatable cryptographic commitments to data that has granular disclosure properties where those properties are also enforced cryptographically.

[David-Chadwick]

@SmithSamuelM Given that you view the VCDM is not a layered design, it is at least consistent in regarding the issuer and the subject (and potentially the issuee) as objects rather than identifiers. The cryptographic security layer can use the identifiers of these objects to validate them, and then higher layers can use their other properties such as name, logo, website, photo etc for other purposes, e.g. to help humans identify the object that has a particular identifier. Wouldn't we only need the VCDM to describe how these various properties are used in order to introduce your layering concept into the VCDM?

[awoie]

An Issuee on the other hand is not needed to prove Issued-Bybut to prove Issued-To. A cryptographic proof of issued to needs no other information that the cryptograhically derived identifier of the Issuee as the target of the issued-to, i.e secure targeting of the issuance. The Issuee identifier is necessary and sufficient. Any other information about the Issuee is extraneous to the function of the Issued-too secure targeting layer. So having an Issuee has an object with other fields is a layer violation. Other information about the Issuee may be needed by the functions of other layers so it belongs in those layers but not in the secure targeting layer.

@SmithSamuelM This is not the approach the VCDM has chosen so far. The VCDM works also without cryptographically derived identifier for subject, holder and issuer. I assume the same would apply to issuee if we decide to add that property. Are you saying, you do want to have an issuee property in the VCDM? If this is the case, we need a use case first that justifies this new field and then we need concrete proposed language (I still don't know what language that might be).

1. What would be the use case and why does the current VCDM not work for that? @SmithSamuelM @David-Chadwick
2. What would be the semantic definition of the issuee property? @SmithSamuelM @David-Chadwick

[awoie]

@SmithSamuelM Also given that we follow the same approach as with other properties in the VCDM and a potential issuee property would be an object, then confirmationMethod could be a property of that object. Then, that object could have one confirmation method based on a cryptopgrahic identifier which should address your use case. Would you agree with that?

[agropper]

There were a number of relevant sessions at IIW last week. Some sessions discussed the impact of biometrics as they become good enough for a hash (or hashes) to be used as identifiers in a VC (and also as enhanced with AI for liveness detection).

The session Delegatable Verifiable Credentials was called by Phil Windley, Alan Karp, Sam Smith https://docs.google.com/document/d/1p7FQxemoqFvgfWqU5WkJs31upLQ5ivQepwKLQBhgItY concluded with: "It's very difficult to bolt-on delegation."

There's only so much that can be done within the VC and DID data models before complexity, unintended consequences, and the reality that biometrics are essentially public makes the issuee discussion irrelevant.

On Mon, Apr 24, 2023 at 8:23 AM Oliver Terbu @.***> wrote:

@SmithSamuelM https://github.com/SmithSamuelM Also given that we follow the same approach as with other properties in the VCDM and a potential issuee property would be an object, then confirmationMethod could be a property of that object. Then, that object could have one confirmation method based on a cryptopgrahic identifier which should address your use case. Would you agree with that?

— Reply to this email directly, view it on GitHub https://github.com/w3c/vc-data-model/issues/942#issuecomment-1520058730, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YMB6VOBMW3OQERRSO3XCZWFFANCNFSM6AAAAAAQ5XAVNY . You are receiving this because you commented.Message ID: @.***>

[David-Chadwick]

@awoie Here is a use case. A rather expensive pet (the VC subject) is given a series of injections allowing it to travel between countries (i.e. a so-called pet passport). The VC cannot be issued to the pet itself. The owner, being the one an only owner, wishes the VC to be issued to herself. The issuer inserts the issuee property (an object) into the VC, which includes details about the owner. Now the owner can present her own passport and that of her pet when she travels abroad and passport control will know that she is the rightful possessor of the pet's VC. The owner, knowing there is a black market in expensive pets, is pleased that no-one is able to steal her pet and pass themselves off as the holder.

Now this could be modelled by creating an owner object, instead of using the generic issuee object, but because the issuee is generic it can be used for any type of relationship that the holder/issuee has to the subject. If we preferred to define the owner object, we might also need to define the parent object, grand parent object, spouse object etc.

Another similar use case is for a new borne baby. In this case the issuer may issue two VCs for the baby with different issuee properties, one for each of the baby's parents. This would ensure that only the parents can present the baby's VC and have it verified that they are the rightful original holders of it.

A proposed semantic definition of the issuee property is "This optional property MAY be inserted into the VC by the issuer to indicate the entity to whom the VC was issued, when this entity is not the subject of the VC".

[David-Chadwick]

@agropper the reality that biometrics are essentially public makes the issuee discussion irrelevant. I don't believe this is correct. We have known for over a decade that biometrics are public and that the essential test is one of liveness i.e. is the biometric being presented coming from a live person and is not some digital copy. Thus providing the holder is being tested for a live biometric and this matches the biometric in the issuee property, then we can be assured that the holder is the issuee.

[wip-abramson]

@David-Chadwick is it not possible to address these use cases with the confirmationMethod (or whatever we end up calling it) property?

E.g. for the pet usecase the credentialSubject object defining the pets immunity record would include a confirmationMethod for the owner of the pet including passport details that can be checked when the owner crosses the border with the pet.

I also do not think there is any guarantee that the issuee is the owner. Don't we get back to a similar hand wavy problem that confirmationMethod was intended to address? That we need some way to confirm / gain confidence in the relationship between some entity presenting a VP and the subject of the credential(s) being presented.

I think @awoie touched on this is the CCG call.

[David-Chadwick]

It's a question of semantics. Is information about the holder (who is not the subject) correctly identified as subject properties or not? I would say not. I think it is fine to have holderBinding/confirmationMethod as a property of the subject when holder=subject, but not when holder NE subject. holderBinding/confirmationMethod can still be used, but as a property of the issuee, not of the subject

[agropper]

Claims about a subject (the sky is blue, the pet is vaccinated, the human is present) are easy. We seem to be trying to give the issuer other powers beyond claims. The power to:

• declare a relationship
• call home - as in paying a tax for each NFT transfer
• restrict use to certain situations

These are all ways to constrain the use of the credential. There's nothing wrong with that except that it enhances the power of the typically institutional issuer and reduces the power of the individual recipient of the VC. This will lead to a galaxy of unintended consequences because the power imbalance is almost always with the issuer and verifier.

I suggest we make VCs simpler.

[awoie]

It's a question of semantics. Is information about the holder (who is not the subject) correctly identified as subject properties or not? I would say not. I think it is fine to have holderBinding/confirmationMethod as a property of the subject when holder=subject, but not when holder NE subject. holderBinding/confirmationMethod can still be used, but as a property of the issuee, not of the subject

In a lot of online use cases it is not required to know who is the issuee, it is only required whether the holder is the authorized party or can satisfy one of the confirmation methods.

[TallTed]

[@awoie] The VCDM works also without cryptographically derived identifier for subject, holder and issuer. I assume the same would apply to issuee if we decide to add that property.

But you suddenly want cryptographic material to be used for your version of the absolutely misnamed holder binding functionality? This seems more than a little inconsistent!

[TallTed]

[@David-Chadwick] ... A rather expensive pet (the VC subject)... two VCs for the baby ...

Neither of these are good use cases for VCs nor for any properties thereof. Both usage scenarios go FAR afield of what we've defined VCs to be capable of, and dive deeply into questions of pet ownership and birth-parental custody, neither of which is anywhere near as cut-and-dried as suggested by your comment. I don't think they shed much light on the potential utility of issuee, even if they were good VC use cases.

[awoie]

[@awoie] The VCDM works also without cryptographically derived identifier for subject, holder and issuer. I assume the same would apply to issuee if we decide to add that property.

But you suddenly want cryptographic material to be used for your version of the absolutely misnamed holder binding functionality? This seems more than a little inconsistent!

No, please review the PR #1054 . It is a framework for anything that can be used to achieve what you proposed as authorizedPresenter. The PR introduces a framework where cryptographic identifier are one of the options.

[David-Chadwick]

In a lot of online use cases it is not required to know who is the issuee, Then there is no need to use the property :-). The proposed definition is a MAY not a MUST. But just because one person does not need a feature (Evidence, ToU etc) does not mean that everyone does not need it :-)

[awoie]

In a lot of online use cases it is not required to know who is the issuee, Then there is no need to use the property :-). The proposed definition is a MAY not a MUST. But just because one person does not need a feature (Evidence, ToU etc) does not mean that everyone does not need it :-)

The VCWG should not invent or define new properties just because they make sense remotely. We should only add new properties to the vocab if we have enough implementation experience for a specific feature. I cannot see that this is the case for issuee. We would end up in a way more bloated vocab if we did. Implementer's can define issuee in their own @context which is the logical extension mechanism for new terms like that.