[OAUTH-WG] Re: SD-JWT linkability

[Denis <[e-mail]>]

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/".

BTW, the goal is not to disclose the age of a user to a Verifier, nor 
worse - his date of birth - but to only disclose whether the user is
above and/or under an age threshold value.

An implementation of the core of this draft will be unable to support 
"age verification" in a secure fashion when the privacy of the End-User 
is supported.
BTW, verifier-verifier unlinkability IS NOT a characteristic that is 
supported in the core of this document.

On April 8, 2024, at the "Age Assurance Standards Summit" in Manchester 
(UK), I made a one hour presentation on the following topic:

    "Behind the scenes of ISO 27566 & paths for moving forwards". 

I attach two slides from this presentation.

These two slides explain the ABC attack (Alice et Bob Collusion attack) 
in the context of age verification.

A few explanations on the data exchanges:

    (1) Bob requests a digital credential to an Issuer. At this moment,
    the Holder (application) that Bob is using demonstrates to the Issuer
    that the public key that is included in his digital credential
    request has been generated by a Holder that supports some "security
    characteristics".

    If the Issuer is pleased with these "characteristics", then the
    Issuer returns a digital credential to the Holder (2).

    Alice wants to connect to a Verifier that requires End-Users to be
    over 18. Alice requests a challenge to the Verifier (3).

    The Verifier sends back the challenge to Alice (4).

    Alice forwards this challenge to Bob (5).

    Bob uses a specifically developed application that has been made
    freely available on the web to receive the challenge.
    Bob uses this application to generate a SD-JWT that is only
    disclosing that he is over 18. Bob sends back the SD-JWT
    and the associated KB-JWT to Alice (6).

    Alice forward this SD-JWT and the associated KB-JWT to the Verifier (7).

    Alice is now granted an access to the Verifier since she has been
    able to demonstrate that she is over 18.

The key binding method is indeed used but it is insufficient to counter 
the ABC attack. Alice can be in Paris, while Bob can be in Rome.

If this works fine with Alice, then Bob can propose his service to other 
individuals. Since Bob is not identified, he will not / cannot be caught
unless the collaboration from the Issuer is requested and obtained.

Bob can ask 10 € each time he performs the trick: a new lucrative type 
of job has been created.

If two End-Users accept to collaborate and if the implementation of the 
Holder does not prevent it, any selectively disclosable claim can be 
"transferred"
to another End-User without the Verifier being able to detect ,when the 
single-verifier unlinkability property is supported (e.g., when using 
batches
of one-time-use digital credentials).

Before issuing a digital credential, the Issuer needs to know the 
characteristics of the Holder.

To draw a parallel with X.509 Certificates used in the context of 
Electronic signatures, a Certificate Issuer will not issue a PKC if it 
has not been convinced
that the private key is indeed supported (and protected) by a SSCD 
(Secure Signature Creation Device). The fact that, a SCCD is supported 
can be indicated
in the QCStatements field from the Certificate Policy field of an X.509 
certificate.  See

See: ETSI EN 319 412-5 V2.4.1 (2023-09) Electronic Signatures and 
Infrastructures (ESI); Certificate Profiles; Part 5: QCStatements.
https://www.etsi.org/deliver/etsi_en/319400_319499/31941205/02.04.01_60/en_31941205v020401p.pdf

See clause 4.2.2: QCStatement claiming that the private key related to 
the certified public key resides in a QSCD.

At the moment, in the current SD-JWT format, there exists no equivalent 
field that allows the Verifier to know the characteristics of the Holder
by inspecting the SD-JWT.

Using the claims *currently defined* in the draft, age verification 
CANNOT be supported in a secure fashion while respecting the privacy of 
the End-Users.

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.

It would be wise to say it in the security considerations section.

Denis

