Review & Clarify Trust Model Section re: No Transitive Trust & Delegated Keys #252
Comments
|
I can support this viewpoint as long as we limit v1 VCs to subject=holder only, and state this explicitly in the specification. The minute you enter the realm of subject NE holder, then you enter the realm of transitive trust and delegation, because the verifier needs to know "is this holder authorised to possess and present this VC or did he take a copy of it without the subject's permission". In the former case the verifier may accept the VC, in the latter case it should definitely reject the VC. Our current specification supports subject NE holder and has some controls to support this scenario. But if we add text to say that transitive trust is not supported, then how do we square this circle? |
|
@David-Chadwick I'll try to unpack this more thoroughly in the other issue, but I think there's still a disconnect. VCs are not an authorization platform. They do not handle delegation. The semantics of creating a verifiable presentation DO NOT imply that the holder is the subject. The semantics could literally say anything. By design. If you look at the citizenship focal use case https://w3c.github.io/vc-use-cases/#citizenship-by-parentage, you'll see that the holder in that case, Sam, is presenting his mother's passport and marriage certificate, not as his own, but as his mother's, with whom he claims a relationship based on the birth certificate which has both Sam and his mother as subjects. This is a perfectly valid use of these credentials. What would be invalid would be Sam presenting those credentials, claiming that he is his mother. IMO, it is completely unreasonable to assume some sort of ability to deny the use of credentials in the fashion Sam is, which is neither a delegation nor an instance of transitive trust. VCs are a mechanism for receiving assertions of fact despite insecure channels (whether that's the holder, the user-agent, or the transmission channel). Because we can't trust the channel, the VCs stand on their own with two exceptions. The first is for a status/revocation check that makes it possible to ascertain if the credential has been rescinded in some fashion after creation. The second is proof-of-control if the subject identifier enables it, which is only appropirate if there is ALSO an assertion in the Verifiable Presentation that the holder is the subject. Without that explicit assertion, it should not be assumed. In Sam's case, it's unlikely his birth certificate has some sort of proof-of-control that was enabled at birth and still viable. The expectation for me is that the document is signed by the issuer and has the typical amount of meta-data. What Sam has is a trail of evidence, not cryptographic provability that he is the subject. |
|
The disconnect is that we are looking at different use cases. The Sam use case if fine by me. I have no problems with it. Here is a use case for you to consider. I get a discount voucher from Supermarket X which gives me a discount on a product. I am the subject of the discount VC. My daughter goes to the supermarket to do our family shopping for me. I give her my VC to take with her on her mobile phone. She presents my VC in a presentation that says she is my daughter. Note. She says she is my daughter, she has no other proof of this. Should the supermarket give her the discount or not? What if my daughter cannot be bothered to go to the supermarket, and gives the voucher to her friend, who then presents it in order to get a discount on her family shopping, and says she is my daughter. Should the supermarket give her the discount. Importantly, how can the supermarket know the difference in the two presentations? The first one is legitimate, the second one is not. One solution is for me to give my daughter a VC saying she is doing the shopping for me. This will allow the supermarket to give my daughter the discount and not her friend. |
Great use case! It is one that we've had a number of discussions about w/ companies in the digital coupon space, so I can provide some real world insight here. Digital Coupons are typically either bearer instruments or they're bound to a subject. Most are just bearer instruments. The use case is pretty clear cut. Either anyone can use the coupon, or only a specific subject can use the coupon. Now, on to your questions:
Familial relationships are the sort of PII that stores are increasingly not collecting in the US and are radioactive due to GDPR in the EU. I've never had a conversation w/ a digital coupon issuer or grocery store that wanted to map our a customer's family tree... which is why most digital coupons are bearer instruments, manufacturers don't want to restrict them in the way you're suggesting.
In almost every case, they don't care that she's your daughter and the coupon she is holding is a bearer instrument.
In almost every case, it's a bearer instrument. The manufacturer doesn't care if it is your daughter or her friend that bought the product as long as the coupon drove someone to buy the product.
Either the coupon is 1) a bearer instrument, so there is no subject identified, or 2) bound to a subject, so the subject is identified. So, either the VP is being presented by anyone or by the subject. Those are the only two valid use cases.
Anything outside of the two simple modes of operation I've outlined above is typically too complicated to pull off in the grocery store ecosystem. This holds true for many types of digital coupons. When it comes to the grocery use case and the VC Data Model, I'm fairly certain we're covered as we've been having those conversations w/ folks in the industry for some time. |
|
@David-Chadwick said
That's presuming that the manufacturer cares that she's your daughter. Who cares? Why is it part of the presentation? In the manufacturer DOES care, they would have to construct a set of rules that could be evaluated at run time by the verifier to programmatically verify the acceptable relationships for redemption. Manu suggests that this is more complicated than current manufacturers care about. But if they did... then the answer cannot be wholly represented in the cryptography of a VC, which would support your assertion that the current maths can't do that. Yes. The current maths don't support delegation or authorization. In the current spec the details would have to be in the language of the claim, similar to the small print that explains to retailers the conditions under which they can redeem a coupon. Those additional claims could describe something like:
The problem is that in order to enforce the policy you want, bespoke authentication and delegation systems must be put in place. These are out of scope for the VC data model. You can do it within the claims with the current spec assuming you have a well understood way to answer the question about family members. However, automating the verification based on the claims in a VC is out of scope. That can be applied at the business rules stage if a domain specific language is used, but that's about how the verifier understands and applies what is in a VC, not how they verify its authenticity as an assertion of the issuer. What I think you really want is something like what OCAP-LD is trying to create. There are good reasons that effort is separate. There tons of valid use cases where we can use VCs without the complexities of delegation and the VC spec will be clearer and done faster by keeping them out of scope. There are also hard problems with delegation that a half-baked solution is likely to create, such as accidentally recreating ACLs and their problems of confused deputies and such. Do you agree that your example is actually authorization and delegation? Or is there a version of it which doesn't involve bespoke authentication, authorization, and delegation? |
|
@manu. Please do not dwell on the specifics of that use case. Since the data model is generic then we cannot envisage all the use case that VCs will be developed for. Consequently we have to write a specification that addresses all possible use cases (as far as practicable) i.e. the specification is written in the general, not the specific. We have to have a general way of stopping the verifier from accepting VPs that it should not accept. @jandrieu. Yes I agree that my examples are a type of authorisation and/or delegation and/or controls and/or terms of use, which is why I have been arguing against saying that the VC data model has nothing to do with authz (since I think it has a lot to do with authz - read the use cases again and you will see that they are about authz in one way or another). The generic cases that I am addressing are where:
The verifier needs to know under which circumstances it should accept the VC and VP from the holder and when it should refuse to accept them. The following 2x2 matrix addresses all the possibilities as to when the verifier should accept or reject the VP and VC Here are some examples of VCs for the 4 cases above
In my opinion we do a dis-service to the community if our data model does not allow the verifier to determine the difference between cases 3 and 4. The solution is quite simple. The subject produces a VC and gives it to the holder, which indicates to the verifier that the holder is legimate. The holder presents both VCs to the verifier. In case 4. the holder will not have the second VC (the one issued by the subject) and therefore the verifier knows to reject the VP. Thus our data model specification should include some text to cover the above cases. |
|
Can you give another example of use case 2? I feel uneasy about the one you've given. I would think people would not want a thief/illegitimate holder to use their loyalty card, not because they wouldn't mind the free points, but because it wasn't them doing the purchase, which may have a whole variety of negative consequences. These consequences can range from the potentially minor: changing their spending profile and causing them to receive annoying/embarrassing ads or flagging them as purchasers of for example, ingredients for making meth, and causing them to have to deal with law enforcement. In other words, there may be additional consequences where awards are erroneously claimed for the subject that create circumstances that are undesirable for the subject. |
|
@dlongley So in fact this makes it easier for the verifier, because it does not need to determine who the benefit is for. If the holder cannot show legitimacy with a second VC, then it will reject the VP, fullstop. |
|
I agree that VCs will be used as part of future authorization data formats protocols, but I believe that @David-Chadwick's concerns about VC used for authorization are out-of-scope for this data format WG. It is another layer. |
|
b4be879#commitcomment-31277508 Extended conversation at that commit on this same distinction (about authorization being in scope or not). |
|
Our data model has an architecture, and shows VCs passing from the issuer to the holder to the verifier. We do not specify a protocol for this, and we do not need to, because dozens of different protocols are feasible, and in a way, we do not care. But one thing is certain, regardless of the protocol, the data that will be carried in the protocol will necessarily contain VCs and VPs. In the general case, where subject NE holder, the verifier needs to know if the holder is the intended holder or an attacker, because it needs to know whether to accept the VP or not. (Authentication protocols wont determine this, they cannot. They only verify the identity of the holder.) The data model should have a way of indicating this extremely important fact to the verifier, regardless of the protocol. This is what I am advocating for the DM document. The data itself should be capable of telling the verifier whether it should accept the VP or not. This is a DM issue that has to be addressed in the DM document. How it is addressed should be debated (e.g. a concrete VC or property for applications to use, or a description of what any application should do in order to address the issue). But we cannot ignore it. |
|
I remind @jandrieu that he said the verifier needs to know when it can "reliably accept" a VC. I fully agree with this, and this is the nub of the issue that the DM model has to address. |
|
I'm not sure where I said that, but if I did, it was a moment of unrigorous chatter. What a verifier needs to know is whether or not the credential remains a legitimate utterance of the issuer. If what you mean by "accept" is that the verifier accepts the statement as an utterance of the issuer, then we're on the same page. If what you mean by "accept" is that the verifier accepts the truth of the utterance, we are not. If what you mean by "accept" is that the verifier accepts the credential as an authorization to any particular benefit, privilege, or customization, we are not. Any given utterance should be taken in context with any number of additional factors. The verifier may not trust the issuer for the fact at hand. For example, if the issuer of my driver's license is my aunt (who is not a legitimate department of motor vehicles nor any equivalent), then the verifier may be required by the specification to accept that the credential is valid without accepting it as legitimate proof of my license to drive. Which "accept" do you mean? This is one of the reasons that VCs should not be used as authorization. At best they are a statement by an issuer. Those statements may be interpreted as authorizations, but the specification intentionally avoids getting into the weeds on using VCs in this way. There are too many security holes to consider in the timeframe for this to be in scope. What we can legitimately guarantee is a particular way of verifying that the assertion by the issuer remains an authentic utterance without checking with the issuer directly and with revocation and refresh capabilities. That's huge. We do not have similar guarantees for anything wrt authorization. Similarly, the only "guarantee" we have that the presenter is in fact the subject is an interactive, out of scope proof-of-control ceremony. It's a higher assurance than username & password, but it still has its problems. And this interactive proof-of-control is completely out of scope. So, in fact, we have no guarantee that the VP is presented by the holder, much less the subject. Since we cannot make the guarantees your use cases require, I can only repeat what I've said before, what the group agreed at TPAC, and what was echoed on the call this week: authorization and delegation are out of scope. You state that "Authentication protocols wont determine this, they cannot. They only verify the identity of the holder." Respectfully, that's just not true. Authentication does not verify the identity of the holder. Authentication verifies that the current user has completed certain ceremonies as part of the identification mechanism of a given system. Every authentication system can be gamed or hacked. It cannot verify identity provably. Maybe that distinction is implied by your comment, but it is vital to what we are talking about here. When we--at the standards setting stage--assert that systems can magically do things that they fundamentally cannot, we are leading users, implementers, and technical decision makers down a false path that will put users and user data in harm's way. It is imperative that we understand and stick to the explicit guarantees we can actually back up with cryptography and process. Everything else is at best wishful thinking and at worst, misleading hyperbole. |
|
The Wikipedia definition of Authorization is very good, and suggests why VCs may be used in authorization systems, but do not (in and of themselves) constitute an authorization system. We have asserted something to this effect in the specification. Specifically, authorization systems require you to define an access policy to a particular resource. The core Verifiable Credentials Data Model does not do that. VCs could be used to do that, but that's not within the scope of our charter, and as many have suggested, is better done via composition or at a different layer using different technology. To put it another way, here is one way of visualizing authorization: presentation -> evaluation -> mapping -> action And the steps explained (for a successful request):
Verifiable Credentials are directly applicable to step 1 and step 2. They are not, on their own, applicable to step 3 and step 4. |
|
@msporny You might wish to add step 0. Credential Issuance, which is part of our model, as well as the definition of the policy. Then I would rewrite the steps as:
The Verifiable Credentials specification is directly applicable to steps 2, 3, 4, 5. Step 6 is the contentious one. Given that the DM model is 100% responsible for step 3, then it should also be 100% responsible for step 6, which is the direct corollary of step 3. (In just the same way that the DM model is 100% responsible for steps 2 and 5). |
|
@David-Chadwick We've said we don't expect VC to be an authorization framework, using language like "access control policy" and "grant or denies ... access" is problematic. For steps 7 and 8 we can reconcile it a bit like this:
In other words, the Verifier decides how to respond based on business/market needs, and/or their intent to be a good actor. |
|
I propose we phrase step 6. as "The verifier MAY wish to verify the right of the holder to possess the VC, depending on the application." |
|
@dmitrizagidulin @stonematt I will include your changes in the PR. thanks |
|
This has now been addressed in #291 (Mode of Operation) |
|
And in #283 (Remove Delegation) |
Related regards to portions conversation at TPAC about "Terms of Use", issues of failures of CA-like transitive trust models and delegated key usage was brought up by @David-Chadwick.
We should review the the Trust Model section and possibly clarify that no transitive trust is implied by the data model (validators only choose to trust an issuer or not, no CA-like delegation), and that it is responsibility of signatures suites to define any limitations on usage re-usage of key material.
The text was updated successfully, but these errors were encountered: