"Who exactly has an environment where any of the already existing pairing implementations, or a forthcoming BBS signature scheme wouldn't be available?"
I have customers who are required to send regulatory trade data that may have redactions with FIPS compliant cryptography. They are ok with linkability, but still need selective disclosure capabilities. A good example would be an agricultural inspection, where the result (pass/fail) might be disclosed to some parties, but not to others. The FIPS and other requirements means we are looking at ES384 and similar as our preferred approaches for signatures and would still like to selectively disclose data. Mike Prorock CTO - mesur.io On Wed, Aug 23, 2023, 17:53 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
