Re: VC Evidence Discussion

Yes - these are great questions. Verifiability and ownership of the evidence is something we should consider. I suspect we’ll need to kick that down the road a little based on where we are now in this transition but we should revisit it. 



> On Apr 7, 2022, at 3:21 PM, Steve Capell <steve.capell@gmail.com> wrote:
> 
> Agree with Michael about clear separation. And with Phillip about maintaining integrity of linked data using hashlinks.  The ability to discover a graph of linked credentials is core to many of our use cases
> 
> But what im less sure about is where to put the linked credential list 
> - in the Extensibility mode as the VC specification seems to hint?
> - in the Evidence model as Kerri suggests  ?
> - somewhere in the VC specific claims structure(not keen on this one)?
> 
>  and, wherever the linked credential list goes, what is its structure?
> - a simple list of hashlinks? - verifier would have to follow all to find the one they want
> - an array of type / hashlinks pairs ? If so, how to consistently represent the type of the linked credential?
> 
> If the group has reached some consensus on the best way to represent linked credentials that would allow verifiers to construct trust graphs - I’d be very keen to hear about it
> 
> Many thanks - and my apologies Kerri if this question is misaligned with your question ..
> 
> Kind regards 
> 
> Steven Capell
> Mob: 0410 437854
> 
>> On 8 Apr 2022, at 4:47 am, Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net <mailto:mwherman@parallelspace.net>> wrote:
>> 
>> 
>> As a general pattern, consider a clear separation of the “thing” from the ownership rights and assignment of those rights to another entity (e.g. person or organization).
>>  
>> A VC is an obvious representation of the thing whether it be an educational achievement, an NFE in an NFT, or house (in the case of homeownership). Use a second VC to represent the ownership rights and the assignment of those rights to an actual person or organization (a verifiable capability authorization is useful for the latter).
>>  
>> …more or less applying the concepts of traditional database normalization to the world of VCs.
>>  
>> Michael
>>  
>> From: Kerri Lemoie <klemoie@concentricsky.com <mailto:klemoie@concentricsky.com>> 
>> Sent: Thursday, April 7, 2022 11:04 AM
>> To: W3C Credentials CG (Public List) <public-credentials@w3.org <mailto:public-credentials@w3.org>>
>> Cc: public-vc-edu@w3.org <mailto:public-vc-edu@w3.org>
>> Subject: VC Evidence Discussion
>>  
>> Hello all,
>>  
>> I’m seeking some input on VC evidence. This is a topic relevant for VC-EDU because education data specifications like Open Badges and CLR may contain an evidence property to support the achievement. This evidence could be a test score, a link to an image, video, and/or web page, etc. that demonstrates competency or participation. These specs are working towards aligning with VCs and it was originally thought that this type of evidence would be included as part of the credentialSubject if it existed.
>>  
>> This would look something like this:
>>  
>> https://json.link/21SpTf0rC4 <https://json.link/21SpTf0rC4>
>>  
>> But since VCs already have an evidence property that allows for an array of evidence, it seems to make sense to use that property instead of using a separate property like the one demonstrated above. The rationalization is that VC evidence could be an array that supports what is needed for a credentialSubject to offer to support the verifiability of a VC such as a student id or it could also support the achievement that is being claimed as discussed above. This would look more like:
>>  
>> https://json.link/0gqe5D1U4K <https://json.link/0gqe5D1U4K>
>>  
>> Can you share your thoughts on this second approach? Do you think the VC.evidence support the achievement evidence too? 
>>  
>> Thanks!
>>  
>> Kerri
>>  
>>  
>> 
>> --------
>> Kerri Lemoie, PhD
>> Director, Digital Credentials Research & Innovation
>> badgr.com <https://info.badgr.com/> | concentricsky.com <https://concentricsky.com/>
>> she/her/hers