Re: Binding credentials to publicly accessible repositories

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