Re: Binding credentials to publicly accessible repositories

On Fri, Jul 30, 2021, at 11:58 AM, Leonard Rosenthol wrote:
> > To my reading of your design, the party who signs the tamper-proof mechanism is attesting the binding between the elements of the PDF.
> > 
> Not just PDF – but yes, I agree completely with this statement.
>  
> > does the verifier trust the signer as a valid authority for that attestation?
> > 
> Right question, however, while the verifier trusts the signer to make attestations of this nature, it has no way of knowing if it can make this **specific** attestation.

How could you trust an issuer to make attestations of this nature, but not trust them to make a specific attestation? If you trust the DMV for attestations about driver's licenses, how would you know to NOT trust them for a specific driver's license? Seems like the trust factor involves both the authority and the scope of trusted attestations. Within those, e.g., driving privileges, it is only the DMV that has the authority to decide which specific driver gets what specific attestations. That's sort of the point, the verifier doesn't have any special information about specific attestations other than what is in the VC (and perhaps in associated DID Documents or certificates)

I think we may be talking past each other on that point.

> > Because the whole goal of your approach is to allow arbitrary VCs to be attached to a PDF
> > 
> Yes and no.  It’s about allowing for VCs that are connected to this asset in some way to be attached to it.

The connections are only as strong as the party asserting the connection. Hence the need to have a well-known identifier for the signing party.

> > If someone takes a VC from one PDF and binds it to another, that's a fine use case.
> >I may take a driver's license VC that I get from a insurance application and in turn embed that VC in a proof of insurance statement. 
> > 
> But you couldn’t be able to put **my** driver’s license VC in **your** proof of insurance.

Ah... my apologies. I was sloppy with my pronouns. I'll restate in hopes of being clearer:
*An insurer may take a driver's license VC that it gets from a insurance application and in turn embed that VC in a proof of insurance statement as a PDF they sign.**
*

If that insurer put *your* driver's license in a *their* proof of insurance, then they are making a claim that you have insurance, presumably offered by them. That's totally valid and a completely different claim than if they put my driver's license in a claim that I have insurance.

What would violate integrity is if a random party, BadActorJoe, could attach a driver's license to a PDF "from that insurance company". Only the insurance company should be able to make that assertion.

I think this boils down to the fact that your tamper-proof attestation is only as good as your identification of the signer of that attestation. Signatures that can't be tied to a particular party, such as the DMV or Allstate Insurance, don't attest to anything at all other than the fact that the content hasn't changed since some random person created it (which could be a bad actor). At most you might manage pseudonymous session keys where all you are confirming is that the signature is from a party that controls the same crypto as was used in this session establishment. In that case, only the information from that session can be considered connected, unless some other forms of identity proofing have taken place. In which case that identity proofing is how you are establishing the trust for that pseudonymous identifier. So, we still have an allow-list: you won't trust a different cryptographic identifier for a message sent in that session.

>  > The validity of the application's binding is dependent on the authority of the party binding that application to the VC (presumably the applicant, subject to assurances).
> > 
> Again, I agree.  But there is no way to know whether that applicant has the authority to make that specific claim.  

Ummm... their presentation of that VC is an assertion of their authority just as fully as handing a driver's license to a cop when pulled over is an assertion that the DL is the driver's. It doesn't mean that it is. They could have stolen it. Rather, it means that the physical person how handed the card over is claiming that it is theirs. Only the driver has the authority to make that claim. The passenger doesn't get to participate. The cop doesn't get to decide what credential you present. The specific act of presentation is semantically meaningful and must not be lost in the translation to digital interactions. This is the whole point of the Verifiable Presentation, to give the holder a chance to sign a statement with the same DID as the subject of the VC, and not only cryptographically verify they control the same crypto as the subject, but make a recordable attestation that they are that Subject.

Your question of how does a recipient have any assurance that the application has integrity is the same as it ever was: source multiple verification mechanisms with intersupporting claims, much as RealID requires when onboarding for a RealID driver's license. If you trust the DMV to say that Joseph Andrieu is licensed and you have a PDF application for Joseph Andrieu and a VC from the DMV that says Joseph Andrieu is licensed to drive--and you have a verifiable presentation signed by the same DID that VC is issued to--then you can reasonably interpret that PDF as associated with that VC, although this structure is open to name collisions (rare with my name but less so with others). Better yet, put the DID that is the subject of the claim, in the PDF, then you have an assertion by the PDF issuer that this PDF is related to the same subject as the VC. My expectation is that despite the former hype about AgeOver credentials as single factor ZKPs, the truth is many VCs will need to embed human-testable correlations like a picture or physical descriptors (height, weight, etc.) so that the bouncer has some way to convince themselves we aren't dealing with a credential that was stolen along with access to private keys (which many *will* keep on their phone creating just that kind of attack).