> Hi
>
>> On 22 Dec 2024, at 20:35, Watson Ladd <[e-mail]> wrote:
>>
>> The fact that you and everyone else feels content to shoot down text
>> rather than try to meet me halfway shows that this isn't an honest
>> attempt to achieve rough consensus or conversely say my views are in
>> the rough because of actually thinking through the issue.  I've been
>> consistent in raising this issue for over a year: to pretend that the
>> WGLC is at all relevant to where we are is a ridiculous excuse made
>> possible only by your own inaction on this issue. I've tried to tweak
>> the text to make it work better, at length, but it's very hard when
>> people say they have concerns without being clear or suggesting
>> alternatives. I'd appreciate you doing me the same courtesy, rather
>> than sitting back and saying "nah, no one agrees enough for us to
>> handle it". I agree that my text may be too limiting or overly
>> prescriptive, but the people closer to the problem need to provide
>> input if there is going to be a text we can live with.
>
> I believe much of this goes back to something you said earlier - that 
> you believe (based on your suggested normative text and your 
> explanation thereof) it should be mandated to use less privacy 
> preserving technologies instead of SD-JWT in some cases. You are of 
> course welcome to hold that opinion, but it seems it is not reflected 
> in the working group consensus.
>
> I don’t think it is helpful to repeatedly make very similar proposals 
> whilst ignoring the feedback on why that proposal is inappropriate, 
> nor does it look like trying to meet halfway - this current proposal 
> and discussion is very similar to, for example, 
> https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/448/files
>
> Whilst I am not saying this is what is deliberately happening here, 
> suggesting text that is overly strict in the hopes of ‘meeting 
> halfway’ is not usually an appropriate strategy in standards 
> development. In my view the general expectation is that text proposed 
> should be a genuine attempt to document the consensus of the working 
> group.
>
> The authors appear to have tried to address your concerns, 
> https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/451 was 
> a response to try and address the underlying issue the above PR was 
> trying to address.
>
>> Secondly the verifier-verifier unlinkability
>> really doesn't have much in the way of actual mitigations: it says you
>> can use one-use credentials, etc. but doesn't mandate, provide
>> designs, explain how to issue based on a previous credential etc. It
>> at least has that material.
>
> Issuing credentials (including how to do batches and re-issuance) is 
> out of scope for the SD-JWT specification itself (in the same way 
> issuing a JWT is out of scope for the JWT specifications) and already 
> dealt with in, for example, https://github.com/openid/OpenID4VCI
>
>> To be absolutely clear, this is what the current text says in its most
>> relevant section "In considering Issuer/Verifier unlinkability, it is
>> important to note the potential for an asymmetric power dynamic
>> between Issuers and Verifiers. This dynamic can compel an otherwise
>> honest Verifier into collusion. For example, a governmental Issuer
>> might have the authority to mandate that a Verifier report back
>> information about the credentials presented to it. Legal requirements
>> could further enforce this, explicitly undermining Issuer/Verifier
>> unlinkability. Similarly, a large service provider issuing credentials
>> might implicitly pressure Verifiers into collusion by incentivizing
>> participation in their larger ecosystem. Deployers of SD-JWT must be
>> aware of these potential power dynamics, mitigate them as much as
>> possible, and/or make the risks transparent to the End-User."
>>
>> That text has a lot of problems:
>>
>> - It presents the issue as one of coercion or malfeasance, rather than
>> e.g. excessive logging, or some other information leak letting the
>> issuer see what the verifier knows.
>
> I think this is covered by 
> https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-14.html#section-10.2 ? 
> If not “leaking SD-JWTs to anyone is problematic for privacy" seems 
> like a specific thing that can be addressed.
>
>> - It says deployers must mitigate the power dynamics, rather than use
>> technical means, with no real guidance as to what that mitigation
>> looks like
>
> I don’t think there have been any proposals of technical means that 
> can prevent this today?
>
>> - It doesn't say what the risks are that must be made transparent
>
> Various risks are explained in the prior 4 paragraphs. Does changing 
> “risks” to “risks as describe above” help?
>
>>
>> It's not something that someone can use to say "no, we shouldn't do X"
>> for any X.
>>
>> All I've been asking to add now is a specific example of what a user
>> might need to know and that if this can't be achieved, don't use
>> SD-JWT. I'm surprised by the enormous pushback to this. All I want to
>> know is is there some form of this we could live with, or what are the
>> concrete issues people have with the proposal. So far I've gotten that
>> actually naming mitigations is a problem. How on earth do I work with
>> that?
>
> Naming possible mitigations is fine as far as I know - naming a single 
> possible mitigation (which is impractical in some cases) with a ‘MUST’ 
> is however problematic. (e.g. "MUST analyze the consequences for such 
> linkage with each
> credential that could be used” as per your first email in this thread.)
>
>> Conversely, if you think age verification with SD-JWT is fine, save me
>> the time and let me know.
>
> 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.
>
> Joseph
>
>
> _______________________________________________
> OAuth mailing list [e-mail]
> To unsubscribe send an email [e-mail]