Proposal: Anchored Resources and Hashlinks for VCs

[dmitrizagidulin]

Sidenote: I debated for a while where to open this issue (whether on the overall CCG repo, or the VC Dev Guide, or here), and decided to go with the VC Data Model spec repo, only because the proposal involves adding two new terms to the VC @context. This issue is meant to be a start of the discussion, and please let me know if this proposal should go somewhere else.

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 content hash 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 digestMultibase.

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.

digestMultibase

A digestMultibase property provides a way to lock down a link using a hash of its content, by specifying the hash algorithm, and (optionally) the canonicalization mechanism to perform before hashing.

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",
        // multibase + multihash of the logo
        "digestMultibase": "zQmdfTbBqBPQ7VNxZEYEj14VmRuZBkqFbiwReogJgS1zR1n"
    },
    "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>",

     // multibase+multihash of the content
     // the photo id credential was canonicalized with JCS (RFC 8785) before hashing
     "digestMultibase": "zQmdfTbBqBPQ7VNxZEYEj14VmRuZBkqFbiwReogJgS1zR1n"
   }],
   "proof": {
      // ed25519 signature proof goes here
   }
}

Note the two usages of digestMultibase in the example. In the issuer, the link 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 link 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.

Edits

• 2021-11-26 -- Added canonicalizationAlgorithm property to anchoredResource.
• 2021-11-03 -- change the usage of contentHash: <hashlink> to contentHash: <multibase+multihash of the content>.

[oed]

Why reinvent the wheel? IPLD already solves this type of problem very well.

[lrosenthol]

