Review & Clarify Trust Model Section re: No Transitive Trust & Delegated Keys

[ChristopherA]

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.

[David-Chadwick]

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?

[jandrieu]

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

[David-Chadwick]

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.

[msporny]

I get a discount voucher from Supermarket X which gives me a discount on a product.

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:

She presents my VC in a presentation that says she is my daughter.

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.

Should the supermarket give her the discount or not?

In almost every case, they don't care that she's your daughter and the coupon she is holding is a bearer instrument.

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.

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.

Importantly, how can the supermarket know the difference in the two presentations? The first one is legitimate, the second one is not.

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.

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.

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.

[jandrieu]

@David-Chadwick said

Importantly, how can the supermarket know the difference in the two presentations? The first one is legitimate, the second one is not.

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:

1. This coupon is only redeemable by PersonX or their delegate or immediate family member.
2. Delegates shall be authenticated by method X. (Mechanism TBD but would have to be known by the verifier)
3. Family members shall be authenticated by method Y. (Mechanism TBD, but would have to be known by the verifier)
4. PersonX shall be authenticated by method Z. (Presumably proof of control)

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?

[David-Chadwick]

@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 holder is not the subject
• the holder is not trying to masquerade as the subject (the holder is happy to be him/herself).
• the verifier does not know the subject or the holder (it only has a bunch of IDs)
• the subject's VC contains some implied benefit (direct or indirect) - I think this applies to all VCs, otherwise there is no point in possessing them.

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

                                              Holder is
                                    legitimate     thief/illegimate    
holder is             subject       1.Accept       2.Accept
claiming
benefit for           holder        3.Accept        4.Reject

Here are some examples of VCs for the 4 cases above

1. A supermarket loyalty card that gives points to the subject.
2. A supermarket loyalty card that gives points to the subject.
3. A prescription, where the pharmacist gives the drugs to the holder (to take back to the subject)
4. A prescription, where the pharmacist gives the drugs to the holder (to sell on the black market)

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.

[dlongley]

@David-Chadwick,

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.

[David-Chadwick]

@dlongley
I agree. There could be hidden negative consequences from the thief giving the subject the benefit. So I am happy to change 2. of the matrix to Reject. This was in fact my original idea, but then I thought, if the thief wants to continue giving me the benefit, then why not? More fool the thief. But you have pointed out why not.

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.