On Wed, Oct 12, 2022 at 10:26 AM Richard Barnes <[email protected]> wrote: > As I think I said at the last BoF, this work would be more compelling if it > could be focused solely on unlinkability, instead of both unlinkability and > selective disclosure.
Just some general observations regarding the SD-JWT and JWP work (since I can't make the call either): * Presuming that JWP succeeds, then SD-JWT is unnecessary (because JWP would presumably cover both selective disclosure and unlinkability). * There is a parallel effort happening in the W3C Verifiable Credentials Working Group on a container format called "Verifiable Credential Data Integrity"[1] that supports both selective disclosure and unlinkability (for BBS signatures, specifically, that has been incubated for years and is now in an active WG that will reuse the BBS signature work that is produced by the CFRG). It's clear that the proponents of the SD-JWT/JWP work do not want to use that format and thus are proposing an alternate format at IETF. * While the Issuer-Holder-Verifier model is used as the basis for the need for the SD-JWT / JWP work, examples using anything resembling a conformant Verifiable Credential do not exist in any of the specifications. I say this as the lead Editor of the W3C Verifiable Credentials specification. * Examples used in the JWP specifications do not provide any level of nesting and disclosure of different nesting levels. This is a key concern because the way JSON is nested can lead to linkability and correlation - no level of analysis, formal proof, or mitigation seems to be suggested in the specifications. This was one of the hardest things to get right in the VC BBS Data Integrity work (and it's still debatable that we've gotten it right). Having to solve this problem again (because the suggested format seems to be a "new thing") should not be underestimated. * If SD-JWT and JWP are successful, they will create three incompatible JSON-Web-*, parallel cryptographic envelope formats that need to be switched between, which will increase developer burden to a level that might be unacceptable to many. This points at a potential architectural flaw in JWTs that the JOSE group might want to look into. * There doesn't seem to be any broad incubation or deployment experience for the technologies being proposed, not that that is a requirement for IETF WGs. It doesn't seem as if much of the stack has been vetted and seems to indicate more wishful thinking that the group will solve these hard problems instead of ensuring the really hard problems have been solved before launching into a WG. Selective disclosure is a different level of cryptographic and privacy difficulty from unlinkability. To be clear, I'm not objecting to the work (nor am I supportive of it). It's clear that the Verifiable Credential Data Integrity work is not an acceptable path for the Editors of the SD-JWT and JWP specifications; that should be acknowledged somewhere in the proposed documents. Having viable options can be a good thing (which is the only reason I'm not objecting -- let's see if they can solve the hard problems that others before them have failed to solve; I remain skeptical that the work is ready). The market will decide, in time, which formats end up getting used. Just noting that 1) prior work exists that's not being cited, 2) the proposed solution seems incomplete, 3) there are ecosystem issues created if all of these formats become "successful", and 4) all this seems rushed. These are typically not good signals when creating a new WG, especially when it's attempting to create new types of cryptographic protections. Just my $0.02. -- manu [1]https://w3c.github.io/vc-data-integrity/#privacy-considerations -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. News: Digital Bazaar Announces New Case Studies (2021) https://www.digitalbazaar.com/ _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
