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
