Hey Watson, There are 2 properties that credential subjects are looking for in new credential formats:
1. Selective Disclosure 2. Unlinkability 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. 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? 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. 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. 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 like sd-jwt, and it was easy to implement, but it's not going to be the last credential format. Regards, OS On Wed, Aug 23, 2023, 6:53 PM Watson Ladd <watsonbl...@gmail.com> wrote: > On Wed, Aug 23, 2023, 1:35 PM David Waite <da...@alkaline-solutions.com> > wrote: > > > > > > There are credentials where the user will always have an identifier, per > policy of the type of credential/credential issuer. Not all credentials are > anonymous credentials. > > But if the credentials aren't anonymous why make SD-JWT? > > To sharpen this: let's say we have a user sitting down and about to > verify their age to a website. It's easy to explain what the website > will learn, even in the face of collusion, when using BBS. It's also > easy to explain what they will learn if the credential isn't > anonymous. What happens with SD-JWT? It's much closer to the > non-anonymous case, with a persistent user identifier known to the > issuer and accessed by every website the credential is used at. Maybe > there are places where these limits are useful, but I don't see them > from the intro. > > > > > There are certainly privacy-centric protocols (such as privacypass) > which support single-use unlinkability, which is what SD-JWTs are > targetting. > > I don't think you even get that without a blind signing protocol: the > issuer can see what root it signed otherwise and use it to connect to > redemption. Privacypass has blind signing and sigle-use anyway, but > there's still some issues with selective disclosure. I did put forward > a similar idea of selective metadata opening based on opening > commitments, but the details really matter. We also ended up with a > very significant architectural constraint on the number of issuers > because it wasn't possible to hide the issuer (or at least it wasn't > solved) and who issued was an anonymity leak. > > > > > Since you used U-Prove as an example - it also only provides > unlinkability on single-use. Lysyanskaya (separately from [CL01]) describes > a linkable anonymous credentials scheme in [BL13]. > > > > There are issuers who simply are not going to trust their reputation > against risk of forgery (or other attacks) from using less-proven > cryptographic algorithms. The issuers may also be operating under explicit > guidance on what cryptography they are allowed to use (e.g. from NIST). > Issuing a ’stack’ of credentials for single use unlinkability is worth > reducing risks and meeting imposed requirements.. > > What exactly does "less proven" mean here? if anything far more people > look at very neat schemes than boring ones, given the incentives of > publication. Furthermore the TPM implemented and deployed schemes like > EAA based on pairings decades ago. If issuers aren't going to > participate in a BBS ecosystem, but would in a SD-JWT one, and end up > not if we don't standardize SD-JWT, that's fine by me. > > I don't understand what risks are being reduced, and if we're saying > that you should issue a stack we need to analyze that system as a > whole and its security properties, not just one bit in isolation. > Again you need blind signing to prevent linkability at the root, so > that's a rather tricky thing for stuff that isn't just RSA and > requires changes to implementations (and isn't necessarily in line > with NIST). Then you have an availability risk where it's not just one > interaction that's required for usage, and the reissuance process > (because you are not going to drag everyone back to the get their > stuff verified when they run out) creates an entirely different > operation risk as that's another way to get a credential. > > The privacy impact of these stacks also assumes that the Issuer isn't > behaving maliciously, or learns things from the consumption rate. > That's not a great assumption. > > > > > > The need for more confidence on anonymous credential algorithms is also > a strong motivator around the BBS efforts. > > I'm not sure what the relevance of this to the downsides of SD-JWT is. > If anything this suggests pushing the BSS ones through. > > > > > > > As for availability it really > > doesn't take many implementations to have enough for almost all > > purposes, and those who aren't served can make their own. > > > > > > I would discourage nearly everyone from writing their own cryptography > implementations - it is a very distinct skill set and mistakes tend toward > the highest levels of severity. > > Who exactly has an environment where any of the already existing > pairing implementations, or a forthcoming BBS signature scheme > wouldn't be available? The GSMA seems to indicate that this isn't a > problem even on sim cards. > > > -DW > > Sincerely, > Watson Ladd > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
