Define "prover" in addition to "holder".

[OR13]

Everyone with access to plaintext is a holder... so the term provides very little value.

In protocols, very often the issuer is the first holder, and then they present to a second holder who is often a subject.

This second holder will then present to a verifier.

• Issuers issue credentials.
• Provers present credentials using presentations.
• Verifiers verify presentations.
• Holders are anyone who sees a credential.

Holder lacks implied directionality, in practice it has been used to root the direction arrow between a subject and a verifier.

Holder: <-> Prover (sender): -> Verifier (receiver): <-

The lack of directionality in the term holder makes it a dangerous term for protocols to rely on, unless the protocol is really intending for no directionality to be implied... which is not the case with the term today, since its only defined in the context of Verifiable Presentations which has a directionality towards a verifier... from a holder.

[agropper]

We might consider:

• Adopting the Terminology from the RWOT11 paper https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/final-documents/identifier-binding.pdf

then

• Discuss the choice of a VC-centric vs. a User-centric approach. Make it clear why we picked one over the other.

If we choose a user-centric approach then all VC interactions look like a Request-Response where an entity either:

• requests a VC based on presenting claims including other VCs or

• requests a service based on presenting claims including a VC

• Adrian

On Mon, Feb 13, 2023 at 11:25 AM Kristina @.***> wrote:

having read the thread, I would suggest proceed as following:

• first discuss whether to break down what is currently one entity "holder" into multiple entities
• if yes, what would be the break down? suggestions seem to be three entities: an entity that receives, an entity that holds, and an entity that presents a VC. what are the terms/definitions for the new terms/
• if no, is there a need to normatively define "holder"

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

[David-Chadwick]

"break down what is currently one entity "holder" into multiple entities"

I am strongly in favour of this. But I think that only two entities are needed, the entity that receives the VC from the issuer and the entity that presents the VC to a verifier. Any entity that either receives or presents a VC must be one of these two entities (or the issuer or verifier). Therefore the holder is never actually visible as a separate entity so we can dispense with this role

[RieksJ]

@David-Chadwick I agree that we need two roles to replace the current holder role. However, since VCs can be transferred in their own right, that is: not as part of a VP, we may need to decide how to refer to the role of an entity that doesn't issue a VC, but simply passes it on as is.

There are many use-cases for this: a simple one is where I, as an employee of the organization TNO, may want to pass on a credential with my name and address to TNO's traveling department so that they can book a flight with me being the passenger, which is the SSI parallel of me handing (a copy of the personal page in) my passport to that travel department (which I trust to not do anything else with it). This is very much in line with the idea that is often voiced by @jandrieu that anyone can hold VCs (that contain claims) about anyone/anything else.

[David-Chadwick]

Hi Rieks

On 14/02/2023 19:27, Rieks wrote:

  @David-Chadwick I agree that we
    need two roles to replace the current holder role. However,
    since VCs can be transferred in their own right, that is: not as
    part of a VP, we may need to decide how to refer to the role of
    an entity that doesn't issue a VC, but simply passes it on as
    is.

I completely accept the fact that anyone can hold any VC. That is
the VC model. The real issue the verifier has to verify, is: is the
holder entitled to hold and present this VC for the transaction in
hand, or did he just get it from somewhere, in which case the VC
should not legitimately be used for the current transaction.

  There are many use-cases for this: a simple one is
    where I, as an employee of the organization TNO, may want to
    pass on a credential with my name and address to TNO's traveling
    department so that they can book a flight with me being the
    passenger, 

Actually I don't think this is a realistic use case. My admin has
  often bought tickets for me and I have never given then a copy of
  my passport for them to do this. They know who I am as my details
  are in their database. Futhermore no airline requires to see a
  passport in order to sell anyone a ticket. I could buy an airline
  ticket for you today.

