Re: Proposal: Anchored Resources and Hashlinks for VCs

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