Hi Joseph,

You wrote:

   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.

There is a huge difference between a *technology* and a *format*. The "best technology" does not yet exist. It is currently under development by smart phone manufacturers. It might be available between one or two years
from now. The hardware already exists.

The SD-JWT *format* is a good basis to be used on the long term ... but not yet today for age verification.

The draft should recognize the fact that end-users exist and that collusions between end-users can happen and is a risk. That risk should be identified and included into the security considerations section and it should also be indicated that
it cannot addressed using the current format.

At the moment, end-users do not even exist in the draft !

The readers of this draft should not believe that the protocol is immune to end-users collusion attacks and is adequate for age verification,
*while protecting the privacy of the end-users*.

The current  format of the SD-JWT specification DOES NOT identify claims that would be necessary to implement a secure ecosystem.
This can be done later on in other IETF drafts.

Denis


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 tooauth-le...@ietf.org

_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

Reply via email to