Closed OR13 closed 1 year ago
We might consider:
then
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: @.***>
"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
@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.
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" } } ]
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):
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)...
@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.
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: @.***>
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
@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?
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?
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?
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.
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"?
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
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
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.
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.
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.
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.
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".
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
.
or "controller-dependent" to align with how "controller" is used.
would be nice to have the vocabulary in line with the VCDM terminology.
@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.
@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.
@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?
We don't need to change things, we do need to define holder a bit better.
I think we can close.
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?
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.
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.
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.
The issue was discussed in a meeting on 2023-06-21
@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).
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.
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 theypresent
to a secondholder
who is often asubject
.This second
holder
will thenpresent
to averifier
.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.