> 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
