Proposal: Anchored Resources and Hashlinks for VCs

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 !