REC Update Request for Verifiable Credentials Data Model v1.1 #414
Comments
iherman
added
[DO NOT USE] Awaiting Director
|
+cc @kdenhartog |
|
Regarding w3c/vc-data-model#782, I see that @aphillips was asked about the change from RFC3339 to XML Schema v1.1 but I don't see a recorded reply. Has I18N reviewed and responded to this change? I notice that a section "Issuer Cooperation Impacts on Privacy" was added. Though non-normative, that text should have been flagged for Security and Privacy review IMHO. I recommend asking for review of that text. I appreciate the perspective on interoperability testing that opened w3c/vc-data-model#863 and look forward to the WG's progress on that in 2.0. The Implementation Report does not identify which tests were added or modified to demonstrate implementation experience pertinent to these changes. Please identify these tests; for example, what tests exist for implementations that might fail now given the differences in the definition of date-time? Small detail (bug in the template that @plehegar has just fixed): the transition request does not include a pointer to the group's decision to request the update. I presume there is such a pointer available. |
swickr
added
Awaiting Working Group
No response yet, IIRC.
Ok, we will discuss on our next VCWG call. I'm not certain the WG can do much about that section, or the design of VCs to address it because the section was added to state the obvious (at least to the VCWG, probably not to the casual reader)... that "If an issuer makes a statement about you that you wish to use, and if they use a specific technology to do so, by passing on that statement, you are beholden to the technology the issuer used. You can always say "no, I don't want to use this statement made by the issuer"." The statement applies to any technology that transmits statements from one party to another (SMS, email forwarding, Signal messages, etc.). That said, more review on sections such as this are good. I don't think it registered with the group as specifically needing a PING review. If PING comes back with something, do we say "We'll deal with that in the VC2WG" or do we say "Ok, we'll do an update in place as an Editorial change, once approved by the WG?"
Yes, the WG has a better plan to do interop testing in VC2WG that will tap into more complete testing of the data model than we were able to accomplish in the VC1WG. We are planning to include at least one concrete ZKP-based test suite (BBS+) if the work at IETF completes with enough time for us to take advantage of it. There are already implementations that exist in the wild that use features described in the ZKP section and we hope to get much more concrete about it in the VC2WG.
The TL;DR is that no changes were needed to the existing test suite for conformance reasons. The date-time differences were a no-op -- there are no changes to the test suite because we accidentally implemented [XMLSCHEMA11-2] date-times the first time around and didn't realize it. The issue with RFC3339, IIRC, was that it allowed a space between the date and time, which [XMLSCHEMA11-2] date-times do not. The regex, while it said RFC3339, was really an XMLSCHEMA11-2 date-time: https://github.com/w3c/vc-test-suite/blob/gh-pages/test/vc-data-model-1.0/util.js#L76 Thus, no change necessary to the test suite (other than maybe the text that says it's an RFC3339 date time)... all the existing implementations were conformant with [XMLSCHEMA11-2] date-times already. With regard to the ZKP changes, we relaxed the requirements, which meant that all previous implementations should still be conformant. The group did debate whether it was worth creating a new test suite for v1.1 and re-requesting implementations, but it seemed as if it was more trouble than it was worth (the only result being the name of the tests would change from RFC3339 to XMLSCHEMA11-2... and that would be the only substantial difference). There is a good argument to just change the test suite text from "RFC3339" to "XMLSCHEMA11-2", but that raised the question if we should have a v1.1 test suite that is identical in all the tests it runs (except for the text associated with the test name). Given that we're going to quickly roll into the VC2WG test suite in the coming months, and given that it will be more API driven than command line driven, the WG felt like copying the v1.0 test suite to a v1.1 test suite that was identical in everything except for the descriptions would not be a good use of the VC1WGs time.
That pointer is here: https://www.w3.org/2017/vc/WG/Meetings/Minutes/2022-02-16-vcwg#resolution1 |
|
Why is the "to be published" version not a static copy? Often I want to be able to refer to a doc version "as reviewed", that this doesn't make it easy. |
|
@samuelweiler tells me he has looked at section 7.18 and is OK with it. |
|
Transition approved. |
swickr
added
Awaiting Publication
|
Document has been published. |
iherman
removed
the
Awaiting Publication
Document title, URLs, estimated publication date
Abstract
Status
See https://w3c.github.io/vc-data-model/#sotd
Link to Last Call for Review of Proposed Amendments
Wide Review of Proposed Amendments
The mode under which the VCWG operated called for a 14-day review period for every proposed change, whether substantive or editorial. The Credentials Community Group was the primary recipient of such review requests, but regular review was also sought from the Decentralized Identifiers Working Group. Additional review was saught from ISO SC17/WG10 and IMS Global.
Issues addressed
The set of substantive corrections made were tracked using the following issues, all of which were addressed:
Additionally, the following editorial changes were made in response to the last call for review from AC Members:
Link to internal AC Review results
Formal Objections
None.
Implementation
Patent disclosures
cc @brentzundel @msporny @Sakurann @wyc
The text was updated successfully, but these errors were encountered: