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
