Hi Watson,
1) You wrote:
if a user uses this technology to pass an age
verification filter, they will end up exposing their complete identity
without knowing it.
When reading the current draft, I understand that your position looks
correct.
However, it is possible to only reveal that an End-User is over 18
without revealing his complete identity,
but this can only be achieved if collusion / collaborative attacks
between End-users against a Verifier
can be prevented.
See my comments:
*33.**Section 9.5 (Key Binding), *
*
*
***24.**Section 5.1.2*
*27.**Section 4.3.2 (Validating the Key Binding JWT)*
which indicates that an additional claim is REQUIRED in that case:
*
-hchar: REQUIRED.This claim allows the Verifier to know
specific characteristics of the Holder (holder characteristics),
in particular whether some of these characteristics are able to
counter Holder collaborative attacks against a Verifier.
*
2) On 31/07/2024 under the topic "[OAUTH-WG] Re: We cannot trust Issuers",
See:
https://mailarchive.ietf.org/arch/msg/oauth/-nmcr36-4qg7NuoXhiuP1nwJonQ/
you wrote:
I've opened
https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/448
as a step torwads this.
On Mon, 2024-07-22 at 19:43 -0400, Richard Barnes wrote:
I would observe that any solution based on garden-variety digital
signature (not something zero-knowledge like BBS / JWP) will have
problems with issuer/verifier collusion.One-time tokens and batch
issuance don't help.There is no such thing as SD-JWT with
issuer/verifier collusion resistance.At best you could have SD-JWP.
I don't think this needs to be a blocker on SD-JWT.There are use
cases that don't require issuer/verifier collusion resistance.We
should be clear on the security considerations and warn people away
who care about issuer/verifier collusion resistance, and accelerate
work on SD-JWP if that's an important property to folks.
(...)
There is an attempt at a discussion around unlinkablity in the privacy
considerations at
https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-unlinkability
currently.
Concrete suggestions to that text about how to better frame
the risks and difficulties around Issuer/Verifier Unlinkability
(perhaps especially with respect to something like a
government issuer compelling collusion from verifiers) would be welcome
for consideration.
In my comment numbered 36. New Section 10.2 (Intrackability), I have
purposely not used the word "unlinkability" for that case, but the word
"untrackability".
A major advantage is that an Issuer *alone* cannot *track* the
End-User activities.
It has been advertised that concrete suggestions "would be welcome for
consideration". I have provided concrete suggestions to that text about
how to better frame the risks and difficulties around this issue in my
comment numbered 36.
. When both the Verifier and the Issuer are forced to collaborate, e.g.,
upon the request from a national authority, a means to mitigate the risk
is indicated. Denis
The privacy issues I have consistently raised have not been addressed
through actionable text.
Implementers are not receiving guidance with the current version. The
actual risks are buried below a bunch of words talking around the
issue.
I'll be very clear: if a user uses this technology to pass an age
verification filter, they will end up exposing their complete identity
without knowing it. This is an unacceptable risk, and no one disagrees
the technology poses it. Implementers will often not have the skills
or knowledge to identify this concern independently, and need
actionable guidance on how to mitigate it. We provide far more
actionable guidance on storage of credentials.
On Fri, Oct 18, 2024 at 11:00 AM Rifaat Shekh-Yusef
<[email protected]> wrote:
All,
This is a short second WG Last Call for the SD-JWT document after the recent
update based on the feedback provided during the first WGLC
https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-13.txt
Please, review this document and reply on the mailing list if you have any
comments or concerns, by Oct 25th.
Regards,
Rifaat & Hannes
_______________________________________________
OAuth mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
