Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
iherman opened this issue Oct 13, 2023 · 16 comments
Closed

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

iherman opened this issue Oct 13, 2023 · 16 comments
Assignees
@iherman
Labels
Entering CR First Candidate Recommendation wg:vc

Comments

@iherman
Copy link
Member

iherman commented Oct 13, 2023

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
@iherman iherman added Entering CR First Candidate Recommendation Awaiting Team Verification Awaiting the verification of the W3C Team labels Oct 13, 2023
@plehegar
Copy link
Member

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
Copy link
Member Author

iherman commented Oct 13, 2023 •
edited
Loading

(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
Copy link
Contributor

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
Copy link
Member

msporny commented Oct 13, 2023

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
Copy link
Contributor

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
Copy link
Contributor

(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)

@msporny
Copy link
Member

msporny commented Oct 13, 2023 •
edited
Loading

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
Copy link

@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

@decentralgabe decentralgabe mentioned this issue Oct 14, 2023
Merged
@plehegar plehegar added Awaiting Working Group This includes editors and team contacts and removed Awaiting Team Verification Awaiting the verification of the W3C Team labels Oct 16, 2023
@plehegar plehegar assigned iherman and unassigned plehegar Oct 16, 2023
@plehegar
Copy link
Member

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

@msporny
Copy link
Member

msporny commented Oct 16, 2023 •
edited
Loading

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
Copy link
Member Author

iherman commented Oct 30, 2023

@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 plehegar added Awaiting Team Verification Awaiting the verification of the W3C Team and removed Awaiting Working Group This includes editors and team contacts labels Nov 6, 2023
@plehegar plehegar assigned plehegar and unassigned iherman Nov 6, 2023
@plehegar
Copy link
Member

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

Additional notes:

  • Define "valid" cid#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
Copy link
Member

msporny commented Nov 10, 2023 •
edited
Loading

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?

@plehegar
Copy link
Member

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

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

@plehegar plehegar added Awaiting Publication Approved by the Director, waiting on publication and removed Awaiting Team Verification Awaiting the verification of the W3C Team labels Nov 16, 2023
@plehegar plehegar assigned iherman and unassigned plehegar Nov 16, 2023
@iherman
Copy link
Member Author

iherman commented Nov 16, 2023

Official publication request sent: https://lists.w3.org/Archives/Team/webreq/2023Nov/0000.html

@iherman
Copy link
Member Author

iherman commented Nov 21, 2023

CR Published, and announced: https://www.w3.org/news/2023/w3c-invites-implementations-of-vc-data-integrity-data-integrity-eddsa-and-ecdsa-cryptosuites-and-vc-json-schema/

@iherman iherman removed the Awaiting Publication Approved by the Director, waiting on publication label Nov 21, 2023
@iherman iherman closed this as completed Nov 21, 2023
@iherman iherman mentioned this issue Aug 27, 2024
Closed
@ericprud ericprud mentioned this issue Aug 29, 2024
Closed
@plehegar plehegar added the wg:vc label Aug 29, 2024
@iherman iherman mentioned this issue Oct 21, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@iherman iherman

Labels
Entering CR First Candidate Recommendation wg:vc
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@aphillips @msporny @iherman @plehegar @decentralgabe