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