You still have to decide if you trust that PDF signer to make those attestations, but that problem is inevitable. You can't trust a signature without some concept of who the signer is and why you would trust them for that attestation.

>   
> > The validity of the proof of insurance binding is dependent on the authority of the party binding the statement to the VC (presumably the insurer).
> > 
> Ah – the issuer of the proof of insurance binding is **not** the issuer of the VC!   That’s part of the conundrum here – I have someone issuing a VC (the DMV issuing the drivers license) and someone else (the holder in VC terms) making a claim about that VC (the person submitting the proof of insurance).  But there is nothing directly connecting those two (though in this specific case you could attempt to see if the subject of the VC matches the issues of the proof – but that’s not a general case).

That's right. The DMV is likely a consumer of the insurance statement, not its issuer. Only the signer of the PDF, the insurer, is authoritative for that signature.

In short, your signed PDF is a signed credential just like a VC or VP. In order to validate it, you MUST trust the signer to have signed it properly and to have assessed the situation accurately enough to make the assertion. If you don't know the signer, you shouldn't trust it. If you do, you are open to exactly the kind of attack you're talking about. Don't trust signatures by unknown signers. In the VC subject=holder case, the VP signer is "known" because the DID in the VC is known.

> > If Joe Random hacker creates a PDF with my driver's license, then whoever is evaluating that binding should check to see if the signer of that PDF is in fact the same party as the subject of that driver's license.
> > 
> Exactly as I noted above – but that is and will almost never be the case in our scenario. 

So what is your scenario?

I think you want to detect that a bad actor isn't publishing false insurance statements. Is that right?

Then maintain a list of qualified insurance providers and the cryptographic identifiers they use to sign things. DIDs and VCs don't avoid the need for an allow-list on those parties you trust for particular types of claims. There are ways to do this w/o an allow-list, but let's save that for another day.

>  > The only thing missing in this is an explicit statement by the signer as to the relationship between the VC and the PDF. If you had a Verifiable Presentation, I would put such a statement either directly in the VP or in a second VC. This latter option means you get a double the proof, but the first is a bit less standard in that you'd be using arbitrary properties in the VP which has its own consequences.
> > 
> I thought about using a VP in this instance, but it would require creating a VC for the asset and who would sign that for proof? Wouldn’t it be the same subject/identity that is signer the tamper proofing – in which case, AFAICT, it doesn’t offer anything.

The canonical pattern for subject=holder is
1. The Issuer requests a DID from the Subject, with a challenge string
2. The Holder presents a signed VP with the challenge string, using a DID
3. The Issuer verifies the signature on the VIP proving the requestor controls that DID (challenge string prevents replay attacks)
4. The Issuer issues a VC to the DID and delivers it to the requestor, who is now the holder of the VC (and its Subject)

later...

5. A verifier asks for a VC, with a challenge string
6. The holder selects a VC
6. The holder signs a VP, with that VC and the challenge string, using the same DID that is the subject of the VC
7. The verifier verifies challenge string, the VP signature, the VC signature, and the equivalence of the DID Subject and VP signature

The VP is proving that the Subject of the holder is now presenting it to the Verifier.
Only the controller of the DID in question is able to go through all that.

Of course, if the crypto secrets are compromised, none of this matters, but I think we all know the root vulnerability here. If we can't trust the key mgmt, all bets are off.

So, if you're VC is stolen, yes, someone else could put that into another VP, but the signing identifier of that VP would not match the id of the subject of the VC, and, as such, it should fail validation (and depending on your definition, it would fail verification as well). 

If you treat the signed PDF conceptually *as* a VP, you can make the same guarantees.  

I think the conundrum you're stuck in is that you're thinking the signer of the PDF has no cryptographic relation to the subject of the VC. In that case, all of your comments sound correct. I don't think you can get the guarantees you want without that cryptographic linkage. 

Can you update your approach to include that cryptographic link?

-j
--
Joe Andrieu, PMP                                                                              joe@legreq.com
LEGENDARY REQUIREMENTS                                                        +1(805)705-8651
Do what matters.                                                                            http://legreq.com <http://www.legendaryrequirements.com/>