Re: Binding credentials to publicly accessible repositories

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

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


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

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


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

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

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

Leonard

From: Joe Andrieu <joe@legreq.com>
Date: Friday, July 30, 2021 at 1:29 PM
To: Credentials Community Group <public-credentials@w3.org>
Subject: 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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fvc-use-cases%2F%23citizenship-by-parentage&data=04%7C01%7Clrosenth%40adobe.com%7C1fe52700df734d6f745208d9537f8f38%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637632629592913676%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=m9OiPiC9ptNAS62nYyN46t7ofY2B4RvjeYmIg%2Fg4tU0%3D&reserved=0>

-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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fc2pa.org%2F&data=04%7C01%7Clrosenth%40adobe.com%7C1fe52700df734d6f745208d9537f8f38%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637632629592923627%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EIJYNLKIvirTVBAHD0SNAJZqzCiJD329eN%2B0E7tudm0%3D&reserved=0>) 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<mailto:joe@legreq.com>
LEGENDARY REQUIREMENTS                                                        +1(805)705-8651
Do what matters.                                                                            http://legreq.com<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.legendaryrequirements.com%2F&data=04%7C01%7Clrosenth%40adobe.com%7C1fe52700df734d6f745208d9537f8f38%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637632629592933586%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5dGjBG6H4L5DpLWN%2FNPD%2Fmc9yNApQeh0ogEeaWK3rU0%3D&reserved=0>