Re: Proposal: Anchored Resources and Hashlinks for VCs

I also intended to write: Thanks for this proposal, Dmitri! 




> On Nov 3, 2021, at 2:33 PM, Kerri Lemoie <klemoie@concentricsky.com> wrote:
> 
> In Open Badges, there is evidence which can be artifacts that demonstrate or support an achievement:
> 
> https://www.imsglobal.org/sites/default/files/Badges/OBv2p0Final/index.html#Evidence <https://www.imsglobal.org/sites/default/files/Badges/OBv2p0Final/index.html#Evidence>
> 
> So far, our modeling for vc alignment includes this evidence in the credential subject so that it is evidence of the claim (not the assertion).
> 
> This is a link to the proposal that includes examples: https://github.com/IMSGlobal/openbadges-specification/files/6977048/Proposal-Open-Badges-3.0-update-08-11-2021.pdf <https://github.com/IMSGlobal/openbadges-specification/files/6977048/Proposal-Open-Badges-3.0-update-08-11-2021.pdf>
> 
> Even though the Open Badges evidence property is different than the VC one, I’m including it because I had to look it up to make sure and it could be that we discuss the utility of evidence related to achievements in VC-EDU. 
> 
> I interpret evidence supporting the VC assertion to be about the assertion - maybe contextual content?
> 
> K.
> 
> 
> 
> 
> 
> 
>> On Nov 3, 2021, at 2:06 PM, Dmitri Zagidulin <dzagidulin@gmail.com <mailto:dzagidulin@gmail.com>> wrote:
>> 
>> @Brian Richter - ah, yeah, makes sense, re the 'evidence' property. And I agree, it's not quite the right mechanism for linking VCs.
>> 
>> But I'd also be really curious, as to if anyone is using 'evidence' in the wild, and what are you using it for.
>> 
>> On Wed, Nov 3, 2021 at 12:57 PM Brian Richter <brian@aviary.tech <mailto:brian@aviary.tech>> wrote:
>> This is great Dmitri, I've been looking forward to investigating chained credentials and how we can create them.
>> 
>> My first thoughts when I started investigating the VC data model was that this was what 'evidence' would be used for but I quickly realized that's meant for a different purpose.. which I'm not sure is being used by anyone.
>> Wondering if anybody else had thoughts along these lines or is using the evidence property in the wild?
>> 
>> Brian
>> 
>> On Wed, Nov 3, 2021 at 3:50 AM Oliver Terbu <oliver.terbu@mesh.xyz <mailto:oliver.terbu@mesh.xyz>> wrote:
>> This sounds interesting.
>> 
>> @Dmitri Zagidulin <mailto: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 <mailto: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
>> 
>> Provide a mechanism with which to link multiple VCs together (as peers or as parent/child relationships).
>> 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://www.w3.org/2018/credentials/v1>",
>>     "https://w3id.org/security/suites/ed25519-2020/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 <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 <https://github.com/w3c/vc-data-model/issues/831> !
> 

Received on Wednesday, 3 November 2021 18:37:48 UTC