vc-data-model
vc-data-model copied to clipboard
w3c
add claims metadata (how the identity claims were assured and how they are maintained)
Credentials section says that "the basic components of a verifiable credential" are credential metadata, claims, and proofs.
From the implementation experience, one gap is the absence of "claims metadata". Not the credential metadata, when the VC itself has been issued, but "information about the process conducted to verify a person's identity and bind the respective person data to a user account", which is super important is some use-cases.
Suggest re-using verification element defined in ekyc-ida specification.
probably in-scope for data model deliverable.
I think what you're asking for may have already been dealt with, albeit imperfectly, as the Evidence property of the VC data model...
@RieksJ -- It seems to me that #248 contemplates a wish for certificate metadata, as "Driving (a/k/a Driver's) License" would seem to be applicable to the entire VC, not to (a) specific claim(s) therein.
It also seems to me that the "claims meta-data" attributes satisfied by things like the "Driving (a/k/a Driver's) License" string mentioned there may already be satisfiable by simply describing the VC Type (or even the specific VC) appropriately [e.g., by using rdfs:label, skos:prefLabel, rdfs:comment, and/or dct:description, among others, for human-focused labels or descriptions at varying levels of detail].
In other words, there's nothing to prevent the issuer of, continuing with your example from #248, "Driving Licenses", including rdfs:label "RieksJ's Driving License"@en therein...
Have you looked at the "evidence" claim that OIDF eKYC uses? https://openid.net/specs/openid-connect-4-identity-assurance-1_0-13.html
The issue was discussed in a meeting on 2022-08-31
- no resolutions were taken
View the transcript
4.2. add claims metadata (issue vc-data-model#893)
See github issue vc-data-model#893.
Brent Zundel: kristina, can you walk us through this?.
Kristina Yasuda: the question was... where to put the metadata about "claims"....
… how do we know how to use "evidence"... can we keep this issue open until we can align with identity assurance.
Manu Sporny: the confusing word is "what is meant by metadata"..
… in theory you can add any metadata that you want, at any level....
… we should probably address this in a use case specific format... like the assurance example and evidence... in person, IAL... etc... we should be more specific.
… are "evidence" and "revocationStatus" metadata?.
… can't tell if this applies to other metadata properties not associated with assuancee.
Kristina Yasuda: was thinking mostly about trust frameworks, government and finance use cases... passport was used to verify the claims, etc....
… evidence seem like the correct place, but there is a vocabulary for assurance that the UK refers to... and the question is how to leverage / integrate the UK vocabulary with the W3C evidence vocabulary..
Oliver Terbu: I was involved in some projects related to this... european ssi framework... they have their own context and schemas, and they use evidence..
… they cover, what did the issuer verify prior to credential issuance..
… I think folks would want to define their own evidence type and register it..
Dave Longley: +1 to oliver.
Manu Sporny: Yes, exactly what Oliver just said -- +1.
Oliver Terbu: people need to evidence type to understand the evidence and the vocabulary it relies on.
Kristina Yasuda: @manu will update the issue to clarify what is meant by metadata in the issue.
Logan Porter: I think we are talking about 2 different things... the current evidence property is more like where the claims came from..
… like name came from passport or drivers license..
… but we are also talking about assurance, which is about how that is checked, in person, remote, etc....
… we might want to distinguish between these uses of the evidence property..
Antony Nadalin: I think I agree with Logan... there is evidence types and method types..
Manu Sporny: the evidence property is currently any information that the issuer can include to help the verifier decide..
… I see this as 2 entries in the evidence property, one speaking to IAL, the other speaking to trust framework..
… authenticators are another type of evidence.
Oliver Terbu: I wanted to add that folks should define their own evidence types as needed by their trust framework.
Manu Sporny: yep, +1 Oliver.
Dave Longley: +1.
to clarify in response to the WG conversation, what I meant by "metadata" was "information about how the identity claims were assured and how they are maintained".
to clarify in response to the WG conversation, what I meant by "metadata" was "information about how the identity claims were assured and how they are maintained".
I believe this is the original intent of the evidence property, so it may be good to adjust that rather than introduce another property.
https://docs.google.com/document/d/1htujrb-_1kh8tkV4MXYRmZ44m_D7yFrY09aFJkAz7io/edit
[added context on 2023-02-02] This document was a submission to CCG and was mentioned during the call as a concrete mechanism that will help move this issue forward.
The issue was discussed in a meeting on 2023-01-18
- no resolutions were taken
View the transcript
4.4. add claims metadata (how the identity claims were assured and how they are maintained) (issue vc-data-model#893)
See github issue vc-data-model#893.
Kristina Yasuda: this is regarding evidence and assurance.
… there as not been much movement on this.
… chair hat off, I would be ok closing this, if we had better detail on the use of evidence property.
Manu Sporny: +1 for special topic call on Evidence..
Kristina Yasuda: there are several issues labeled evidence, it seems like a potential special topic call.
David Chadwick: W3C CCG is attempting to define a standard evidence property type.
… this new work item would create a standard evidence type for OIDC.
… the data structure would be controlled by OIDF.
… its a proposed item, it was very recently introduced.
… its written with arcaine.
Kristina Yasuda: please link to the issue.
David Chadwick: https://docs.google.com/document/d/1htujrb-_1kh8tkV4MXYRmZ44m_D7yFrY09aFJkAz7io/edit.
Kristina Yasuda: seems the CCG item could resolve the issue.
Manu Sporny: we should discuss here.
David Chadwick: we didn't think it was in scope for this WG, happy to move it here, if thats preferred.
… what I pointed out to the CCG, there were 2 features that were interesting....
… people change their names, and that can impact evidence....
… evidence can disagree with credentials.
… another issue was wrt selective disclosure....
… you can accidentally leak information through use of evidence.
Orie Steele: If we refer to this evidence type from our document, I don't believe we can point directly at a W3C CCG work item. We are compelled to provide testable solutions for the property or remove it from our specification, this feels further along, but we can adopt the work item as the WG, use the work item as one of the registered types, then we are protected by downref. I'm concerned about pointing to something that's not within the group and a different timeline. I'm excited about the work. I'm concerned about potential objections, there's process issues here that we might want to consider. There are potential objections that could come if we don't have a strong evidence type in our next spec..
Kristina Yasuda: please review the document that was been shared.
… lets end here today.
David Chadwick: @Orie arcaine to Mark Haine.
@Sakurann — I have significant concerns with the "Definition of Evidence Type for W3C Verifiable Credentials Data Model for High Assurance Individuals" Gdoc you linked above [ETA-2023-02-06: which did not have any contextualizing comment, when it was originally linked] —
- starting with the W3C logo at its head
- moving to its author, OpenID Foundation eKYC & IDA Working Group, which is not part of W3C in any way
- continuing into the garbled Copyright statement ("the Contributors to the A Template for W3C Credentials Community Group Specifications Specification, published by the Credentials Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.")
- and continuing through to the end of the meat of the Gdoc.
(If this Gdoc is not meant to be reviewed yet, that should be noted along with the link to it, above.)
to clarify in response to the WG conversation, what I meant by "metadata" was "information about how the identity claims were assured and how they are maintained".
It may be very important for a verifier to know how the identity claims were assured and how they are maintained. However, in such cases, I would think that the verifier would want to know this before it would have its applications request presentations for such claims. So I am not convinced that this kind of information would serve any purpose in real-world use cases.
There are definitely real-life use cases requiring strong assurance, for example, to comply with regulatory requirements such as Anti-Money Laundering laws or access to health data, risk mitigation, or fraud prevention. They require identity information, along with an explicit statement about the verification status of these Claims (what, how, when, according to what rules, using what evidence). This is why quoted ekyc-ida spec exists and is being implemented in various jurisdictions - definitely in Europe and Japan.
@TallTed the document was contributed to W3C CCG and was mentioned during the call as a concrete mechanism that will help move this issue forward, so the WG members was encouraged to read it. it was the first time I saw the document during the call, and I agree we need to figure out the relationship of this document and the work in W3C VC WG. But I personally do not appreciate the strong language you use such as a word "garbled" and a dismissive attitude towards the content.
would want to know this before it would have its applications request presentations for such claims.
I don't think this is feasible in an open environment. Rather, using a request syntax such as DIF PEv2 it is possible for the verifier to craft a request to a wallet that will only return VCs that have the necessary LoA or Evidence that the verifier requires. For this to work on a global scale we need to standardise features such as the LoA and other Evidence properties. The draft that we have submitted to the CCG is the start of this process. (And in the recent NGI Atlantic project we specified a way of standardising the LoA as an Evidence property)
@Sakurann —
I am surprised to see that my label of "garbled" is considered "strong language". I meant that the copyright statement was difficult to understand; unclear; confusing ... which are the meanings Google shows me, without any hint that its use might be considered problematic.
I do feel strongly, and may indeed use strong language to express that, that the status of this document not be misrepresented going forward (and which misrepresentation I trust has been unintentional to date), which should include but not be limited to the rapid removal of the W3C logo and/or the correction of the existing misrepresentation of the "Status of This [draft] Document" as W3C CCG output until such time as the CCG as a whole, or at least a quorum thereof on a telecon, approves it as such.
As to what I previously labeled as "garbled" (which label I stand by), I have now read over that copyright statement several more times, and may have deciphered that it was intended to say that copyright on the Template for W3C Credentials Community Group Specifications is held by (note the quotation marks and boldface on what follows, which radically change the meaning of the phrases without these formatting and punctuation elements)
the Contributors to the "A Template for W3C Credentials Community Group Specifications" Specification, published by the Credentials Community Group under the W3C Community Contributor License Agreement (CLA).
This is still something of a guess, as I cannot find any such template published by the CCG, only a gist from @msporny.
Even if I've deciphered the intended meaning correctly, this remains an incorrect copyright statement, as the Gdoc as it stands is no longer the Template, but is rather a draft-in-progress of a "Definition of [an] Evidence Type", and its copyright statement should reflect contributors to this Definition, not to the Template.
It is also important to note that the existing copyright wording suggests that there is a human-readable summary of that Specifications...Template, but the human-readable summary to which that phrase links is only of the CLA.
Further, the existing "Status of This Document" suggests that issues with the document's content should be raised on a nonexistent GitHub repo, https://github.com/w3c-ccg/ccg-template/, which might be appropriate if such issues were being raised on the content of the Template itself, but as the content of this Gdoc stands, it seems that such issues would be with the "Draft Community Report" which has not been previously worked on within the group as a whole, and which I might suggest would be better titled "Definition of Evidence Type for High Assurance Instances, an Extension of the W3C Verifiable Credentials Data Model", rather than the current, "Definition of Evidence Type for W3C Verifiable Credentials Data Model for High Assurance Individuals".
I could go on. I will refrain for the moment, in hopes that the comments above are sufficient for my readers to begin to understand the bases of my concerns, and perhaps move the existing Gdoc to a GitHub repo for further collaborative editing of the Definition of Evidence Type for High Assurance Instances and/or the Template for W3C Credentials Community Group Specifications. I have further hope that the content of the draft-in-progress will be revised in similar fashion.
The issue was discussed in a meeting on 2023-04-04
- no resolutions were taken
View the transcript
1.16. add claims metadata (how the identity claims were assured and how they are maintained) (issue vc-data-model#893)
See github issue vc-data-model#893.
Kristina Yasuda: About claims metadata. I think it can probably be closed..
… Any objections to closing this one?.
Either this issue (#893) should be kept open, or a new issue should be raised (on whatever the appropriate repo is), until my concerns as described in https://github.com/w3c/vc-data-model/issues/893#issuecomment-1418987041 are addressed/resolved.
Either this issue (#893) should be kept open, or a new issue should be raised (on whatever the appropriate repo is), until my concerns as described in #893 (comment) are addressed/resolved.
@TallTed Unless I misunderstand, your linked comment is entirely regarding a document that is neither a work item of the VCWG, nor a dependency for a VCWG work item, nor exists in a GitHub repository or similar place where an issue could be raised to address your concerns. I am unsure what action we can take that would be satisfactory to you so that this issue can be closed.
@brentzundel —
I think that a good step would be for @Sakurann to update https://github.com/w3c/vc-data-model/issues/893#issuecomment-1396073160 to make plain that the "Definition of Evidence Type for W3C Verifiable Credentials Data Model for High Assurance Individuals" Gdoc linked therefrom has zero standing in the VCWG or the CCG. (I think it's important to include both VCWG and CCG because much work has been incubated and/or maintained in the latter before and/or after being taken up by the former.)
Another good step would be for the individual(s) who were involved in the creation of that Gdoc and also involved in the CCG and/or VCWG (which I think amounts to @David-Chadwick) to update it to address the concerns I described in https://github.com/w3c/vc-data-model/issues/893#issuecomment-1398575256 and https://github.com/w3c/vc-data-model/issues/893#issuecomment-1418987041.
I think that a good step would be for @Sakurann to update #893 (comment) to make plain that the "Definition of Evidence Type for W3C Verifiable Credentials Data Model for High Assurance Individuals" Gdoc linked therefrom has zero standing in the VCWG or the CCG. (I think it's important to include both VCWG and CCG because much work has been incubated and/or maintained in the latter before and/or after being taken up by the former.)
I agree with this step, @Sakurann please let us know when your comment has been updated to indicate that the linked document has zero standing in our working group.
Another good step would be for the individual(s) who were involved in the creation of that Gdoc and also involved in the CCG and/or VCWG (which I think amounts to @David-Chadwick) to update it to address the concerns I described in #893 (comment) and #893 (comment).
I agree that this would be a good step, but I do not believe that such action should in any way hold up our WG, especially after @Sakurann edits her comment as requested.
The CCG provided a template for new work item suggestions, and this was used to produce the GDOC referred to above. The original intention was for this GDOC to become a CCG work item, and it was introduced in one of their minuted meetings to this effect. In parallel to presentation to the CCG, this document was also introduced to the VC WG to make them aware of the development, and there appeared to be some support in the VC WG to adopt this example of the Evidence property instead of the CCG. Thus it was not pursued for the CCG to adopt it. The VC WG then introduced its Directory of extensions, and my understanding was that the VC WG had said that the Directory was the best place to publish this example of the Evidence property. So an entry in the Directory was created for it. Since the GDOC is a live document that can be amended and updated at any time, the level of indirection introduced by the Directory pointing to the GDOC means that the Directory entry does not need to be changed in order to for the GDOC to be amended and improved as implementation experience advances. Note I have just updated the GDOC to fix the copyright issue that @TallTed referred to. Concerning the W3C logo, this was provided by the CCG in its new work item template. Perhaps it would be best to return to the CCG to ask it to adopt this new work item?
A link dropped without additional comment by an ordinary VCWG member has different implied meaning than a comment dropped without additional comment by a VCWG chair. The existing added comment is better than nothing, but "as a concrete mechanism that will help move this issue forward" belies its lack of "any standing in VC WG".
I think it has been made clear that the document mentioned has no standing in the VCWG, additionally, the document has been cleaned up. Closing this issue.
@TallTed Thank you for the feedback. I will be more careful when linking to the external resources.