On Wed, Aug 23, 2023 at 5:25 PM Orie Steele <[email protected]> wrote: > > Hey Watson, > > There are 2 properties that credential subjects are looking for in new > credential formats: > > 1. Selective Disclosure > 2. Unlinkability
What's the definition of selective disclosure without unlinkability? I do see that e.g. a bowl of carrots might be the sort of thing where we don't care about the difference. But then we need to make clear that sort of widespread usage some are going to push for where it's human credentials is a bad idea. While SD might make sense without unlinkability, you end up giving away everything you ever said, plus some without it. > > Ideally we would get both of these for JWT and CWT, with new algorithms, and > both compact and flat encodings. > > Ideally, we would have more than 1 crypto system powering these, so for > example pairing friendly curves and lattices. > > BBS is still making it's way through cfrg, and lattice systems for this kind > of thing are not even at cfrg yet. > > I agree that sd-jwt takes a pragmatic approach that balances the needs of the > credential subject, with the capabilities of the issuer and verifier > ecosystem. RFC 8890 is relevant here. We're not supposed to balance the needs of credential subjects with the capabilities that will in large part be defined by choices we've made. We're supposed to put the needs of the credential subjects first, and after all they are the ones who can decide to walk away. Particularly on the web there's a very challenging privacy model that SD-JWT will not meet. > > This is similar to the challenge of "post quantum or quantum ready" systems > for signing and encryption. > > Will not making kyber-x25519 or dilithium-es384 make NIST or CFRG move faster? The reason to have kyber-x25519 has very little to do with certification. But that's irrelevant here. > > Will not making sd-jwt make BBS, CFRG and JWP move faster? > > There is always opportunity cost. > > Personally, I think it's fine to create sd-jwt while also working on things > that immediately improve on it. We've learnt the hard way that it is extremely difficult to get rid of stupid things. The original RC4 usenet announcement was followed up with a break in a month. We didn't get rid of it until a few years ago. Was it exploited? Yup. RIP wepcrack being more convenient than trying to type in those ugly passwords. > > If you are more interested in seeing JWP or it's future COSE cousin solve > this problem, that's also something I am interested in. It's not enough to have a secure way. It is enough to have the only way be secure. To be clear, I think this can be made to work if we sufficiently caveat the applications, but I don't think the current doc gets there, and I'm afraid publication will be taken as permission to do bad things. > > I hope that some of the interfaces and flows from sd-jwt can be reused for > JWP/CWP. > > One of the challenges for multi message proof systems is handling nesting / > hierarchy. > > In sd-jwt, this manifests as the recursive payload traversal algorithm. > > In the past we've used json pointer dictionaries and streaming json to solve > this, for other selective disclosure schemes ( using merkle proofs). > > I wonder if others have considered unlinkability, and selective disclosure in > the context of streaming serializations? I'm not sure I understand the issue here: care to say more? (Maybe offlist if its been rehashed ad nauseam) > > I like sd-jwt, and it was easy to implement, but it's not going to be the > last credential format. > > Regards, > > OS -- Astra mortemque praestare gradatim _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
