For me, JWP is about a container format that can work with different cryptographic schemes for enabling selective disclosure.
If we want a plurality of selective disclosure schemes and still have interoperability (or at least pluggability), we need JWPs to provide us with a common container format. The alternative is proprietary formats that will probably be more prone to exploits, harder to implement and make selective disclosure harder to scale across wallets, authorisation servers and resource servers. Cheers Pieter From: jose <[email protected]> On Behalf Of Vasileios Kalos Sent: Thursday, August 4, 2022 10:38 PM To: Mike Jones <[email protected]>; Neil Madden <[email protected]>; Orie Steele <[email protected]>; Zundel, Brent <[email protected]> Cc: Jeremie Miller <[email protected]>; Vasileios Kalos <[email protected]>; [email protected] Subject: Re: [jose] An attempt at unlinkable tokens with minimal magic Some people who received this message don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> As a further note, I think we also underestimate a little the difficulty of defining a container format that supports selective disclosure and unlinkability. There are many nuances in the design, and without a formal analysis it is easy to unintentionally compromise security and privacy [1, 2]. Applications that tried it have been found to introduce vulnerabilities [3]. What is the best wording to avoid ambiguities and what guarantees it is safe to make in the document is an excellent discussion to have but IMO is not reason enough to dismiss the item. [1] https://ieeexplore.ieee.org/abstract/document/9799315<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fieeexplore.ieee.org%2Fabstract%2Fdocument%2F9799315&data=05%7C01%7Cpieter.kasselman%40microsoft.com%7Cbedc193dc46b45b7ea8b08da7661a6c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637952459838625546%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=KKtdGTACH7%2FeaociDz%2FanU7GrhNv1pBqvu9orSkRlq0%3D&reserved=0> [2] https://mm.aueb.gr/publications/fd17e44e-9b7a-477d-b948-81a71db53b06.pdf<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.aueb.gr%2Fpublications%2Ffd17e44e-9b7a-477d-b948-81a71db53b06.pdf&data=05%7C01%7Cpieter.kasselman%40microsoft.com%7Cbedc193dc46b45b7ea8b08da7661a6c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637952459838625546%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rBzC7iCntWwmIFOE0yvEIv%2Bxt%2FdMcV99gdQPZ3Aqe%2FA%3D&reserved=0> [3] https://github.com/w3c-ccg/ldp-bbs2020/issues/60<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c-ccg%2Fldp-bbs2020%2Fissues%2F60&data=05%7C01%7Cpieter.kasselman%40microsoft.com%7Cbedc193dc46b45b7ea8b08da7661a6c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637952459838625546%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=s5UPr3jhAEmxltuvUNmXgnLqU%2FEElxap1GGi%2B04Nlrg%3D&reserved=0> Best regards! Vasilis ________________________________ From: jose <[email protected]<mailto:[email protected]>> on behalf of Mike Jones <[email protected]<mailto:[email protected]>> Sent: Tuesday, August 2, 2022 11:04 PM To: Neil Madden <[email protected]<mailto:[email protected]>>; Orie Steele <[email protected]<mailto:[email protected]>>; Zundel, Brent <[email protected]<mailto:[email protected]>> Cc: Jeremie Miller <[email protected]<mailto:[email protected]>>; Vasileios Kalos <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: Re: [jose] An attempt at unlinkable tokens with minimal magic EXTERNAL EMAIL: This email originated outside of our organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe. Neil, you wrote: "I think perhaps we most fundamentally disagree on this roadmap. Although many standardised systems have followed this kind of modular design, I don't think it is the best approach. Compare say IPSec vs WireGuard for an often-cited example. Privacy is not a separable concern. Start with the privacy-aware applications. Otherwise I think we'll end up with lots of "privacy-related" tools with lots of sharp edges that inevitably get used inappropriately." Modular design based on standards is the most practical approach to enabling applications to use these new algorithms easily, safely, and correctly. Yes, as with any standards, implementation mistakes will be made. But as happened with the other JOSE standards, those mistakes were caught, implementations were fixed, and the JWT BCP<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8725.html&data=05%7C01%7Cpieter.kasselman%40microsoft.com%7Cbedc193dc46b45b7ea8b08da7661a6c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637952459838625546%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HMziLE0uWEeFxMGrw0uV1QcAyndjr5gO3W2vXiR%2FA8U%3D&reserved=0> was written to help implementers avoid them in the future. By making JWP a standard, the same virtuous cycle of review and refinement will occur for it. The alternative is having applications write bespoke cryptographic code to use these algorithms. That's certainly a security anti-pattern. Yes, the WireShark code is likely well reviewed by virtue of being in the Linux Kernel, but that's not typical. We owe those needing this functionality simple, well-reviewed standards they can build upon. -- Mike P.S. To my first point, see Kristina Yasuda's reprise<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fkristinayasuda%2Fstatus%2F1554474399226552320&data=05%7C01%7Cpieter.kasselman%40microsoft.com%7Cbedc193dc46b45b7ea8b08da7661a6c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637952459838625546%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=62bMKS3qmZx%2BLt08%2FEWu1XKx5kbg3nFxh0Q7luTnPLg%3D&reserved=0> of John Bradley's points "Open standards can create a healthy ecosystem in which security issues are addressed effectively" and "implementation is everything". From: jose <[email protected]<mailto:[email protected]>> On Behalf Of Zundel, Brent Sent: Tuesday, August 2, 2022 12:19 PM To: Orie Steele <[email protected]<mailto:[email protected]>> Cc: Neil Madden <[email protected]<mailto:[email protected]>>; Jeremie Miller <[email protected]<mailto:[email protected]>>; Vasileios Kalos <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [jose] An attempt at unlinkable tokens with minimal magic You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> > If we are going to do modern cryptography, we will either have a standard > json representation or we won't. This hits a main point for me. We want to use modern cryptographic schemes, and would prefer to have a standard JSON representation. None of the existing JOSE formats work, it looks like JWP would work great, while also making use of the general architecture shared by other JOSE formats. On Tue, Aug 2, 2022 at 7:00 AM Orie Steele <[email protected]<mailto:[email protected]>> wrote: Good security is about building the right layers. Many of these arguments might be better focused in the CFRG. I wonder if the argument in this thread might be some version of denying the problem... If we are going to do modern cryptography, we will either have a standard json representation or we won't. If the assertion is, let's not use that cryptography... That's not exactly an argument against the envelope format. I am in favor or resurrecting JOSE and defining JWP. Regards, OS On Tue, Aug 2, 2022, 4:51 AM Neil Madden <[email protected]<mailto:[email protected]>> wrote: On 30 Jul 2022, at 18:26, Jeremie Miller <[email protected]<mailto:[email protected]>> wrote: Isn't this somewhat overstating the likely privacy benefits? If the prover reveals _any_ PII to the verifier then the verifier can collaborate with the issuer to discover everything about that user. JWP as a container aims to make unlinkability _possible_ for applications to build, not a guarantee. There are many extremes an application may choose to design for to accomplish different scales of unlinkability (from multiple verifiers colluding, from the verifier and issuer colluding, from multiple presentations to the same verifier, etc). In my mind it's akin to you can cryptographically validate the contents and signature in a JWS, but how you decide if you trust the signer is up to the application or higher level protocols. And we know from many studies on deanonymisation that it is very easy to accidentally reveal enough information to be identifiable. ZK proofs are nice and everything but they only ensure zero *additional* knowledge is gained by the verifier. In practice what is explicitly revealed is often enough. That's exactly why we believe this work is very important, having a container to support algorithms where zero *additional* knowledge is revealed by the container and crypto layers. It *is* very easy to incidentally reveal linkable factors, which is why JWP is hard to get right, and critical to do so to enable this capability. IMO if you want to have any hope of actually achieving the privacy you want then you really need to design the entire protocol, including specifying exactly what information is to be revealed. I think designing a generic "privacy preserving" message container is likely to give people unrealistic expectations. We have the lowest level privacy algorithms becoming well established like BBS (and CL signatures, etc), next we need a privacy-capable container to make those algorithms more accessible and interoperable, then we need privacy protocols to leverage those containers, then privacy aware applications, ecosystems, and user experiences. I think perhaps we most fundamentally disagree on this roadmap. Although many standardised systems have followed this kind of modular design, I don't think it is the best approach. Compare say IPSec vs WireGuard for an often-cited example. Privacy is not a separable concern. Start with the privacy-aware applications. Otherwise I think we'll end up with lots of "privacy-related" tools with lots of sharp edges that inevitably get used inappropriately. - Neil _______________________________________________ jose mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/jose<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fjose&data=05%7C01%7Cpieter.kasselman%40microsoft.com%7Cbedc193dc46b45b7ea8b08da7661a6c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637952459838625546%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=T2ZFLiy7haZ%2BoyjsA0iHuMzkMspIIptmXCe4p1jDWOU%3D&reserved=0> _______________________________________________ jose mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/jose<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fjose&data=05%7C01%7Cpieter.kasselman%40microsoft.com%7Cbedc193dc46b45b7ea8b08da7661a6c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637952459838625546%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=T2ZFLiy7haZ%2BoyjsA0iHuMzkMspIIptmXCe4p1jDWOU%3D&reserved=0> -- Brent Zundel Principle Crypto Engineer - Avast
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
