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.
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. * 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. > It's true that I've frequently re-used the Issuer-Holder-Verifer terminology and it was more of a familiar bootstrapping than a foundational assumption for this work. This is definitely something that I will be proposing to tackle early on in a WG setting, adopting better terms that won't lead to confusion with other existing work. 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. * 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. > 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. 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. * 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. I do believe that the really-hard-problems we're aiming to tackle are probably not the ones you're thinking, those specifically being in my mind: how do we normalize common interfaces to the diverse capabilities afforded by the many families of ZKP algorithms. JWP is really about introducing the absolute minimum amount of container structure that supports the widest set of knowledge-protection algorithms. 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. 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. Ideally we'll find that common path of layering sometime in the not-to-distant future. Jer 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.
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
