This might be a partial answer to some of the questions asked. We prototyped using JWP as a direct substitute for BBS+ Data Integrity Proofs.
https://github.com/w3c-ccg/Merkle-Disclosure-2021 Converting an object to a set of messages that can be disclosed: https://w3c-ccg.github.io/Merkle-Disclosure-2021/#json-pointer Proving membership: https://w3c-ccg.github.io/Merkle-Disclosure-2021/jwp/ https://github.com/w3c-ccg/Merkle-Disclosure-2021/blob/main/packages/json-web-proof/ref-impl/jwp.test.js This code is very old, based on some of the first drafts we could review. The general idea was to create a broad category of selective disclosure schemes (not unlinkability schemes), that could apply to JSON. And then map those schemes to JSON-LD Verifiable Credentials, similar to how VC-JWT is a mapping of JSON-LD to JWT. Ideally if you need selective disclosure (and not unlinkability) you could use JWP with: 1. BBS 2. Merkle Proofs 3. SD-JWT 4. ...some future JWP algorithms (maybe snarks, starks, spartan, etc...) and all of them could support the VC Data Model. Only BBS might support unlinkability in addition to selective disclosure, based on my current understanding of the drafts I have seen. Regards, OS On Thu, Oct 20, 2022 at 9:13 AM Manu Sporny <[email protected]> wrote: > On Sat, Oct 15, 2022 at 4:42 PM Jeremie Miller <[email protected]> > wrote: > > Hi Manu! Appreciate your voice being added to this IETF work, I think > there's a lot of value in wider collaboration between the IETF and W3C work > in this space and I hope you'll find my answers below commensurate with > that. > > I've never known you to not be genuinely collaborative, Jeremie. :) > > >> 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. > > > > I apologize if I've given that impression or even let such an impression > be made about why the JWP work is happening. I'll try to start changing > that here. > > You haven't given that impression, but others have suggested that JWP > is of critical importance to the W3C Verifiable Credential work > without providing concrete examples of exactly how that is going to > occur. It's being simultaneously claimed that canonicalization is > unnecessary but somehow nested data structures are going to be > supported in the flat structure proposed in JWP. At present, there > seems to be quite a bit of hand waving around the specifics. I'm not > looking for detail, just /any/ example of how JWPs are going to be > applied to VCs, given that VCs have been put forward as a use case. > > > The reason you're not finding examples resembling a VC is intentional > though, the JWP work isn't intended to be VC use-case specific, and that's > the central divergence from the Data Integrity work happening inside the > W3C VC WG. > > The Data Integrity work is not specific to VCs or Linked Data. This is > why it was renamed from Linked Data Signatures/Proofs to Data > Integrity. You can add a Data Integrity proof to a document by doing > something like JCS (for canonicalization) + any bog standard > hash-then-sign digital signature format. There's overlap there, but > it's clear that a subset of the community in this problem space wants > to do work in the JOSE group to create a JSON-based serialization of > an unlinkable digital proof. > > Given that there will be a BBS cryptosuite in Data Integrity, and that > cryptosuite will choose to use a binary representation (in CBOR or > whatever binary representation the BBS libraries output); it's > unlikely to use the JWP expression given that it would be just another > (more complex) way of representing the result of the signing library. > > So, I expect there to be yet-another format for securing VCs to be > launched called VC-JWP (there is a VC-JWT that's being worked on right > now, with another VC-SD-JWT potentially on the way). That will bring > the total count of JOSE-based mechanisms to 3 incompatible > serializations. That's certainly an interoperability and system > complexity concern for some. > > > Indeed! You've hit it spot on actually, JWP is *not* attempting to solve > for any nested JSON structures nor would I support ever veering in that > direction. > > While the JWP headers are indeed JSON and the payloads *may* be JSON, > those payloads are opaque to the underlying ZKP algorithms and all > container interfaces and structures. > > In scope with JWP is also a parallel COSE-based structure that wouldn't > inherently have any JSON at all. > > If you're not attempting to solve for nested JSON structures, then > some form of canonicalization will be necessary to meet the VC use > cases given that those data structures are nested. > > > There's a significant interest in having an agile ZKP-supporting > container format for IoT and device use cases that are very distant from > anything to do with VCs or nested JSON structures. > > We've worked with the W3C Web of Things group for years, who use > JSON-LD and are exploring the use of Verifiable Credentials and Data > Integrity, so it's a familiar space. Can you elaborate on the IoT use > cases? Are they written up somewhere? > > > JWP is really about introducing the absolute minimum amount of container > structure that supports the widest set of knowledge-protection algorithms. > > Yes, but many of these knowledge-protection algorithms already have > their own binary formats... so why not just re-use those as a binary > blob in the signature? Why the need to separate what is a compact > signature today out into a text-based base-encoded JSON data > structure? > > > If we had started this process a few years ago and been successful, I > hope that I would have been working closely with you within the Data > Integrity effort such that you'd only have had to create a LD-based > solution atop JWP and then had the benefit of being able to use any of the > BBS, CL, PS, Merkle, etc based algorithms without any additional effort. > > Even if JWP were to have existed, you'll note that the Data Integrity > work was undertaken when it became clear that JWTs were not going to > address all of the use cases envisaged for Verifiable Credentials. > Yes, there is a VC-JWT format under development, and yes, it does > address a limited subset of the use cases, but it's also quite > constrained based on architectural decisions made in JWTs (that the > Data Integrity approach doesn't suffer from). > > > Instead, because we're not far enough along today, you're already forced > to do all that work just for one of the algorithms, BBS. > > There was a proof of integration w/ BBS two years ago with the Data > Integrity work... the hard part wasn't what JWP is solving... it's in > the privacy characteristics of the signature mechanism and the > unlinkability guarantees that can be made. That is, the hard part is > both below and above what JWP is addressing, IMHO. At the low level, > it's the information model in the BBS signature scheme and what you > need to express in a signature. At the high level, it's how do you map > the application data model to the BBS information model in order to > generate a signature while keeping the data structures at the > application layer usable by most developers (that don't have advanced > cryptographic training). > > > Ideally we'll find that common path of layering sometime in the > not-to-distant future. > > Perhaps, and I hope so, but as I've outlined above, I remain dubious > that it'll align. I can't see the path yet. I see JWTs, SD-JWTs, and > JWP diverging in a way that confuses the JOSE ecosystem. That you're > creating new incompatible JOSE data formats are a system complexity, > developer cognitive load, and architectural layering concern. > > > P.S. While working on JWP this past year I've done some experimenting > with using n-quads as the JWP payloads and am pretty sure there's some > interesting possibilities along those lines. > > Perhaps, and that's the route that Data Integrity uses (because there > is value in canonicalization to a common underlying data format)... > but there are members of the W3C VCWG that have rejected anything that > smells like canonicalization, N-Quads, or RDF. Data Integrity doesn't > require RDF, it can work on pure JSON or CBOR data structures, but > there seems to be a desire by a subset to use something JOSE-based... > thus, the SD-JWT and JWP work. > > In any case, I've said my piece. I wish ya'll the best of luck and > hope what you create is useful to the VCWG work. > > -- manu > > -- > 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 > -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
