Re: Proposal: Anchored Resources and Hashlinks for VCs

see also
https://github.com/w3c/vc-data-model/issues/831#issuecomment-960249901 for
special cases where the hash is of a subject’s biometric.

- Adrian

On Wed, Nov 3, 2021 at 7:52 PM Phillip Long <phil@rhzconsulting.com> wrote:

> Dimitri: we have been talking about how endorsements could be handled as a
> VC, and linked to specific attributes in a different VC (a skill or
> competency, e.g.), as part of work under way in the HR Open Resume
> workgroup. Your proposal is timely and warmly welcomed.
>
> Thank for triggering this useful discussion.
>
> Cheers,
>  Phil
>
> Phillip D. Long, Ph.D.-Founder and Principal
> RHz Consulting LLC
> Inquire-Listen-Design-Prototype-Analyze-Repeat
> e: phil@rhzconsulting.com
> LinkedIn:http://www.linkedin.com/in/longpd
> —
> Senior Scholar, Center for New Designs in Learning and Scholarship (CNDLS)
> Georgetown University, e: pl673@georgetown.edu
> —
>
> Honorary Professor, Institute for Teaching and Learning Innovation
> University of Queensland, St. Lucia, Brisbane, QLD, Australia
>
> On Nov 2, 2021, at 9:57 PM, 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-sporny-hashlink__;!!IKRxdwAv5BmarQ!NXUqh588uxaE1iorS_inMNy0emRogYtZ0JD5t4VUParF0iaxmthxUGjblMyI7Xc$> 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://urldefense.com/v3/__https://www.w3.org/2018/credentials/v1__;!!IKRxdwAv5BmarQ!NXUqh588uxaE1iorS_inMNy0emRogYtZ0JD5t4VUParF0iaxmthxUGjbOszy8yY$>",
>     "https://w3id.org/security/suites/ed25519-2020/v1 <https://urldefense.com/v3/__https://w3id.org/security/suites/ed25519-2020/v1__;!!IKRxdwAv5BmarQ!NXUqh588uxaE1iorS_inMNy0emRogYtZ0JD5t4VUParF0iaxmthxUGjbc8KWzks$>"
>   ],
>
>   "id": "urn:uuid:123445",
>   "type": ["VerifiableCredential", "StudentIdCredential"],
>   "issuer": {
>     "id": "did:key:....",
>     "image": {
>        "id": "https://example-university.edu/logo.png <https://urldefense.com/v3/__https://example-university.edu/logo.png__;!!IKRxdwAv5BmarQ!NXUqh588uxaE1iorS_inMNy0emRogYtZ0JD5t4VUParF0iaxmthxUGjbqzUqoCY$>",
>        "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://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-sporny-hashlink__;!!IKRxdwAv5BmarQ!NXUqh588uxaE1iorS_inMNy0emRogYtZ0JD5t4VUParF0iaxmthxUGjblMyI7Xc$> 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
> <https://urldefense.com/v3/__https://github.com/w3c/vc-data-model/issues/831__;!!IKRxdwAv5BmarQ!NXUqh588uxaE1iorS_inMNy0emRogYtZ0JD5t4VUParF0iaxmthxUGjbktVVMk0$>
> !
>
>