w3c/transitions

CR Request for VC Data Integrity, EdDSA and ECDSA Cryptosuites, and JSON Schema Specification

Closed this issue · 16 comments

iherman commented

Document title, URLs, estimated publication date

Abstract

Status

Link to group's decision to request transition

New publication date plus reaffirming the publication after some post TPAC changes:

Changes

Requirements satisfied

Yes.

Dependencies met (or not)

For the "Verifiable Credentials JSON Schema document": there is a dependency on JSON-Schema. This is related
to the discussion on W3C's Strategy team, see:

The WG's judgement is that a normative dependency is appropriate in this case.

All documents have a dependency on the following WG specification:

this document is planned to go to CR by the end of 2023 or very early 2024.

Wide Review

Issues processed:

PRs processed:

Horizontal reviews:

Issues addressed

Formal Objections

None.

Implementation

7 independent implementations for the existing test suites:

Patent disclosures

None, see

cc: @msporny @seabass-labrax, @dmitrizagidulin @Wind4Greg @decentralgabe
cc: @brentzundel @Sakurann

plehegar commented

There are open issues, in particular around data integrity:

Please, remind your group participants to NOT put *-needs-resolution label on issues. Those labels are meant to be used solely by the horizontal groups. Your participants should use *-tracker instead. I'll need to do some clean-up to figure which issue is actually blocking.

It's not clear if the loop with the TAG was closed. @ylafon is checking on it.

iherman commented

(The Issue template does not make it clear that comment is needed on the state of various liaisons. But I just saw #571 (comment)...)

Adding information on liaisons:

  • There are participants' overlap with the following groups:

    • RDF Canonicalization and Hashing Working Group
    • Decentralized Identifier Working Group
    • Credentials Community Group
    • Internet Engineering Task Force
    • Internet Engineering Task Force Crypto Forum Research Group
    • Hyperledger Aries
    • Decentralized Identity Foundation Interoperability Working Group
    • IMS Global
    • ISO/IEC JTC 1/SC 17/WG 10
    • ISO/IEC JTC 1/SC 17/WG 4

  • Web of Things Working Group

    • Joint meeting at W3C TPAC 2023

  • APA Working Group

    • See horizontal reviews

  • National Institute of Standards and Technology, U.S. Department of Commerce

    • DHS actively engaged w/ NIST over VCWG + Justin Richer NIST SP 800-63-C work

  • The American Civil Liberties Union

  • European Telecommunications Standards Institute

    • EU Digital Wallet cites/uses VCWG output + ARF + EBSI
aphillips commented

VC did not request review of either vc-data-integrity or vc-json-schema from I18N. The former has a self-review that was labeled with i18n-tracker. The latter has a self-review which as no i18n label. No request was submitted (that I can find) in the w3c/i18n-request repo. Therefore you cannot say that there was a "request timeout": there was no review done. Please request one before proceeding with CR transition. See here: https://www.w3.org/Guide/documentreview/#how_to_get_horizontal_review

(Note: you did later request review of other VC docs. If the process is unclear, please help us make it clearer.)

msporny commented

Therefore you cannot say that there was a "request timeout": there was no review done.

sigh, dammit.

This issue states: "Internationalization Review for VC Data Integrity (and vc-di-eddsa and vc-di-ecdsa)" and it's in the i18n-activity tracker, which I thought was the tracker for i18n reviews:

w3c/i18n-activity#1717

... @aphillips did a review for VCDM v2.0, which I thought also covered the data integrity specs, which I guess it did not.

If the process is unclear, please help us make it clearer.

Yes, the new process makes it difficult to understand when you're requesting a review... and if all of the horizontal review groups follow the same process (they don't -- e.g. TAG requests different things, PING/Security requests different things, etc.). When processing a lot of documents through the system, as VCWG is doing, and given the new process (I've been doing this for years, but clearly got tripped up with the new changes), it becomes difficult to understand when the review was actually triggered. I thought w3c/i18n-activity#1717 would have done it, but clearly it didn't.

I've raised an i18n-request issue here:

w3c/i18n-request#219

In any case, we've set a CR-entry date of November 7th. At this point, all we can do is throw ourselves at i18n WG's feet in mercy and ask if there is any possibility that an i18n review could be done before then given that these are cryptography enveloping formats and thus have very little to no i18n considerations?

aphillips commented

I'll do my best to get these through our process to meet your schedule. If, as you note, it's mostly crypto stuff then there's a good chance we won't find anything of note.

Data-Model v2 was requested by awoie using our process in June. vc-jose-cose was requested by awoie (and we will complete the review in our next call). FWIW, Data-Model v1 was reviewed in 2019, also from a proper request.

... @aphillips did a review for VCDM v2.0, which I thought also covered the data integrity specs, which I guess it did not.

We have limited resources and have to review every specification, so only docs actually in a request are covered by the request. It's okay to include multiple specs in a request, by the way.

We love self-reviews (which is what 1717 was) and we love early engagement. I know VC has put a lot of effort into getting the I18N right, which is why I was fairly sure this was a gap in conveying the process.

Yes, the new process makes it difficult to understand when you're requesting a review... and if all of the horizontal review groups follow the same process

Actually, except for TAG, all of the horizontals have copied I18N's process, which requires "request a review via github". What differs are any preliminary steps (which makes it look more diverse). In case you didn't already, you might want to check A11Y and security (showing timeout above) to ensure that you filed requests with them too (sorry).

aphillips commented

(I have just now done a quick-and-dirty review. I have created one minor issue for consideration by the WG and will schedule this in our 2023-10-19 call along with JOSE-COSE issues)

  • ❤️1
msporny commented

I have just now done a quick-and-dirty review.

Thank you, you are a saint. 👼

I see w3c/i18n-activity#1771 and am tracking it in as a pre-CR issue here w3c/vc-data-integrity#211

I will add text to address your concern, ideally by the end of the upcoming weekend.

decentralgabe commented

@aphillips I apologize for not following the process correctly and forcing you into this last minute position. I've just opened a review here w3c/i18n-request#220

plehegar commented

As a reminder, how to do wide review, including horizontal reviews, is documented in the guidebook.

msporny commented

As a reminder, how to do wide review, including horizontal reviews, is documented in the guidebook.

Yes, it is, and I read it and still got it wrong. :) -- it's completely my fault, but I think the problem is human fallibility (I'm not exactly new to this process... maybe that's the problem (old habits)... or maybe we need something that requires less cognitive load on the Editors).

