- From: Oliver Terbu <oliver.terbu@spruceid.com>
- Date: Fri, 8 Apr 2022 12:33:56 +0200
- To: "Joosten, H.J.M. (Rieks)" <rieks.joosten@tno.nl>
- Cc: Kerri Lemoie <klemoie@concentricsky.com>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>, "public-vc-edu@w3.org" <public-vc-edu@w3.org>
- Message-ID: <CAP7TzjC=1cbXNSMT19-_nQErwOh+QofCEwU--x+44xXOHiXMxA@mail.gmail.com>
Rebase also used `evidence` for proof of verification: https://github.com/spruceid/tzprofiles. We are also thinking to use `evidence` for VPs to express additional info needed for holder binding. On Fri, Apr 8, 2022 at 12:04 PM 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> > *Sent:* Thursday, April 7, 2022 11:04 AM > *To:* W3C Credentials CG (Public List) <public-credentials@w3.org> > *Cc:* 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 > > 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 > > 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 > 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. > >
Received on Friday, 8 April 2022 10:34:20 UTC