Kind regards
David

  which is the SSI parallel of me handing (a copy of
    the personal page in) my passport to that travel department
    (which I trust to not do anything else with it). This is very
    much in line with the idea that is often voiced by @jandrieu
    that anyone can hold VCs (that contain claims) about
    anyone/anything else.
  —
    Reply to this email directly, view it on GitHub, or unsubscribe.
    You are receiving this because you were mentioned.Message
      ID: ***@***.***>
  [

{ @.": "http://schema.org", @.": "EmailMessage", "potentialAction": { @.": "ViewAction", "target": "https://github.com/w3c/vc-data-model/issues/902#issuecomment-1429190718", "url": "https://github.com/w3c/vc-data-model/issues/902#issuecomment-1429190718", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { @.": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[mwherman2000]

Since these activities are distinct, it makes sense to make these roles distinct as well, and have different names for them.

@RieksJ Here's another approach: https://youtu.be/uo4RuT__IXw?t=575s

You may need to watch the following as background: https://youtu.be/uo4RuT__IXw?t=401s

In case you didn't have time to watch these video snippets: Here's a generalization of the Issuer-Holder-Verifier model that separates the Holder role into two separate specializations (derived roles):

1. A Holder as a specialization of the Credential Receiver role (receiving VCs from an Issuer - the latter being a different specialization of the Credential Sender role)
2. A Holder as a specialization of the Credential Sender role (sending VPs or VCs to a Verifier - the later being a different specialization of the Credential Receiver role)

Here's an example diagram...

Here's a example diagram of the generalized Credential Sender-Receiver model (which I think should be documented first in the spec to faciliate a follow-on explanation of the Issuer-Holder-Verifier model)...

[RieksJ]

@David-Chadwick wrote

The real issue the verifier has to verify, is: is the holder entitled to hold and present this VC for the transaction in hand, or did he just get it from somewhere, in which case the VC should not legitimately be used for the current transaction.

As a verifier, I have no clue how to determine whether or not the holder is entitled to hold and present a VP/VC/claim. Who provides such entitlements? Who enforces them?

From the perspective of a verifier, would an arbitrary person not be entitled to hold/present a VP/VC/claim about e.g. the right of a child to travel (by train, in an airplane, ...)? All the verifier cares about is whether or not the subject of that claim can be related to that child, regardless of who presents it.

I think the real issue is that verifiers need ways to determine who/what the subject of an identifier is (and by extension: of a claim). If the verifier has such a capability AND it chooses (for specific use-cases) to enforce a business-rule that states that it will only accept a claim when it is provided by its subject, it can easily do so.

[agropper]

This brings us back around to a long conversation almost two years ago in a thread labeled “ VC-HTTP-API - A follow up on the RAR presentation”

It’s the “Cruise-Ship Use Case” where Alice trusts the cruise line and the cruise line outsources verification and validation of Alice’s credentials to an expert that Alice cares nothing about.

Adrian

On Tue, Feb 14, 2023 at 4:53 AM Rieks @.***> wrote:

@David-Chadwick https://github.com/David-Chadwick wrote

The real issue the verifier has to verify, is: is the holder entitled to hold and present this VC for the transaction in hand, or did he just get it from somewhere, in which case the VC should not legitimately be used for the current transaction.

As a verifier, I have no clue how to determine whether or not the holder is entitled to hold and present a VP/VC/claim. Who provides such entitlements? Who enforces them?

From the perspective of a verifier, would an arbitrary person not be entitled to hold/present a VP/VC/claim about e.g. the right of a child to travel (by train, in an airplane, ...)? All the verifier cares about is whether or not the subject of that claim can be related to that child, regardless of who presents it.

I think the real issue is that verifiers need ways to determine who/what the subject of an identifier is (and by extension: of a claim). If the verifier has such a capability AND it chooses (for specific use-cases) to enforce a business-rule that states that it will only accept a claim when it is provided by its subject, it can easily do so.

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

[David-Chadwick]

As a verifier, I have no clue how to determine whether or not the holder is entitled to hold and present a VP/VC/claim. Who provides such entitlements? Who enforces them?

I agree. The essence of my proposal is that the holder provides hints to the verifier to help the verifier, and these hints point to the various VCs in the VP, indicating how the verifier can verify that the holder is entitled to hold each VC. The slides are in the deck of the F2F meeting that was held today. See https://docs.google.com/presentation/d/128DHWSzVxPgAhB0mq-h23_iATnbVeA4Y-JhNLjpcXJE/edit#slide=id.g1f24e2c0aad_7_602 starting at slide 48

[RieksJ]

@David-Chadwick: My problem is that I do not understand what it means when you say someone is entitled to hold/present a VP/VC/claim.

An entitlement (a 'right' according to Merriam-Webster) must have a ground, e.g. a law or regulation, an agreement or similar. While there will be specific situations where this might be the case, in the general case there is nothing to ground such an entitlement on.

My guess is that I can understand this if I can answer the the following questions; can you help me do that?

1. There is a dog that can do fantastic tricks. There is a highly esteemed dog-organization that has issued a VC stating which tricks it can do, etc. a. Which parties are entitled to hold that VC, and on what grounds? b. Which parties are NOT entitled (prohibited) to hold that VC, and on what grounds?

2. In the specific use-case where I pass a VC that contains my name, DOB, etc. to the travel agent of my employer so that it can book a flight, and when booking a flight for me the travel agent (which is then the holder) then presents it to the airline office (which then is the RP), then a. why would the verifier need to know whether or not the travel agent was entitled to hold that VC, and b. how would the verifier ascertain whether or not that is the case? c. does the verifier need to know on what grounds the entitlement is based?

3. Same three questions for the case where the travel agent has hired self-employed people that it can ask to book tickets, and passes on the VC that has claims about me to such a person that is then also asked to book a flight for me.

4. Can you help me understand in general terms what you mean when you say "the verifier can verify that the holder is entitled to hold each VC"?

[David-Chadwick]

Many VCs are issued to holders (usually subjects) after they have entered into an agreement with the issuer. So this satisfies the definition of entitled I believe. e.g. I am entitled to hold my credit card, I am not entitled to hold your credit card. Other VCs are deemed to be "bearer" VCs, meaning that anyone/everyone is entitled to hold them. Yet other VCs may be issued to third party holders (who are not the subject) when they enter into an agreement with the issuer. They are also entitled. Does this answer your question about entitlement in general? Now to your specific questions

1. The dog organisation, being the issuer, determines who may or may not hold the VC on behalf of the dog. I cannot determine this for them.
2. When you got the VC that contains your personal details the issuer will have told you the terms and conditions for the issuing of this VC. So you should read these to see what you are entitled to do with it. E.g. several plastic cards I possess have 'not transferrable' stamped on them. I understood this when I signed the agreement to get the card. This notice makes it pretty clear to everyone who is entitled to hold it. Only the subject is entitled to hold it.
3. Ditto
4. If you look at the use case examples I have given then you will see that there is a deterministic way for the verifier to determine that the holder was indeed entitled to hold the VCs he/she/it is presenting (assuming that none of the VCs that are being presented by someone other than the issuee do not have a ToU that indicates "non transferrable") or that they are bearer VCs where everyone is entitled.

[RieksJ]

It is clear to me that by 'entitlements' you mean the rights/duties that are specified in an agreement (contract) that the issuer and the party to which the VC has been issued have committed to. Thank you for that.

I accept that in the agreement/contract between you and your credit card provider there is a clause that that states that you ma not pass the card around and let someone else use it, and that you are the only one that is entitled to pay with it.

The text you wrote in reply to my specific questions mostly talks about the issuer, the party to which it issues a VC, and an agreement between the two that say what that party could/should (not) do with it, and you refer to earlier stuff to enlighten me of how the verifier could verify such entitlements.

However, you haven't answered questions 2a/b/c and 3a/b/c, that relate to why the verifier would/should care. The way I see it, rights/duties/entitlements in a contract only have meaning for those that have committed to it (signed it). An arbitrary verifier that didn't do so couldn't care less. When I considered your example with credit cards, I tried to remember of any practical situation where a credit card payment was refused on the mere fact that the presenter was not the 'rightful holder'. I could not find an example of that, and quite a few examples where verifiers do not even bother to check. All they care about is whether or not they will get paid. It is their own business rules that say what assurances they need to get paid, and it is these rules that they seek to comply with. Knowing the card details doesn't make one its rightful holder, but it is all verifiers need to get paid.

Use-cases in which the verifier has business rules that require that the contents of a claim pertain to the party that presents it do, of course, exist: a verifier that needs to decide whether or not someone gets access to a session in which (s)he can make an exam is one of them. But even in such cases one could often argue that the verifier should allow for the claims to be presented by someone else, e.g. in case the person has some kind of disability.

I conclude that

1. most VC would be 'bearer VCs' in the sense that anyone could hold them (which is different from what VCDM says bearer claims are)
2. Verifiers are not interested in whether or not a VC is presented by a 'rightful holder', i.e. a party that has committed to an agreement with the issuer in which its rights/duties (entitlements) regarding the VC are specified. They are only interested in making sure that in the context of the transaction in which it is presented with VCs/VPs, their own business rules are being complied with.
3. whenever issuers put stuff in a VC that informs third parties about the entitlements of a party that the issuer has a contract with, that could be a means that verifiers might use to obtain the assurance (to comply with their own business rules) they need. But such verifiers would then also need to identify/authenticate the party that had committed to that agreement, and they should not automatically assume that it must be the holder. And that is what the identifier-binding paper proposes the means for.

[David-Chadwick]

They are only interested in making sure that in the context of the transaction in which it is presented with VCs/VPs, their own business rules are being complied with.

In which case they must inform the holder what these rules are, since neither the issuer nor the holder in general will know what these rules are. I do not see anything in the holder binding proposal that indicates what these rules are.

Furthermore when the presenter is neither the subject nor the issuee, then holder binding is not much use since the presenter (who is neither of these) is not able to prove the holder binding without either masquerading as the issuee or subject, or by proving delegation of authority or similar. Neither of these seem to be within scope of the current holder binding.

It seems that in your travel agent use case the verifier does not care who the presenter is, as it is treating the passport as a bearer credential that anyone can present to it, and it will issue the ticket in the name of the passport subject. So holder binding is not needed in this case.

Therefore you have not indicated why. holder binding is actually of any use.

[RieksJ]

In practice, verifiers tend not to inform holders (or issuers) what these rules are. Rather, they request the user to supply data (fill in forms, present a VP) that enables them to verify these rules (and because nobody makes a real point of this, data minimization has become a farce).

You seem to insist on thinking that for whatever reason the verifier is interested to learn who the holder (or issuee) is. While I agree that in the majority of the situations that might well be the case, there are also situation where the presenter is neither the subject nor the issuee. In the example of the dog-organization, that organization could issue a VC about the dog to (the partner of) its owner, who could then transfer the VC to friend, asking him to register the dog for a dog show. The registration application (verifier) doesn't care who the friend is, nor who (the partner of) its owner is, and there's no reason to forbid that. This example shows that there are cases where holder binding is irrelevant.

I argue that holder binding is always irrelevant (in the context of VCDM, that is). What we need is identifier binding, i.e. providing the verifier with the capability to identify/authenticate the entities that identifiers (that are used e.g., in claims) refer to. If delegation of authority or something similar is required, this can be arranged by creating claims that state what the authority is that is being delegated, and state (an identifier for) the party that delegates the authority and (an identifier for) the party to which the authority is delegated. A verifier may be very interested to learn who these parties are that such identifiers refer to. Identifier binding provides a way to enable them to learn that.

I agree that I haven't indicated why holder binding is actually of any use. That is because I think that in the context of VCDM, identifier binding is the more generic problem to be solved, and once we have that, every case in which holder binding would be required would also be solved.

[David-Chadwick]

While I agree that in the majority of the situations that might well be the case,

And it is these majority of situations that I am addressing. For the other minority, perhaps where the verifier is not interested in who the holder is, this is fine. In its request to the holder, the verifier can indicate that it does not care or can ignore any information that the holder might provide.

I argue that holder binding is always irrelevant

I think we can both agree on this. I also believe that identifier binding is needed in the 'not obvious' cases such as when the identifier is an X.509 DN. When the identifier is a public key then it is obvious how to authenticate the holder of the private key as we have many existing standards that do this i.e. send a challenge and get it signed by the private key. So we do not need identifier bindings for the obvious cases that are implicit in the nature of the identifier.

[OR13]

As a note, given the v2 context includes a default vocab...

We should refer to the "issuing" party of a "verifiable presentation", as an "issuer" since that is what the default vocab will expand terms to be rooted under, see:

https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L4

^ TLDR: this line currently applies to both VC and VP.

[OR13]

I suggest we close this issue, and not define another role for "holder".

Or we could move the vocab into the VC or VP RDF Class and make the VP one root term definitions under "holder".

[dlongley]

We should refer to the "issuing" party of a "verifiable presentation", as an "issuer" since that is what the default vocab will expand terms to be rooted under, see:

If this is a problem, we could change the URL to be "author-dependent" instead -- which may be more agnostic as to any particular role other than being the author of the data that used the terms that resolved via @vocab.

[OR13]

or "controller-dependent" to align with how "controller" is used.

[RieksJ]

would be nice to have the vocabulary in line with the VCDM terminology.

[awoie]

@RieksJ do you still strongly believe that we need to have a separation between prover and issuee (both being specializations of holder)? Discussions regarding holder binding or identifier binding are happening in another PR #1054.

Otherwise I don't see strong consensus in this thread to add that property. Especially since @OR13 who created this issue wanted to close it.

[dlongley]

@OR13,

or "controller-dependent" to align with how "controller" is used.

That's an option, but I'd be worried that we'd hit some similar situation like we just did with "issuer-dependent" where it didn't apply. If we use "author-dependent" then it should be a safe bet because it's always up to the author of the terms to decide what they meant.

[awoie]

@dlongley @OR13 Is my understanding correct that we won't have to change holder to prover or introduce a new role prover but we might need to adjust the vocab? If this is correct, what concrete changes have to happen in the vocab and can we create a separate issue for that since this issue is about introducing a new role prover?

[OR13]

We don't need to change things, we do need to define holder a bit better.

I think we can close.

[decentralgabe]

Is there an issue to track clearly defining holder? If not, @OR13 would you want to close this and open that one? I see @awoie is assigned. Perhaps the holder definition is encompassed in the binding work?

[Sakurann]

good discussion - please open a new issue if there is a need to redefine a term holder - discussion in this issue is impossible to follow with that regard.

[RieksJ]

We don't need to change things, we do need to define holder a bit better.

That's not going to help, unless people start using terms in the meanings in which they are defined, which is currently not the case. I contend that if they were to do that, even if the definition weren't modified, that would already lead to the resolution of many issues.

[RieksJ]

Is there an issue to track clearly defining holder? If not, @OR13 would you want to close this and open that one? I see @awoie is assigned. Perhaps the holder definition is encompassed in the binding work?

There is a definition of 'holder' in the RWOT paper on identifier/holder binding, which I think is quite good. But there is no point in having a good definition unless people start to actually commit to using the term in the way it is defined.

[iherman]

The issue was discussed in a meeting on 2023-06-21

• no resolutions were taken

View the transcript

#### 2.4. Define "prover" in addition to "holder". (issue vc-data-model#902) _See github issue [vc-data-model#902](https://github.com/w3c/vc-data-model/issues/902)._ **Kristina Yasuda:** Orie says we can close. I'm putting pending close.

[TallTed]

@RieksJ — I believe this is the definition of holder to which you refer:

A role that a party[5] can perform as it (a) requests and obtains a VC from an issuer, (b) manages VCs within a wallet, or (c) creates VPs from one or more VCs and sends them to the verifier that requested it. A holder is usually, but not always, the subject of a claim in one or more of the VCs that it uses to create a VP.

[5] The W3C VCDM defines the holder as an ‘entity’, leaving it to the reader to determine from the context whether or not a party is intended, or a component (an actor) that acts on behalf of such a party. For a discussion about distinguishing between parties and actors, see the eSSIF-Lab mental model on Parties, Actors and Actions.

If we're going to discuss it here (or in a new issue), I think it makes sense to have it here (or in that new issue).

[brentzundel]

No objections raised to closing since marked pending close, closing.

I invite those who wish to continue discussing whether to revise the definition of holder to open an issue for that purpose.