Re: Proposal: Anchored Resources and Hashlinks for VCs

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