Hi all, resurfacing this approach as it may provide issuer-verifier unlinkability for SD-JWTs and formats like it depending on your threat model.
https://csrc.nist.gov/Presentations/2024/wpec2024-3b4 Best, Wayne Chang Founder & CEO | SpruceID <https://spruceid.com/> | LinkedIn <https://www.linkedin.com/in/waynebuilds/> On Mon, Dec 23, 2024 at 09:07 Joseph Heenan <jos...@authlete.com> wrote: > > > On 23 Dec 2024, at 16:02, Denis <denis.i...@free.fr> wrote: > > Joseph wrote: > > I believe I've said that, including in your PR I linked above: there are > situations where SD-JWT is the best currently available deployable > technology > for a user disclosing their age to a verifier, and yes, it is absolutely > appropriate to use the best currently available deployable technology to > solve a real world problem. > Yes, in some situations it can’t achieve issuer-verifier unlinkability, > but in those situations it can still achieve better data minimisation than > alternative technologies. > Maybe in the future we will have better solutions available and at that > point it might be appropriate to start adding stronger text. > > A presentation where only a date of birth is disclosed is an example > explicitly mentioned in the specification too. > > I’m deliberately avoiding the term ‘age verification’ there as I think > you’re trying to use it to describe some fairly specific situation that > hasn’t been defined > - I’m not sure whether a stronger statement is possible about the specific > case of age verification you seem to be thinking of, as I’m not clear on > what that case is, > and as I said in my 1st August comment “age verification” is an overly > generic term that incorporates a large number of very disparate use cases. > > I think differently: > > SD-JWT *as currently described* is NOT "*the best currently available > deployable technology for a user disclosing their age to a verifier*". > > > That is not what I said - the ‘in some situations’ is a very important > qualifier. (And maybe I should have said ’format specification’ or > something rather than ’technology’.) > > Although I’m somewhat puzzled why you didn’t go on to name what is the > best technology, it seemed more like you were agreeing it is the best > technology and explaining how it can be extended using available extension > points to build a good solution for this use case. > > The major problem is that SD-JWT is only a piece of a puzzle that > includes other entities - that have not yet been identified. > In order to secure the two exchanges described in this draft, other > protocols and other entities would need to be considered. > > As an example, *in its basic form*, OpenID4VCI is insecure. > > A Framework would be needed to identify all the pieces of the puzzle and > to describe how they interrelate. > > To close the loop, SD-JWT **as currently described** SHOULD NOT be > considered to be secure enough > for disclosing one or more age threshold values to a Verifier. > > > I don’t think anyone is arguing that the SD-JWT specification contains all > the information you need to implement a fully secure age verification > ecosystem, and the same applies to OpenID4VCI and SD-JWT VC as well. Nor > should they contain these things - they are flexible building blocks that > cover many uses cases and can be further profiled/constrained/extended, and > they are building blocks that people appear to be successfully building > secure solutions on top of. This seems close to complaining that the HTTP > RFC doesn’t tell you how you should use cookies when you’re implementing a > banking portal. > > Thanks > > Joseph > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
