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]> wrote: > On 30 Jul 2022, at 18:26, Jeremie Miller <[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] > https://www.ietf.org/mailman/listinfo/jose >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
