Re: Binding credentials to publicly accessible repositories

DIDs can/will certainly play a roll Kerri – in that I would expect that VC’s coming back from the issuer to include a DID that would enable the verifier the ability to get more information about the subject.

Our system doesn’t not require the use of DLT-based technologies, so that we can’t mandate IPFS (or equivalent).

Leonard

From: Kerri Lemoie <klemoie@concentricsky.com>
Date: Friday, July 30, 2021 at 1:10 PM
To: Roman Evstifeev <someuniquename@gmail.com>
Cc: public-credentials@w3.org <public-credentials@w3.org>
Subject: Re: Binding credentials to publicly accessible repositories
I appreciate Leonard’s question and consideration of Open Badges where evidence assets can play a big role in skill assertions. It’s worth exploring this further.

Two thoughts came to mind: DIDs and IPFS. Perhaps the IPID DID? Perhaps then assets could be bound to at least the credentialSubject if not the VC?






On Jul 30, 2021, at 12:45 PM, Roman Evstifeev <someuniquename@gmail.com<mailto:someuniquename@gmail.com>> wrote:

If the VC in its credential subject contains info about one particular creative work, then it is pointless to reference this VC as a credential for another creative work. Any verifier should check the contents of the VC and accept it as a credential only for the data mentioned inside the credential subject part of this VC.

On Fri, Jul 30, 2021, 19:33 Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>> 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%7C965d8bb17ab248960bc208d9537ce837%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637632618215792563%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FV1iQSLNmv0%2FDFRVlRQptV0dS%2FLfsqesMpdYt2rPGlk%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<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org%2F&data=04%7C01%7Clrosenth%40adobe.com%7C965d8bb17ab248960bc208d9537ce837%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637632618215802521%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Hl7W3Mg8hVQndE9Xc5fM0ILBsaKPNfiqinTIUUuRLAY%3D&reserved=0>’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