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.

[dlongley]

Presenter (instead of prover) may provide a wider scope to capture more use cases and better match with the fact that they are "presenting".

[agropper]

Requester (instead of holder or prover) is the entity that is making a request of a verifier. Verifications hardly ever stand alone. I the general case, the presentation of a credential is part of a request: - Resource or processing action desired - Purpose of the request - Credentials associated with the request - Payment or refundable deposit to compensate for the significant cost of policy evaluation and verification. Obviously, interoperability at the level of requests is complicated and domain-specific. Formulating the request has domain-specific actions (resource, purpose, and most credentials) as well as generic actions (signing and payment). This complexity promotes platforms and centralization as the client sophistication and policy evaluation are "sponsored" through surveillance capitalism and platform network effects. Even if requests are out of scope for this WG, using Requester will help other efforts.

…

On Sun, Aug 7, 2022 at 1:53 PM Dave Longley ***@***.***> wrote: Presenter (instead of prover) may provide a wider scope to capture more use cases and better match with the fact that they are "presenting". — Reply to this email directly, view it on GitHub <#902 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YJSJMAAHTBQPIHPXV3VX7Z2XANCNFSM552WPUHA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[TallTed]

Prover suggests to me that they are playing a specific role in the cryptographic layers, which they are not in any of the scenarios discussed in this issue (including those in comments), so I think that label would cause more confusion than it may relieve.

Similarly, requester feels like it inverts the role typically being played by an entity offering a VC/VP for verification.

Presenter seems to be the least likely to cause more confusion than it resolves.

I think further discussion along these lines would be aided by reference to (and possibly generate valuable feedback on) the mermaid diagrams that have recently been of significant help in clarifying the VC API Use Case efforts (start here and scroll down a bit....).

[vongohren]

We have touched upon similar problems and ended up with owner. But I feel presenter might be a better option.
We did use receiver internally, but verifier can be just as good

[agropper]

Owner is an interesting choice. It accurately reflects the reality that an owner can delete or take the VC off-line regardless of the subject or contents. It also matches the common use or Resource Owner in OAuth, GNAP, etc... Presenter, Holder, and Requester are different from Owner in terms of delegation. It makes little sense to delegate ownership and leads to impersonation and lack of accountability as major security flaws. As one who argues for freedom to delegate as a human right, I would suggest we avoid Owner.

…

On Tue, Aug 9, 2022 at 10:46 AM Snorre Lothar von Gohren Edwin < ***@***.***> wrote: We have touched upon similar problems and ended up with owner. But I feel presenter might be a better option. We did use receiver internally, but verifier can be just as good — Reply to this email directly, view it on GitHub <#902 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YLM4LWDIW3X2UGU6A3VYJVLBANCNFSM552WPUHA> . You are receiving this because you commented.Message ID: ***@***.***>

[brentzundel]

If presenter is the party who submits a presentation to the verifier, what is the name of the party that receives a credential from an issuer?
My understanding was that holder (as a role) was both the party who receives the credential from an issuer and presents a proof to a verifier.

The most recent spec defines it this way:

A role an entity might perform by possessing one or more verifiable credentials and generating presentations from them. A holder is usually, but not always, a subject of the verifiable credentials they are holding. Holders store their credentials in credential repositories.

[OR13]

A - (verifiable presentation) -> B

prover / presenter / from: The party A, such that A presents to B using a verifiable presentation.
verifier / receiver / recipient / to: The party B, such that B verifies a verifiable presentation from A.
holder (of the bag): an ambiguous term that applies to both presenters and receivers, and conveys no directionality

There is also a need to related "holder to aud" and "verifier to aud".

Does the holder really know who (specific id) they are presenting to ?... or are they presenting to an unbounded group? (the set of all servers that process "aud" bound presentations from that holder).

domain ~= aud
challenge ~= nonce

for the folks who have not yet become frustrated enough with our refusal to layer the data model and its security representations properly.

[jandrieu]

I'd like to suggest that we split "Holder" into "Recipient" and "Presenter", with the explicit understanding that it is generally assumed that these three are all the same person.

[OR13]

For the record:

PROPOSAL: define holder (undirected), receive / present (directed actions) .... receiver, presenter (directed).

[iherman]

The issue was discussed in a meeting on 2022-09-07

• no resolutions were taken

View the transcript

