vc-data-model
vc-data-model copied to clipboard
w3c
Define "prover" in addition to "holder".
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.
Presenter (instead of prover) may provide a wider scope to capture more use cases and better match with the fact that they are "presenting".
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 https://github.com/w3c/vc-data-model/issues/902#issuecomment-1207455974, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YJSJMAAHTBQPIHPXV3VX7Z2XANCNFSM552WPUHA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
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....).
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
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 https://github.com/w3c/vc-data-model/issues/902#issuecomment-1209477326, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YLM4LWDIW3X2UGU6A3VYJVLBANCNFSM552WPUHA . You are receiving this because you commented.Message ID: @.***>
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.
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.
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.
For the record:
PROPOSAL: define holder (undirected), receive / present (directed actions) .... receiver, presenter (directed).
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.
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.
It's not bike shedding to consider a directed request-based model vs. the current discussion of undirected and directed.
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.
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.
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.
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.
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.
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.
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.
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.
A related issue discussed on the traceability call today:
- https://github.com/w3c-ccg/traceability-vocab/issues/521
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.
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".
I continue to believe that "binding" is the wrong word for this association, this desired restriction (which might be the right word for it).
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
@OR13,
I think the "holding binding" issue(s) and related conversations started from the idea of creating a dependency of sorts on a proof of possession, but it's grown to encompass more than just that idea. Besides, that idea had some initial flaws when called "binding" that people mentioned early on as well.
I agree with @TallTed that we need a better word than "binding" -- but I'm hoping at this point that we don't try to bikeshed it but rather let something new come out of further discussion. I think there are a number of different use cases people are interested in that all fall under the umbrella of "holder binding". Some examples that come to mind:
- Having an issuer say that they intended a particular entity to be the presenter of a VC (but in the absence of why that matters?).
- Having an issuer say that verifiers could examine certain evidence or compare it against the presenter of a VC (perhaps running checks X, Y, Z against them) to see if they are the intended subject of the VC / some other identified and intended party.
- Having the issuer say that they believe a particular party should be given some privilege and perhaps suggest how to authenticate that party. Note that maybe it doesn't actually matter who presents the VC unless the act of presenting itself involves sufficient authentication of said party. (There's also some tension here between what the verifier might accept as valid authentication and what the issuer might prefer or suggest they accept).
This ongoing discussion has not converged for as many years as I've been around. If anything, it seems to be getting fuzzier even as ACDC and other options come on the scene. The challenge from ISO mDL and OWF is also adding to the fuzz.
I think some of this is due to not treating biometrics as primary components of VCs. To help advance our discussion, I posted a slightly tongue-in-cheek perspective on digital human identifiers to CCG today. https://lists.w3.org/Archives/Public/public-credentials/2022Nov/0195.html
It's not proposing a solution, but hoping people take the question seriously and factor it into the VC 2 design.
Adrian
On Wed, Nov 30, 2022 at 5:54 PM Dave Longley @.***> wrote:
@OR13 https://github.com/OR13,
I think the "holding binding" issue(s) and related conversations started from the idea of creating a dependency of sorts on a proof of possession, but it's grown to encompass more than just that idea. Besides, that idea had some initial flaws when called "binding" that people mentioned early on as well.
I agree with @TallTed https://github.com/TallTed that we need a better word than "binding" -- but I'm hoping at this point that we don't try to bikeshed it but rather let something new come out of further discussion. I think there are a number of different use cases people are interested in that all fall under the umbrella of "holder binding". Some examples that come to mind:
- Having an issuer say that they intended a particular entity to be the presenter of a VC (but in the absence of why that matters?).
- Having an issuer say that verifiers could examine certain evidence or compare it against the presenter of a VC (perhaps running checks X, Y, Z against them) to see if they are the intended subject of the VC / some other identified and intended party.
- Having the issuer say that they believe a particular party should be given some privilege and perhaps suggest how to authenticate that party. Note that maybe it doesn't actually matter who presents the VC unless the act of presenting involves sufficient authentication of said party. (There's also some tension here between what the verifier might accept as valid authentication and what the issuer might prefer or suggest they accept).
— Reply to this email directly, view it on GitHub https://github.com/w3c/vc-data-model/issues/902#issuecomment-1332838780, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YKZCXIYCJZTLM4FSI3WK7LJPANCNFSM552WPUHA . You are receiving this because you commented.Message ID: @.***>
At ISO SC17 WG4 For 23220-4 we are discussing the same thing.
We are trying to determine whether there is value in distinguishing between the human entity whom the issuer identifies before issuance, the main subject of a credential, the entity receiving a credential directly from the issuer, the authorized user of a wallet, a human guardian of the subject, a delegated person, an entity authorized to assemble a presentation, an entity authorized to present a presentation, a prover. I might have missed some.
We are going down the path of having the issuer endorse a "means to authenticate" which, when a verifier wants confirmation that the entity presenting a credential is authorized to do so, can be invoked by the
