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

[iherman]

Document title, URLs, estimated publication date

• Data Integrity BBS Cryptosuites v1.0
  • Final URL: https://www.w3.org/TR/2024/CR-vc-di-bbs-20240328/
  • Proposed publication date: 28 March 2024
  • Editors' draft: https://w3c.github.io/vc-di-bbs/CR/2024-03-28/

Abstract

• https://w3c.github.io/vc-di-bbs/CR/2024-03-28/#abstract

Status

• https://w3c.github.io/vc-di-bbs/CR/2024-03-28/#sotd

Link to group's decision to request transition

• https://www.w3.org/2017/vc/WG/Meetings/Minutes/2024-03-13-vcwg#resolution1

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:

• 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
• 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
• BBS per Verifier Linkability. V. Kalos. 2023. URL: https://basileioskal.github.io/bbs-per-verifier-id/draft-vasilis-bbs-per-verifier-linkability.html

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:

• https://github.com/w3c/vc-di-bbs/issues?q=is:issue+

PRs processed:

• https://github.com/w3c/vc-di-bbs/pulls?q=is:pr+

Horizontal reviews:

• TAG: BBS Cryptosuite v2023 Securing Verifiable Credentials with Selective Disclosure using BBS Signatures w3ctag/design-reviews#922
• PING: BBS Cryptosuite v2023 2023-12-15 > 2024-01-15 w3cping/privacy-request#126
• Security: BBS Cryptosuite v2023 2023-12-15 > 2024-01-15 security-request#61
• a11y: BBS Cryptosuite v2023 2023-12-15 2024-01-15 a11y-request#69
• i18n: BBS Cryptosuite v2023 2023-12-15 > 2023-01-15 i18n-request#221

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

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

  • Presentations given to ACLU and CDT over the years via PING and other venues
  • ACLU, EFF, CDT, and EPIC paper speaking positively about VCs:
    https://www.eff.org/document/10-16-2023-aclu-eff-epic-comments-re-tsa-nprm-mdls

• European Telecommunications Standards Institute

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

Formal Objections

None.

Implementation

• Test vectors
  • https://github.com/w3c/vc-di-bbs/tree/main/TestVectors
• Test suite
  • https://github.com/w3c/vc-di-bbs-test-suite
• Existing Implementations (more may come)
  • https://github.com/Wind4Greg/BBS-VC-Library
  • https://github.com/digitalbazaar/bbs-2023-cryptosuite

Patent disclosures

None, see

• https://www.w3.org/groups/wg/vc/ipr/

---

cc: @msporny @Wind4Greg @brentzundel

[plehegar]

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

@aphillips , can you close w3c/i18n-activity#1807 and w3c/i18n-activity#1805 ? They seemed to have been addressed. And, for w3c/i18n-activity#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]

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]

"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]

This RFC link is out of date

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

Fixed in w3c/vc-di-bbs@c90e531

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 w3c/vc-di-bbs@d65b491

[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: w3c/vc-di-bbs@f9d3481

[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]:

• if a specification fails to reach a finalized IETF RFC on time, the associated optional features from the W3C BBS Cryptosuite will be dropped before proceeding to PR and then REC at W3C.
• if a specification succeeds in reaching a finalized IETF RFC on time, the associated optional features from the W3C BBS Cryptosuite will be kept, AS LONG AS there are two independent implementations of each feature, before proceeding to PR and then REC at W3C.

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

[aphillips]

@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]

(still waiting on PING, will check on Monday)

[plehegar]

Approved.