Re: VC Evidence Discussion

Hi Rieks,

I read the evidence property in the spec as validation too and in reference to this documentation: https://github.com/w3c-ccg/vc-api/blob/main/verification.md#validation <https://github.com/w3c-ccg/vc-api/blob/main/verification.md#validation> validation may include "Subject attributes listed in the credential” which in the vc-edu credentials can reference the achievement definition. 

My thought is also that it doesn’t really matter where the evidence sits as long as the type id defined and references documentation that it explains it to the verifier. I also think it will be less confusing for a verifier to pull supporting evidence form one location in a VC.

I appreciate reading the examples people are providing. So far not seeing anything that contradicts the above thinking. I’ll be happy to help provide use cases for evidence as we dig into the next version.

Thanks!

Kerri







> On Apr 8, 2022, at 6:02 AM, Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl> wrote:
> 
> Let’s stick to what the VC data model 1.1. says about the intention of the evidence <https://www.w3.org/TR/vc-data-model/#evidence> property, which I read as ‘a means to facilitate data validation’ (while the validation itself is outside scope of the VC spec <https://www.w3.org/TR/vc-data-model/#dfn-credential-validation>).
>  
> I see data validation <https://essif-lab.github.io/framework/docs/terms/validate> as an action that a party performs after it has received (and verified) data (e.g. a presentation). It results in a decision that says whether or not that data must be considered ‘valid’ for further processing, e.g. whether the party trusts the data sufficiently to continue to work with it, or in still other words: whether or not the risk of such processing being ‘invalid’ as a result of working with that data, is acceptable.
>  
> One may readily observe that criteria that a party will use will depend on the context, the purpose for which the data will be used, the party’s risk appetite, etc. Validation criteria are highly context sensitive and subjective. There is no one-size-fits all.
>  
> However, the (define time) specification of validation criteria, and the (run time) use thereof, will benefit from the presence of ‘assurances’, that may constitute of evidence that the data is produced or vetted in a specific way (by an official exam, a specific medical test), or by an actor that has specific qualifications (e.g. certificates, accreditations), etc.
>  
> I see the ‘evidence’ property as the place to put data, that is evidence to whatever validators might be needing in (not so) specific cases, and that they could design validation criteria around.
>  
> I think it is undecideable whether data should be ‘evidence’, or should be part of the credentialSubject object. That is because what one validator would consider assurance/evidence, another would consider as part of the data that it needs for further processing. Here’s an example
>  
> Consider Alice, a patient that needs to transfer to an elderly home. Her application needs to come with her treatment plan, for which she has a credential, which has properties e.g., the organization on whose behalf the plan was drafted, and the qualifications of the person that drafted it. One elderly home may decide that the application is only valid if the treatment plan was drafted by a qualified nurse (“it’s the law”), in which case such qualifictions may be considered ‘evidence’. Another elderly home may decide that the application is valid if there is treatment plan, and use the qualifications of its author in the caring process, as input for determining when and how to review the treatment plan. In that case, the same data would not qualify as ‘evidence’ as intended by VC 1.1.
>  
> Does this pose a problem? I think not. From the perspective of any validator (b.t.w., do we want to have this role in the SSI ecosystem?), it really doesn’t matter where the supporting data/evidence sits, as long as it can be found and the software they use can find and present it. With a properly defined schema that should be a big deal.
>  
> Rieks
>  
> 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
>  
>  
>  
>  
> 
>  
>  
> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.