Re: Binding credentials to publicly accessible repositories

+1 to Leonard's line of inquiry here.
Speaking of bleeding edge (and related to c2pa / ipfs / digital asset
provenance), Arweave may be worth exploring - https://www.arweave.org

The transition challenges for OBs are anything but
independent ...so grateful for the deep bench of ccg!

On Fri, Jul 30, 2021 at 11:10 AM Kerri Lemoie <klemoie@concentricsky.com>
wrote:

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