@dmitrizagidulin Thanks for putting up this proposal. I agree that there are indeed some key use cases for needing to supply a hash to related resources to be able to securely "bind them together". For example, this would be useful to us in C2PA (https://c2pa.org) in ensuring that VC's couldn't be moved between manifests to forge ownership.

The one question that I would pose here is whether a hashlink is a right solution. As such as I like them - including having my name on the spec - I believe that they are overkill in this instance. They are really to be used when you need to combine the URL and the hash into a single value in instances where you don't have rich structured data. But in this case, the id provides the URI (or other identification) to the asset so all you really need is the hash for contentHash. Accordingly, why not adopt SRI (https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity) instead? In addition to being more clear on what it is doing, it would align us with the browsers which is always helpful in getting support.

[vongohren]

Reflecting on the question @awoie asked per email.

When you say unrelated credentials, that is unrelated to each other credentials and not unrelated to the DID right?
So to bring back @awoie question, would it be possible to link two DIDs through one VC together with this approach?

[ChristopherA]

In some cases like to see a proof over a hash. Can you make it clear to separate that use case out from this one?

One use case for me is a VC where I have verified that you are the holder of the keys for another VC.

[dmitrizagidulin]

@lrosenthol - Yeah, on further thought, I agree, hashlinks are overkill for this usecase. I DO want to (in a separate proposal) advocate for using hashlinks for contexts and schemas. But you're right, for linking VCs together, a contentHash that links to a multihash/multicodec value is easier (and sufficient).
As far as why not use Sub-Resource Integrity instead of multihash/multicodec -- I think SRI is just not as flexible. Meaning, it locks in a base64 encoding, and only allows for 3 hash algorithms. Whereas multihash/multicodec allows for multiple different encodings, and multiple hash algorithms. And is a more compact notation.

@oed - A very valid concern, sure. We never want to reinvent if we don't have to. For what it's worth, this proposal (and the Hashlink spec itself) does use multihash & multiformat specs from IPFS.

[dmitrizagidulin]

@vongohren

When you say unrelated credentials, that is unrelated to each other credentials and not unrelated to the DID right?

Good question. It's both -- in the VP case, the individual VCs inside the VP may be unrelated to each other. And ALSO, they may have different credentialSubject IDs from each other, and those IDs can be different from the DID of the holder who signed the VP. Does that make sense? A VP (at least in the current VC Data Model spec) is an envelope for arbitrary different VCs; the credentials don't have to be about the same subject, nor do they have to be about the presenter who is handing them over.

(I'll try to answer your other question in the next comment.)

[dmitrizagidulin]

@vongohren

So to bring back @awoie question, would it be possible to link two DIDs through one VC together with this approach?

Ah, right. So let's talk about that. On the CCG mailing list, @awoie asked "would it be possible to link two DIDs through one VC together with this approach?"

My personal thought on it is -- yes, it's possible, but maybe we would want a slightly different mechanism for it. Let's dive into the details, though.
This proposal introduces two properties, anchoredResource, and separately, contentHash. Let's see if either of them can be useful, for linking two DIDs.

1. Using alsoKnownAs in a DID Document, to link two DIDs together

(I know that's not quite the question you both asked, but bear with me for a second, it's related.)

So, the DID Core spec, in the DID Document properties section, specifies alsoKnownAs, which is used for linking two different DIDs together (and recommends a bi-directional link).
That's one possible mechanism to link two DIDs together (and has the benefit of being in the DID spec). What are the drawbacks?
The main drawback (or, difficulty, really) with this method is -- what if one of those DIDs uses an immutable DID method, like did:key? I can link my did:web DID document to a did:key using alsoKnownAs, but not vice versa (since I can't modify a did:key document).
(Also, the proof of key possession of the link is unclear, and depends on the combination of the did methods.)

2. Using alsoKnownAs + contentHash in a DID Document

Could we add a contentHash to link not just two DIDs, but link two DIDs to particular content hash versions of each other? Sure.
For example, we can have a DID Document that's like:

{
  "id": "did:example:alice's did",
  "alsoKnownAs": {
    "id": "did:example:some-other-did-belonging-to-alice",
    "contentHash": {
      "digestMultibase": "z1Aaj5A4UCsdMpXwdYAReXa4bxWYiKJtdAvB1zMzCHtCbtD",
      "canonicalizationAlgorithm": "jcs"
    "
  },
  // ...
}

(We'll also assume that the DID Document for did:example:some-other-did-belonging-to-alice also has an alsoKnownAs link to did:example:alice, also with a valid contentHash.)

We still have the same drawback as the previous method (alsoKnownAs by itself), in that it's not possible with immutable DID methods like did:key.
We do get the benefit of linking to a particular hash/particular version of a DID document. But the problem with that is, unlike VCs or @contexts or versioned schemas, DIDs are intended to change over time (for example, as keys get rotated).
So, by using a contentHash when linking two DIDs together, we get into weird territory as soon as one of the DID keys is rotated.

3. Linking two DIDs by issuing a fit-for-purpose "did linking" VC

Ok, so, linking two DIDs together using alsoKnownAs is a pretty good mechanism, except when it comes to immutable DID methods.

Could we, instead, issue a VC that links two DIDs together?
Yes! (And, incidentally, this was the method that was proposed by DID WG members who were not fans of the alsoKnownAs property.)

One way we can do this is to agree on a particular VC type and payload, and by requiring TWO proofs, one from each DID.
So this would look like something like:

{
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://w3id.org/security/suites/ed25519-2020/v1",
      "https://w3id.org/some-new-did-linking-vc-context/v1
    ],
    "id": "urn:uuid:...",
    "type": [
      "VerifiableCredential",
      "NewTbdDidLinkingVC"
    ],
    "issuer": "did:example:alice's did",
    "credentialSubject": {
      "id": "did:example:alice's did",
      "alsoKnownAs": "did:example:some-other-did-belonging-to-alice"
    },
   proof: [
     { // proof 1, signed by "did:example:alice's did" },
     { // proof 2, signed by "did:example:some-other-did-belonging-to-alice" }
   ]
}

Note that this re-uses the alsoKnownAs term from the DID spec, instead of using the anchoredResource term, just because it's slightly more specific / descriptive.

4. Using anchoredResource in a (general) VC to link two DIDs together.

Instead of issuing a specific VC that was specifically designed to link DIDs together, could we just use something like anchoredResource, to link multiple DIDs in any (unrelated) VC?
(This is what I suspect @vongohren and @awoie were asking about.)
Maybe, yeah. This would look something like:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu/issuers/14",
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    },
    "anchoredResource": "did:example:some-other-did-belonging-to-ebfeb1f712ebc6f1c276e12ec21"
  },
   proof: [
     { // proof 1, signed by "did:example:ebfeb1f712ebc6f1c276e12ec21" },
     { // proof 2, signed by "did:example:some-other-did-belonging-to-ebfeb1f712ebc6f1c276e12ec21" }
   ]
}

This approach would essentially overload the semantics of the VC to say "it's a VC about a bachelor's degree, BUT ALSO it binds the DID in credentialSubject.id to the DID in credentialSubject.anchoredResource.

Summary / thoughts

I think all of these approaches are valid, though I think I'd prefer either using plain alsoKnownAs (approach 1), or issuing a fit-for-purpose VC that binds DIDs together (approach 3).
Approach 4 seems like it may be too ambiguous, and force VCs to serve multiple unrelated purposes.

[dmitrizagidulin]

@ChristopherA

In some cases like to see a proof over a hash. Can you make it clear to separate that use case out from this one?

Interesting, ok! You're right that just the contentHash by itself doesn't have a proof of possession component.
But in a way, isn't the VC itself a proof over a hash? Meaning, the VC has a contentHash in it, and the proof section signs over the whole thing?

One use case for me is a VC where I have verified that you are the holder of the keys for another VC.

Can you say a bit more about this use case?

[kdenhartog]

This is a new feature which would create changes to the VC context, so I'm going to label this as a v2 issue.

[agropper]

tl;dr: linkage based on hashed compressed facial images can avoid the need for verifiable presentation to a human verifier. A subject can present authentic DIDs or sufficiently simple credentials as QR codes on paper. *Credential*: I’m particularly interested in the use-case of a passport or driver’s license *Credential* that includes *a human-recognizable face biometric in order to link the Subject to the tamper-resistant proof. *The Issuer of such a *Credential* is signing over the correspondence of the biometric to other attributes of the Subject such as their DID. This Credential is typically long-lived and not specific to any particular transaction. *Document*: For example, a notary signs and seals for the correspondence between a face and a name of a Subject as a transaction. The notary also keeps a private log of the transaction that includes a unique attribute of the Subject as their state drivers license number. Importantly, the contents of the *Document* referencing the Subject are not verified by the notary. The signature is over the entire document as a transaction that identifies an individual in a non-repudiable way. *Hash*: As with an analog biometric credential, the digital version of a biometric credential prevents tampering using a digital hash rather than physical inspection. The notary serves important roles in non-repudiation of the transaction and in privacy. The notarized document need not include the Subject's unique attribute (a driver's license number or a DID) that might be opaque to a Verifier. All the Verifier cares about is that the notary is "registered" and the transaction they logged is indexed by timestamp in the notary's log. *Linkage* between the notarized *Document* and the Subject is via a human-friendly Subject Name as an attribute shared among: - the long-lived biometric *Credential*, - the notarized transaction *Document*, - and the Verifier. *DID:* The opaque unique identifier (e.g. a DID) need not be scrutinized by the Subject, the notary, or the Verifier as long as it is accurately copied from the biometric credential to the notary's log. This is a major user experience and adoption benefit. The DID need not appear in the Document at all as long as there is sufficient information to access the notary's log, if necessary. *Privacy*: The Verifier does not need access to the biometric as long as they trust the notary. *This mitigates the risk of Verifiers contributing to biometric registries*. The notary needs access to the biometric but does not need to store the biometric. The biometric is only available locally in the *Credential* and may or may not be stored by the Issuer either. *Inspection:* The notary who inspects the *Credential* needs access to both the human-recognizable biometric and the hash of the biometric in order to verify the integrity of the Name and various other attributes. *QR codes*: If the size of the *Credential* is limited, then the biometric template used to calculate the hash of the biometric needs to be a compromise between human recognition of a live person and a size small enough for efficient encoding of the biometric. This is a well-understood compression problem. Involving a notary in a presentation transaction is expensive and inconvenient. What happens if your Verifier is presented with the credential directly? In that case, live presentation of the credential is still required and the risk of biometric aggregation is now increased. However, the biometric aggregation risk can be mitigated to the extent that compression of the biometric makes it much less useful as a facial recognition input when the long lived Credential is not involved. This reduces the risk of ambient authentication a la Clearview AI. In summary, hashed human-recognizable biometrics can be the basis of linking long-lived Credentials to transactions whether a notary is involved or not. To the extent linkage across credentials is based on human recognition, this works even when multiple Credentials are presented, each having a different biometric of the same person. Well understood image compression technology makes presentation of DIDs or credentials as QR codes practical. In many use cases, verifiable presentation and the need for Subjects to use an app to sign a challenge can be eliminated. - Adrian

…

On Wed, Nov 3, 2021 at 12:36 PM Dmitri Zagidulin ***@***.***> wrote: @vongohren <https://github.com/vongohren> When you say unrelated credentials, that is unrelated to each other credentials and not unrelated to the DID right? Good question. It's both -- in the VP case, the individual VCs inside the VP may be unrelated to each other. And ALSO, they may have different credentialSubject IDs from each other, and those IDs can be different from the DID of the holder who signed the VP. Does that make sense? A VP (at least in the current VC Data Model spec) is an envelope for arbitrary different VCs; the credentials don't have to be about the same subject, nor do they have to be about the presenter who is handing them over. (I'll try to answer your other question in the next comment.) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#831 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YPI7QP22KSUXHUCRC3UKFXIXANCNFSM5HHUDLOQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[cjbuchanan]

@agropper

What's the use of all this linked data if we can't see it? This is the World Wide Web Consortium. We make webs for the entire world! A web has to be complicated enough that people stop asking how it works and just get caught up in it.

If we depend on human readable credentials, we won't be able to use the link hashes to triangulate a person's activities across multiple VCs. That's a whole new market to exploit! Plus, the photo hosting platform won't be able to see where, when, and how the link is being used. The person would become invisible to the identity ecosystem. Don't you think that's a little too private? What if they commit crimes? Police would have work harder. That's expensive. People would have to be hired to do the inspection. People are very expensive. It sounds like you value privacy more than money / open society.

[agropper]

Let’s start with a slide by @cjbuchanan on p193 of Proceedings of the 31st Internet Identity Workshop. Transcribed as:

Digital Identity is Not Equivalent to Physical Identity.

Transience

• Most physical identity transactions are transient and quickly forgotten.
• The internet never forgets.

Retransmission

• The physical world is severely limited in its ability to transmit and consume data and must therefore be selective.
• The internet’s entire purpose is efficient retransmission of data.

Degradation

• Physical world data degrades in both quantity and quality over time and when it is retransmitted.
• Digital information is perfectly preserved in storage and retransmission.

© 2020 THE MITRE CORPORATION. APPROVED FOR PUBLIC RELEASE. DISTRIBUTION UNLIMITED 20-00971-2.

Standards-based digital credentials make surveillance vastly more efficient for all parties acting as service providers:

• Issuers participate when verifiers “call home” for a VC or a revocation status.
• Holders participate when wallets and other user agents are “certified” as platforms or effectively mandated by convenience Holder: store <credential> w3c-ccg/vc-api#71.
• Verifiers participate when subjects are not anonymous.
• Notaries participate when mandated by law or the asymmetric power of institutions.

Much of the security and privacy engineering related to VCs is driven by the desire to make digital identity socially acceptable by mitigating the risks of surveillance. BBS+, Zero Knowledge Proofs, Dead-Drop revocation lists, and Decentralized Public Ledgers are prominent examples of our community’s concern for the risks associated with digital identity, including VCs. These are considerations of the data model designs and we have done great work on the VC and DID data models.

We now need to do great work on the protocols that are the essence of surveillance #252, w3c-ccg/vc-api#237 (comment).

Mitigation of surveillance risk falls within four broad categories:

• Bearer credentials (e.g. cash)
• Expense (e.g. more technology, fewer standards, human interaction, court order)
• Technology (e.g. zero knowledge proofs)
• Mediators (e.g. cryptocurrency tumblers, differential privacy agents, notaries, Audit trails for Issuers and Verifiers w3c-ccg/vc-api#189)

VC-API is the one protocol in a position to create and deliver VCs to other actors including Subjects, Holders, Controllers, Mediators and Verifiers. I propose we consider all four surveillance mitigation categories in our work and specifically that we avoid VC-API designs that would compromise the use of any of the four mitigation strategies.

[kayaelle]

The IMS Global Comprehensive Learner Record (CLR) standard has something like this to associate achievements to each other but being able to associate assertions/credentials like this would be useful. This is the reference for the CLR achievements association:

https://www.imsglobal.org/sites/default/files/spec/clr/v1p0/InfoModel/clr_InfoModel.html#Data_Association

[dmitrizagidulin]

@kayaelle - Thanks!

[dmitrizagidulin]

I updated the proposal to include a canonicalizationAlgorithm property, in the anchoredResource section.
This optional property means "the content was processed with the following canonicalization algorithm (such as JCS) before being hashed".

[kayaelle]

The IMS Global Comprehensive Learner Record (CLR) standard has something like this to associate achievements to each other but being able to associate assertions/credentials like this would be useful. This is the reference for the CLR achievements association:

https://www.imsglobal.org/sites/default/files/spec/clr/v1p0/InfoModel/clr_InfoModel.html#Data_Association

Also, another example in related to what I believe @ChristopherA is referencing is endorsements. Open Badges has a concept like this: https://www.imsglobal.org/sites/default/files/Badges/OBv2p0Final/index.html#Endorsement

In 2.0, endorsements can be about OB profiles, badge classes, and assertions. In OBv3 we could consider that an endorsement claim references another asserted badge or single skill assertion. A use case being discussed would be a self-assertion VC of a skill and then an endorsement VC of that self-assertion such as an employee claiming they learned a skill at a job and an employer endorsing that. Both of these VCs may be in the employees wallet and presented together and it would be useful to be able to link them together in a verifiable way in the endorsement claim.

[radhertz]

A third approach, mentioned above by @oed is leveraging a separate infrastructure to host a VC endorsement, using the hashlinking approach to connect that VC to the particular attributes of an issued VC in the holders wallet. These we hope to talk about Monday Dec. 6th at @kayaelle's VC-EDU meeting. I hope many of the people commenting here participate as we need all the help we can get on this.

[kdenhartog]

I updated the proposal to include a canonicalizationAlgorithm property, in the anchoredResource section. This optional property means "the content was processed with the following canonicalization algorithm (such as JCS) before being hashed".

Is there an expectation that many different forms of canonicalization will be necessary to achieve this feature? I know in the past we've allowed for alot of extensibility which has come at the cost of interoperability and so I'm wondering if it's actually valuable for us to allow for this extension path if we're able to achieve the same outcome in either case.

[radhertz]

@dmitrizagidulin Does your method #3, issuing a fit-for-purpose VC that binds DIDs together, require the two DIDs are both assigned to Alice? Imagine I have two separate VCs, one associated with Alice's DID and one associated with Bob's DID, The first, Alice's, is an assertion about a skill or competency she has demonstrated. The second is an endorsement VC created by Bob where in he is supporting the issued assertion made to Alice as the subject of the skill credential. Does the method you describe enable the two VCs to be bound together and provide a tamper evident connection? Who is issuing this linking VC?

[agropper]

Isn’t this exactly what notaries do in the world? However we decide to support or describe notarization we need to be clear about this very common use case.

…

On Sun, Dec 5, 2021 at 2:59 PM Phillip Long ***@***.***> wrote: @dmitrizagidulin <https://github.com/dmitrizagidulin> Does your method w3c/vc-data-model#3 <#3>, issuing a fit-for-purpose VC that binds DIDs together, require the two dids are both assigned to Alice? This, imagine I have two separate VCs, one associated with Alice's DID and one associated with Bob's DID, The first, Alice's, is an assertion about a skill or competency she has demonstrated. The second is an endorsement VC created by Bob where in he is supporting the issued assertion made to Alice as the subject of the skill credential. Does the method you describe enable the two VCs to be bound together and provide a tamper evident connection? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#831 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YPGTAY5KMVJXGQXN6TUPPHERANCNFSM5HHUDLOQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[peacekeeper]

Just a quick note that this issue here could also be relevant to the new RDF Dataset Canonicalization and Hash Working Group: https://www.w3.org/groups/wg/rch

@philarcher

[TallTed]

(bikeshedding) Maybe change from anchoredResource to externalResource? I think anchored implies attributes which may not be true for the target (including that it's under the clear control of the VC issuer who's including this property in their VC).

[iherman]

The issue was discussed in a meeting on 2022-08-24

• no resolutions were taken

View the transcript

3.3. Proposal: Anchored Resources and Hashlinks for VCs (issue vc-data-model#831)

See github issue vc-data-model#831.

Kristina Yasuda: ... Dmitri would you be able to talk to hash links for VCs?

Dmitri Zagidulin: Sure. In a lot of use cases in the VC world, we need a way to bind not only objects in the VC but also bind other external VCs or other external / outside resource like a PDF.
… Towards that, this issue proposes two new terms that could be used separately or together. One is "anchoredResource" -- the general semantic is that in order to fully verify the signature of this VC, you're going to likely have to fetch other objects and fetch their signature as well.
… The other part of this is the hash link part of this -- that's digestMultibase, it is meant to be paired with the id and whenever you have those two together (and object identified by id with a digestMultibase property).
… Then you can use the multibase encoding to express all of the parameters around the hash, such as hash algorithm and canonicalization algorithm.
… So to summarize, anchoredResource and digestMultibase allows us to bind multiple resources and VCs together.
… It also allows us to do use cases like "endorsement" where you are issuing a VC about another VCs.
… Any questions about the proposal?

Kristina Yasuda: I think people are interested in the use case. I think we want to discuss how we want to address it.

Michael Prorock: I really appreciate this PR / proposal and discussion on it. We run into it a lot on the supply chain side of the world. The thing that threw me a little bit. The first is calling it an anchored resource. The broader use case is to point at some external system. That may or may not be able to have a hashlink with it.
… There might be some UID or something like that -- the use cases we have you may look up some organic certification. How we're handling that today is very similar to what is proposed here. The other two is to attach some additional meta data and structure and vocabularies.
… The third is to use vocabulary terms to define evidence.
… It's definitely a valid use case and we need to bridge the VC world with legacy / traditional systems. It's a useful thing to do but it feels constrained to referring to it as anchors or using hash links. I'm not sure we need to standardize that.
… There are a lot of things like lab results and other external docs we want to reference.

Michael Jones: I'm going to bitch about the use of multibase, it's not a standard in any standard organization. It's a draft subject to change. That's one of the things that resulted in the formal objections to the DID specs. I don't think we should start repeating that mistake.
… There are plenty good IETF hash specs that could be used so that we're only relying on standards.

Michael Prorock: +1 selfissued - multibase is one of the specifics that concerns me.

Gabe Cohen: -1 - it has broad usage, standards don't need standards bodies to gain wide usage/adoption.

Manu Sporny: Multibase just went out to dispatch at IETF. The expectation is that it will be a standard soon with air quotes around "soon". I think focusing on multibase misses the point. This is important, there are multiple industries, supply chain, education, retail that are all using some variation of pattern here.
… It would be great if they were all using the same pattern.
… Multiple industries are solving this in different ways that are incompatible and we're well positioned to propose something that would work for all of them.

Michael Prorock: +1 manu - this is a pattern recognition item - i will note that not all items have a hash or hash link ability.

Phil Archer: This sounds like something really important to use at GS1. We will look at it in detail and we're glad to see it.

Michael Prorock: +1 Phil.

Kristina Yasuda: Thank you everyone, that was a great call!.

Kerri Lemoie: Thanks!.

Gabe Cohen: ietf multibase - https://datatracker.ietf.org/doc/html/draft-multiformats-multibase.

---

[dmitrizagidulin]

In the 2022-08-24 meeting, it was suggested that the two proposals in this issue should be extracted to separate issues.
These will be:

1. digestMultibase standalone proposal - issue Proposal: Chaining VCs via links and digests #952
2. anchoredResource standalone proposal - tbd

[amiller-ims]

@dmitrizagidulin 1EdTech's CLR standard also has a mechanism to link VCs together as peers or as parent/child relationships, but the relationships are explicit. For example, the issuer of a CLR VC can say that VC1 is the parent of VC2 and that both VC1 and VC2 are contained in CLR VC's credentialSubject.

(Short summary of CLR: It looks very much like a VP, but it is a VC, and the set of contained VCs is in the credentialSubject making it clear that they are all about the CLR subject even if each contained VC uses a different credentialSubject.id. For example, a university can issue a CLR transcript where each degree, course, co-curricular activity, etc. is represented by a VC possibly issued by a sub-contractor that 'knows' the student by a different id than the university.)

Thinking about a future CLR standard that uses achoredResource to link VC1 and VC2 to the CLR VC and to each other instead of containing them, do you think achoredResource could also make the type of association (isParentOf, isChildOf, isPeerOf) explicit? The type of association is important for some CLR use cases such as a transcript.

[OR13]

I still wonder about this...

When is a URL enough?

When is an @id like sha256:0123ABC enough?

Why is multibase a requirement?

Do VCs need a RDF type to explain what a hash is? (like proof.type)...

What about JWK thumbprint URNs?

What about compression in content id systems? Which hash to use?

There have been some recent software supply chain issues with compression and hashes ...

https://news.ycombinator.com/item?id=34586917

[brianorwhatever]

When is an @id like sha256:0123ABC enough?

is that how you use it? ChatGPT says it's like this:
"@id": "urn:sha256:7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069"

[aljones15]

one small question:

Provide a mechanism with which to link multiple VCs together

If all that is being linked to is other VCs doesn't anchoredResource seem a bit of a high abstraction level? I was assuming an anchoredResource could link to any resource such as a digital camera on a local network, a REST API on an external server, a Kafka Que topic, a pdf, etc. If all anchoredResources are VCs then why not using terminology relevant to VCs in the name in case a future VC does need to link to an external resource that is not a VC? Some more relevant names: supportingClaim, externalClaim, linkedCredential, anchoredClaim? My apologies if I'm not completely understanding the topic in question. Do all anchoredResources refer to VCs that represent a resource such as a photograph? I feel like anchoredResource might be better as a type for a credentialSubject.

Also of note the CLR standard mentioned earlier is here and has some great ideas on linking VCs together.

[OR13]

@brianorwhatever it knows what a hash is supposed to look like, and how to encode base64url... but sadly its not secure in the random oracle model.... the syntax it proposes is indeed valid... even if the hash is made up :)

I remain annoyed by things like this....

 "evidence": {"@id": "cred:evidence", "@type": "@id"},

• https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v1#L39

Seems like we have already solved for the problem... "evidence" is a name for an "identifier"...

Why can't we use "evidence" for this use case?.. and embed the "type" in the identifier?... like what ChatGPT suggests?

This is also the approach taken in multi codec.... and URNs at IETF generally, for example:

• https://datatracker.ietf.org/doc/rfc9278/
• https://datatracker.ietf.org/doc/html/draft-thiemann-hash-urn-01
• https://datatracker.ietf.org/doc/html/draft-mealling-uuid-urn-03#section-3
• https://www.w3.org/TR/did-core/ (not a URN... but... looks like one)

Why do we need a new "predicate" ?

Note that GS1 invented "extendsCredential"... https://w3c-ccg.github.io/traceability-vocab/#GS1KeyCredential

• https://gs1.org/voc/extendsCredential

• https://ref.gs1.org/gs1/vc

We seem to really like to create new predicates for "identifier links"... but does that help or hurt the knowledge / information representation and processing / querying behaviors...

[OR13]

Recently seen on the IETF lists:

https://github.com/TheELNConsortium/TheELNFileFormat/blob/master/SPECIFICATION.md

{
    "@id": "./2022-05-29 - Some-experiment/2022-05-30-export.elabftw.csv",
    "@type": "File",
    "description": "CSV Export",
    "name": "2022-05-30-export.elabftw.csv",
    "contentType": "text/csv; charset=UTF-8",
    "contentSize": "247",
    "sha256": "f3278e796c687371cc63a600b6f12ea32167067fed3ef98099d0c1aad2426531"
}

cc @mprorock ^ maybe a thing you would like.

[dlongley]

@OR13,

Why do we need a new "predicate" ?

You're not talking about the same thing if the identifier changes (at least, you can't know that without special reasoning software). When you want to link to an external VC (or any resource) that has identifier X and add a statement that you expect its hash to be <hash>, that's not the same thing as linking to an external resource with the identifier <hash>. So all of this depends on what you're trying to achieve in your use case.

This affects the ability to merge graphs of information together using simple tools. This can get particularly awkward when trying to combine statements from within the VC (which necessarily can't use the content-based identifier) and statements made externally about the VC. If this is what you want / you don't care about this, use a content-based identifier. If instead, you want or need these sorts of capabilities, use a predicate to express the hash. The safest approach is to use a predicate so everything is additive, ensuring capabilities aren't lost and there isn't confusion / extra reasoning software required.

[OR13]

This affects the ability to merge graphs of information together using simple tools.

Which tools?

The safest approach is to use a predicate so everything is additive, ensuring capabilities aren't lost and there isn't confusion / extra reasoning software required.

Is support for "software reasoning systems", a design goal for W3C Verifiable Credentials?

If so, which specific systems? Can we add some citations regarding this?

[dlongley]

@OR13,

Which tools?

Standard JSON-LD processors using the JSON-LD framing API are the simplest / most common that come to mind.

Is support for "software reasoning systems", a design goal for W3C Verifiable Credentials?

Well, we already support such systems to some extent by publishing vocabularies, etc. I don't think we're looking to do more than that at this time.

[OR13]

I'd like to cover the framing APIs informatively, next to the data model, if possible... Developers should understand why we put all the effort in... Otherwise it seems hard to argue for 1 representation over another in the context.

I added w3c/vc-data-integrity#107 to keep this thread focused on relationships between things that might have hashes.

[Sakurann]

also pending close on #952

[iherman]

The issue was discussed in a meeting on 2023-04-11

• no resolutions were taken

View the transcript

1.12. Proposal: Anchored Resources and Hashlinks for VCs (issue vc-data-model#831)

See github issue vc-data-model#831.

Kristina Yasuda: suggests pending close on "Proposal: Anchored Resources and Hashlinks for VCs" as well.
… ....
… going back to list for one more.

[iherman]

The issue was discussed in a meeting on 2023-04-11

• no resolutions were taken

View the transcript

1.12. Proposal: Anchored Resources and Hashlinks for VCs (issue vc-data-model#831)

See github issue vc-data-model#831.

Kristina Yasuda: suggests pending close on "Proposal: Anchored Resources and Hashlinks for VCs" as well.
… ....
… going back to list for one more.

[brentzundel]

No objections since being marked pending close, closing.