Re: Binding credentials to publicly accessible repositories

Leonard,

I think this gets resolved by understanding who is attesting to the binding between the VC and the rest of the PDF.

To my reading of your design, the party who signs the tamper-proof mechanism is attesting the binding between the elements of the PDF. 

The authority of that party to make that binding is subject to the same inquiry as any issuer: does the verifier trust the signer as a valid authority for that attestation?

Yes, anyone could take that same VC and embed it into another PDF.

As it should be. Because the whole goal of your approach is to allow arbitrary VCs to be attached to a PDF.

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. 

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

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

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. This could be trivially proven if both signatures use the same DID. However, if that alignment is not verified, than the recipient is taking Joe Random's word that the driver's license VC is the right one for the application. 

This seems more of a feature of the architecture than a threat, as long as you understand that the signing of the anti-tamper mechanism is, by its nature, an attestation about the affinity of that VC to the rest of the PDF, made by that signing authority (and by neither the VC issuer nor the Holder, unless the tamper signature can be independently demonstrated to be either the issuer or holder).

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.

See the Citizenship by Parentage use case for an example. It doesn't use PDFs, but it demonstrates the bundling of various VCs with attestations about the relationships between those VCs. https://w3c.github.io/vc-use-cases/#citizenship-by-parentage

-j


On Fri, Jul 30, 2021, at 9:30 AM, Leonard Rosenthol wrote:
> I realize that I might be out on the bleeding edge a bit, though not completely as I think it is very similar to what OpenBadges will face as they move to VC’s…
>  
> In the Trust Model section of the VC Data Model spec, it states that one of aspects of that model is:
> The holder trusts the repository to store credentials securely, to not release them to anyone other than the holder, and to not corrupt or lose them while they are in its care.
> This is certainly true when the repository in question is something like a wallet that is designed to be kept private or local (not shared).  But what happens when the repository is designed to be out in the public… such as an image or PDF with the VC embedded?
>  
>  
> As part of the C2PA’s (https://c2pa.org) work on establishing provenance for digital assets, we will be using VC’s as a way for persons and organizations to establish their relationships to the asset.  Specifically in this instance, we’re extending schema.org’s Person and Organization schemas, as used by their CreativeWork schema, to support referencing a VC.  This then allows the author or publisher (or any of the other roles in CW) to provide their credentials in that role, which (a) adds useful trust signal(s) to the end consumer and (b) helps establish reputation.
>  
> These VC’s (etc.) will be embedded into the assets (e.g., video, images, documents, etc.) in a tamper-evident manner, so that in addition to the individual VC’s “proof”, any attempt to change the CreativeWork relationships, etc. can also be detected.   This all works great.
>  
> However, in doing some threat modelling, we recognized that we have no protection against a malicious actor simply copying the VC from one asset and dropping it into another (and then signing the new setup), because there is nothing that binds the credential to the asset in our case.
>  
> Has anyone run into this scenario before and has some guidance to offer?  Am I doing something that I shouldn’t be doing – and if so, what does that mean for OpenBadges?  
>  
> All thoughts and suggestions welcome! 
>  
> Thanks,
> Leonard
> 

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