[OAUTH-WG] Re: Second WGLC for SD-JWT

[Denis <[e-mail]>]

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
> <[e-mail]>  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 [e-mail]
>> To unsubscribe send an email [e-mail]
>
>