Re: Proposal: Anchored Resources and Hashlinks for VCs

Hi Michael,

Ahhh yeah, I was sorry to have missed that session! Do you happen to know,
does GS1 have a proposed linking property/mechanism?

On Wed, Nov 3, 2021 at 2:10 PM MXS Insights <mxsinsights@gmail.com> wrote:

> Dmitri,
>
> This sounds very interesting and very similar to some of the challenges
> that GS1 was raising at IIW around the current VC Standard.  Sharing a
> screen shot from one of the presentations.
>
>
> Michael Shea
>
>
>
>
> On Nov 3, 2021, at 6:59 PM, Dmitri Zagidulin <dzagidulin@gmail.com> wrote:
>
> Oliver,
> Great question. Some thoughts on that over here:
> https://github.com/w3c/vc-data-model/issues/831#issuecomment-959772827
>
> On Wed, Nov 3, 2021 at 6:48 AM Oliver Terbu <oliver.terbu@mesh.xyz> wrote:
>
>> This sounds interesting.
>>
>> @Dmitri Zagidulin <dzagidulin@gmail.com> would it be possible to link
>> two DIDs through one VC together with this approach?
>>
>> Oliver
>>
>> On Wed, Nov 3, 2021 at 2:57 AM Dmitri Zagidulin <dzagidulin@gmail.com>
>> wrote:
>>
>>> I've been hearing the subject of cryptographically binding links between
>>> VCs and other VCs (or other external resources like PDFs) come up more and
>>> more lately (it's especially been prevalent in the VC Edu community). I'd
>>> like to put forth a proposal that hopefully addresses the use case, or at
>>> very least starts a conversation. Motivation
>>>
>>>    1. Provide a mechanism with which to link multiple VCs together (as
>>>    peers or as parent/child relationships).
>>>    2. Provide examples of a general purpose hashlink
>>>    <https://datatracker.ietf.org/doc/html/draft-sporny-hashlink> mechanism
>>>    (useful for linking VCs, but also for linking to external images, PDFs, and
>>>    other files).
>>>
>>> Background / Use Cases
>>>
>>> There are many use cases that involve binding multiple Verifiable
>>> Credentials together. For example, a simple Student ID credential can
>>> consist of an overall container credential, which links to several
>>> individual credentials (such as a student Photo credential, a proof of
>>> enrollment at a particular university, a proof of age, etc).
>>>
>>> Note that this is different than binding multiple credentials together
>>> in a Verifiable Presentation (and having the presenter sign the VP). In the
>>> VP case, the binding just means "this presenter is authenticating the
>>> handing over of these unrelated credentials". Whereas in the linked VC
>>> case, the credentials are aware of each other, and the peer or hierarchical
>>> relationship is built into the VC itself.
>>> Proposal
>>>
>>> This proposal introduces two new related properties: anchoredResource
>>>  and contentHash.
>>> Anchored Resource
>>>
>>> An anchored resource points to one or more linked or bound resources. It
>>> can appear in the credentialSubject section (which implies that the
>>> resource is linked to the subject), or in the top level credential (same
>>> level as issuer, issuanceDate, etc), which implies that the resource is
>>> linked to the credential itself.
>>> Content Hash
>>>
>>> A contentHash property provides a way to refer to an external resource
>>> via a Hashlink.
>>> Example
>>>
>>> Here's what this would look like, using a mock Student ID credential.
>>>
>>> {
>>>   "@context": [
>>>     "https://www.w3.org/2018/credentials/v1",
>>>     "https://w3id.org/security/suites/ed25519-2020/v1"
>>>   ],
>>>
>>>   "id": "urn:uuid:123445",
>>>   "type": ["VerifiableCredential", "StudentIdCredential"],
>>>   "issuer": {
>>>     "id": "did:key:....",
>>>     "image": {
>>>        "id": "https://example-university.edu/logo.png",
>>>        "contentHash": "hl:<hashlink to the logo url above>"
>>>     },
>>>     "name": "Example University"
>>>   },
>>>   "issuanceDate": "2020-04-03T00:00:00.000Z",
>>>   "expirationDate": "2020-12-15T00:00:00.000Z",
>>>   "name": "Student Identification Document",
>>>   "anchoredResource": [{
>>>      "id": "urn:uuid:<URN of the related photo id credential>",
>>>      "contentHash": "hl:<hashlink to the related photo id credential>"
>>>    }],
>>>    "proof": {
>>>       // ed25519 signature proof goes here
>>>    }}
>>>
>>> Note the two usages of contentHash in the example. In the issuer, the
>>> hashlink <https://datatracker.ietf.org/doc/html/draft-sporny-hashlink> is
>>> to a resolvable resource (a regular .png hosted somewhere), and its only
>>> purpose is to cryptographically bind the exact version of the logo. (The
>>> alternative way to do that is to embed the full image in a
>>> data:image/png;base64,iVBORw0KGgoAA... url. Except those tend to make
>>> the VC too large for some use cases, such as fitting onto a QR Code.)
>>> Whereas in the anchoredResource, the hashlink is to a non-resolvable
>>> urn:uuid: type URN, which only makes sense if both the student id and
>>> the photo credential were presented to the verifier.
>>>
>>> Let's continue the conversation over at
>>> https://github.com/w3c/vc-data-model/issues/831 !
>>>
>>
>