To be clear, the documentation is correct, if you read it carefully... which I was trying to do, but failed. It is only after going through the new process that it's now clear that the "raise an issue via the horizontal review groups *-request tracker" is the standard process for all HR groups.

I did raise the correct *-request issues on many of the other specs, but missed i18n for some reason (probably because I thought that the way you request review was subtly different for each group -- which it is, but that mostly has to do w/ the pre-review material.

Here are some things that make it seem like the process is different for each group (when it isn't):

  • You have to write an Explainer for the TAG and then request review, no link to "request review" in that list (above), like other entries in the list... the TAG not having a questionnaire and not having a link makes the process feel different.
  • You have to fill out a joint Security/Privacy questionnaire, but then request review for the joint document separately (separate review requests for PING and Security).

In addition, the entire process is manual, introducing human error... case in point: me (and Gabe), as evidenced above :).

I read the document multiple times, but just now saw that there is a way to generate a checklist (at the very bottom, in a collapsed section):

https://www.w3.org/Guide/documentreview/#how_to_get_horizontal_review

The checklist would probably have been helpful w/o having to track everything in one's head. In any case, I now know that the input documents to the horizontal review process are different for each group (sometimes separate (i18n, APA), sometimes combined (Security/Privacy), sometimes an Explainer (TAG, i18n), different questions in the *-request issue that is raised), but the request process is the same.

My only suggestion for changes is to make the list of steps to perform more uniform:

https://www.w3.org/Guide/documentreview/

For example:

I'll also note that "Have you reached out to all of your liaisons?" isn't a part of the list, but seems like it could be used as a reason to not transition (based on a judgement call).

Feels like we need a "pubrules checker" for horizontal review... :) or, maybe the list just needs to be more uniformly formatted? This is one of those things that if you get it wrong, you don't find out until it's too late... potentially adding months of delay to a transition.

iherman commented

@plehegar, @ylafon

The files have been updated. More precisely:

There may be some more editorial changes (due to i18n) that can happen on the document between now and the final steps. Obviously, if there is any normative change planned, I will ping you.

Can you take back the baton for the CR approval? Thanks.

plehegar commented

we're still going through this transition to sort everything out.

Additional notes:

  • w3c/controller-document#35 will need to be addressed before moving to PR and will likely require a CR snapshot due to its substantive changes
  • the use of https://w3id.org/security# , managed by a CG, in a W3C REC also raises questions. the document in GH will need to move into w3.org/ns. what's the guarantee of stability of the redirect from w3id.org ?
msporny commented

Noted. The plan there is to reference the conforming controller document and conforming verification method language, which contain normative statements wrt. what a "valid" form of those documents should look like.

  • the use of https://w3id.org/security# , managed by a CG, in a W3C REC also raises questions. the document in GH will need to move into w3.org/ns. what's the guarantee of stability of the redirect from w3id.org ?

Agreed that the document in GH will need to move to w3.org/ns (this was always the plan).

Some background (to speak to the stability of w3id.org):

To speak to the stability of the security vocabulary redirect:

  • I am one of the maintainers of that redirect.
  • Every maintainer of the redirect for the security/ namespace are VCWG members (and have been for a long time). That is, it is highly unlikely that they would act in a way that goes against the VCWG's (and W3C's direction).

To speak to why the redirect doesn't matter for the VC Data Integrity specification:

The VC Data Integrity specification contains normative text that instructs processors to treat all w3id.org URLs as "already resolved", where the content matches a cryptographic hash value that's included in the specification:

Excerpt from https://w3c.github.io/vc-data-integrity/#contexts-and-vocabularies

Implementations that perform JSON-LD processing MUST treat the following JSON-LD context URLs as already resolved, where the resolved document matches the corresponding hash values below:

This means that implementations normatively ignore any dynamic changes to any w3id.org redirect referenced normatively in the specification and end up using whatever is published at w3.org/ns. In other words, the contents of these files are hard coded in implementations and no network access occurs.

In the very worst case of w3id.org going down, or being taken over by a hostile force, no harm is done to implementations because they MUST NOT process the re-direct during runtime (and they have a cryptographic hash of what all of the w3id.org URLs used in the specification must contain).

Does that achieve the stability that you were expecting @plehegar?

  • ❤️1
plehegar commented

Thank you @msporny for the clarification. This was helpful.

This transition is now approved. Apologizes for taking so long.

  • 🎉1