search

w3c / transitions

W3C Transitions
https://www.w3.org/Guide/transitions/
71 stars 26 forks source link

CR Request for Data Integrity BBS Cryptosuites v1.0 - vc-di-bbs #594

Closed iherman closed 3 months ago

iherman commented 4 months ago

Document title, URLs, estimated publication date

Abstract

Status

Link to group's decision to request transition

Changes

This is the first Candidate Recommendation for the first Recommendation attempt for this specification. It does not have a changelog other than the changes since FPWD, which can be found here:

https://github.com/w3c/vc-di-bbs/commits/main/?since=2023-05-18&until=2024-03-14

Requirements satisfied

Yes.

Dependencies met (or not)

The normative dependencies are on the VC Data Model and the VC Data Integrity specification, both are in CR as well as on the RCH specification for which a PR transition has been requested.

There are also dependencies on the IETF work on the BBS cryptography primitives listed in the Normative References section of the specification:

It is critical that the first normative reference reach an IETF RFC state before this specification can proceed to the Proposed Recommendation state. The following two references are desired and must also reach the IETF RFC state for the features that use those specifications, which are marked as at risk in this specification, to be preserved in the final W3C Recommendation.

RFCs for each specification are expected this year, or the following year, after they undergo thorough cryptographic review by the IETF CFRG.

Wide Review

Issues processed:

PRs processed:

Horizontal reviews:

Additionally, Simone Onofri is gathering reviewers to do a more thorough review of the BBS specification during the Candidate Recommendation phase.

Liaisons:

Formal Objections

None.

Implementation

Patent disclosures

None, see

cc: @msporny @Wind4Greg @brentzundel

plehegar commented 4 months ago

PING is doing more work following TAG review. @npdoty is checking.

@aphillips , can you close https://github.com/w3c/i18n-activity/issues/1807 and https://github.com/w3c/i18n-activity/issues/1805 ? They seemed to have been addressed. And, for https://github.com/w3c/i18n-activity/issues/1806 , did you mean that this needs to be fixed before CR or could it be fixed during CR (since it's in an example)..

plehegar commented 4 months ago

This RFC link is out of date [[ [CFRG-BBS-SIGNATURE] The BBS Signature Scheme. Tobias Looker; Vasilis Kalos; Andrew Whitehead; Mike Lodder. Draft. URL: https://www.ietf.org/archive/id/draft-irtf-cfrg-bbs-signatures-02.html ]]

[CFRG-Blind-BBS-Signature] Blind BBS Signatures. V. Kalos; G. Bernstein. 2024. URL: https://www.ietf.org/archive/id/draft-kalos-bbs-blind-signatures-00.html#name-proof-generation

How stable are those RFC documents meant to become ?

[CFRG-Pseudonym-BBS-Signature] BBS per Verifier Linkability. V. Kalos. 2023. URL: https://basileioskal.github.io/bbs-per-verifier-id/draft-vasilis-bbs-per-verifier-linkability.html

is not published by an organization. It seems inappropriate to have a normative reference to a document like that.

plehegar commented 4 months ago

"at least two independent implementations for each mandatory feature in the specification. "

There are optional features in this specification. What are the CR exit criteria for those?

msporny commented 4 months ago

This RFC link is out of date

We have updated the link to the latest (which is draft -05).

Fixed in https://github.com/w3c/vc-di-bbs/commit/c90e531b0a1f1e815d328227b09739509376e992

There are optional features in this specification. What are the CR exit criteria for those?

Same as for the non-optional features. All features (both non-optional and optional) have the same exit criteria: two independent, interoperable implementations for each feature. Would explicitly stating this in the SotD address your concern?

We have pushed a fix in https://github.com/w3c/vc-di-bbs/commit/d65b49170646b746a5fc319dbd460b059857928d

[CFRG-Pseudonym-BBS-Signature] is not published by an organization. It seems inappropriate to have a normative reference to a document like that.

This was an unfortunate miscommunication with the author of the document. It was supposed to have been published as an I-D at IETF by the time of your review. The I-D was published today and the link updated.

We have pushed a fix here: https://github.com/w3c/vc-di-bbs/commit/f9d3481eb3f9be7f5db3315b340987dcc2235684

[CFRG-Blind-BBS-Signature], [CFRG-Pseudonym-BBS-Signature] How stable are those RFC documents meant to become?

All three documents cited are meant to proceed to IETF RFC's with assigned numbers (get through Last Call, CFRG review, and AUTH48 approval by area directors/reviewers). The documents might be combined before the final RFC number is assigned.

[CFRG-BBS-SIGNATURE] is currently undergoing cryptographic review at IETF, and if it passes, is expected to become an published RFC (with a number). This will mean that all non-optional features in the W3C BBS Cryptosuite could proceed to PR and then REC at W3C.

For [CFRG-Blind-BBS-Signature] and/or [CFRG-Pseudonym-BBS-Signature]:

Does the above address all of your review concerns, @plehegar ?

aphillips commented 4 months ago

@plehegar w3c/i18n-activity#1806 is an example. I would like it if it were fixed pre-CR, but it is editorial. I would not delay publication of the CR on that, given that they have agreed to fix it when time permits during CR. I have closed our other two issues.

plehegar commented 4 months ago

(still waiting on PING, will check on Monday)

plehegar commented 3 months ago

Approved.