2.3. Define "prover" in addition to "holder". (issue vc-data-model#902)

See github issue vc-data-model#902.

Orie Steele: We created the spec to have a term for presenting.
… It's important to acknowledge the different roles for being a holder.
… It's dangerous to have terms in VPs that are undirected. The holder label is undirected.
… It would be better for the entity making the presentation to be able to assert that "I am presenting or I am receiving".
… We want directed intentionality in the data model.
… That's why we need additional terms related to the holder role.

Kristina Yasuda: There's a suggestion to use presenter.

Joe Andrieu: It makes sense to add both recipient and presenter for what we're currently calling holder.

Manu Sporny: +1 to defining the roles in a directional manner.

Joe Andrieu: That's an iteration on this conversation.

Kristina Yasuda: There is a consensus to have two terms.

Manu Sporny: Are we talking about getting rid of holder or saying that holders have two things that they can do.

Orie Steele: +1 to the latter formulation manu.

Manu Sporny: I wondering if issuers can receive and present as well.
… It's a question we have to answer for each of the current roles we have.

Joe Andrieu: We would benefit from keeping holder and clarifying it.

Brent Zundel: +1 Joe.

Joe Andrieu: The issuer/holder/verifier is a very powerful group of terms.
… We should elaborate on them.

Joe Andrieu: +1 to chat at TPAC.

Kristina Yasuda: This is the first time we're talking about this issue.
… Let's give people time to think about it.

[agropper]

The role of holder is the same as requester. An entity requests a VC from an issuer and may provide scope as well as authentication as part of the request. (Another) entity requests authorization from a verifier and may provide scope and purpose as well as authentication as part of the request. Unlike holder, requester is always a directed term.

[jandrieu]

So, now you do want to bikeshed?

[agropper]

It's not bike shedding to consider a directed request-based model vs. the current discussion of undirected and directed.

[logpo]

Splitting the holder definition in two will create more confusion IMO. The holder holds the credential and the means to present that credential to a verify. So they receive credentials from issuers, but they have a private key which is what separates them from anyone else who has the plaintext credential. I agree that the term isn't perfect but I'm not sure splitting the role in two fixes that.

[brentzundel]

I agree with @logpo about not wanting to split the holder role, but do feel it would be helpful to better describe the actions a holder takes when they are involved with an Issuer vs a Verifier.

[David-Chadwick]

This problem of describing the actions is compounded when subject NE holder. Describing the holder's relationship with the issuer (and subject) in this case is complex due to the different relationships there may be, and the holder may have to proove possession to the Verifier when the VC is not a bearer VC.
When subject EQ holder we have the public key in the VC to prove the relationship/possession.
If we mirrored this for issuing VCs to holders (NE subject) it would simplify these relationships, because the VC would contain the holder's public key and then PoP to the verifier becomes straightforward. Of course it does not deal with the subject EQ holder passing their VC to another holder (NE subject). But that is a second order issue.

[decentralgabe]

I'd like to re-define holder as one who has the cryptographic ability to prove control of a credential using a cryptographic identifier or key defined by the issuer of the credential.

[OR13]

I'd like to deprecate holder, and NOT define it normatively, instead, I would like to define only terms that have some security characteristic associated with the securing format (vp-jwt, vp-data-integrity).

Unsigned "verifiable" presentations are the only use case for the existing holder term imo.

[agropper]

There are significant human rights associations with the holder term because of the temptation to use a biometric wallet or, more literally, an ankle bracelet.

"Client credentials" is a constant challenge. To the extent that holder is a client, the relationship of the client to the human that is operating the client must be explicit in our normative statements. The risk of being expected, if not forced, to carry or use a certified client is an obvious human rights problem.

[TallTed]

The holder holds the VC. They need not be identified anywhere in the VC (though they might be). There is no global need to tie VCs to their holders, though it may be useful in some cases. Likewise, there is no global danger for holders of VCs, nor even subjects, who may not ever know they were the subject of a given VC.

I am growing increasingly weary of saying the same thing again and again, of having to defend against universals that aren't universal, certainly technologically and generally otherwise.

Please remember, we are working on the technological aspects. Concerns that amount to "government logic", akin to business logic, are pretty far outside of our scope, unless a specific harm can be identified and defined and demonstrated to be inherent to the tech, which will enable us to construct a defense against that harm, at least to the extent that we agree about its significance.

[RieksJ]

One of the above comments nicely distinguished between parties and roles. A party, whereas a role can be seen as a particular way in which it can perform. It's like a play where actors fulfill roles, which is easily transferrable to the real world (I can act in a role as 'father', 'TNO employee', etc.). The VC-image of issuer-holder-verifier is a bit misleading in the sense that many seem to interpret these roles as if they were the party itself - as little children do when they see Santa (for the Americans) or Sinterklaas (for the Dutch).

Having said this, we just need to identify the various 'parts' of the play, e.g. 'issuing', 'requesting/receiving' - whatever we choose/need to have, then properly describe these 'parts' and define a name by which we can refer to parties that will perform this part/assume this role. It doesn't really matter what the role-name is, as long as it is properly defined. But of course, it helps if these names trigger the right 'hallucinations' with readers.

[OR13]

A related issue discussed on the traceability call today:

• Traceable Presentation Recipient w3c-ccg/traceability-vocab#521

[awoie]

I also found the term holder a bit vague. We could try to run a non-binding poll on this and ask folks how they feel about introducing a new role presenter (I also feel that prover is too narrow in scope since it is not always about verification of cryptographic proofs).

• Issuer issues VCs
• Verifier verifies VPs/VCs
• Presenter presents VPs/VCs

I'm ok with keeping the term Holder in the VCDM as non-normative text if people think this might help with establishing some reader context but if we agree on presenter, then we should probably make presenter a normative property in the VP.

[awoie]

Also note that holder has never been normatively defined in VCDM 1.1.

[OR13]

It's amazing how many critical issues there are for us to work on.

My guess is that "holder binding" would be far less contentious if we could define what a holder is first.

My sense is that "holder binding" might more accurately be titled "presenter binding".

[TallTed]

I continue to believe that "binding" is the wrong word for this association, this desired restriction (which might be the right word for it).

[OR13]

Great point about the word binding, it makes you wonder if we are trying to relate "holder binding" to "token binding" or if that relationship is not what we are hoping to accomplish:

https://www.w3.org/TR/webauthn-2/#dom-collectedclientdata-tokenbinding

[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.

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.