Re: [OAUTH-WG] Call for adoption - SD-JWT

[David Chadwick <[e-mail]>]

Hi Guiseppe

On 03/08/2022 01:02, Giuseppe De Marco wrote:

Hi Neil,

The problem of the linkability affects both sd-jwt (opaque values) and traditional jwt (readable values).

Not if short lived ones are issued for each RP with ephemeral keys

Even if I present an mDL or an sd-jwt without disclosing any user attribute in It, the linkability Is possible exploting the VC itself and its public key, adopted as proof of possession of the vc. The public key won't change in different vcs if the wallet has only a single  private Key to sign it's issuance requests.

I would say this is a bad wallet design.

A salted/hashed value doesnt tell you anything about its content but Is still linkable, because It won't change, It Will be presented and presented again and due to this It is traceable and a user linkable over many different RPs.

This is why a SD-JWT should only be presented to one RP and not re-used

As we have the pairwised subject id in oidc, that changes in relations of the audience, well, even with VCs we May enable the concept of ephemeral VC (and ephemeral bounded public Key). A Citizen that doesnt want to be tracked may ask for the issuance of a VC for each RP.

Exactly. And in this case the VC can be a partial VC with only the subject properties that the RP needs. So there is no need to blind either the property types or values as the not-needed ones wont be present.

Without enabling the advanced crypto in our implementations, the salted/hashed strategy seems like the only usable for selective disclosure in several contexts,

The only context that it is usable over a partial-subject-claims ephemeral VC is offline where the user/wallet does not know in advance who the RP is and the wallet is offline when the RP demands to see it (the police officer on top of a mountain context). So we do have one genuine use case here for SD-JWT. What the ratio of this use case is to overall usage remains to be seen.

thus a good issuance strategy covers the privacy requirements as well, so let's give a place for sd-jwt because we really need It, otherwise we'll have a future painted in mDoc/CBOR and jwt would not be considered as an usable data format. Dont let this happen!

I think this is an over statement of the position. Standard JWTs will be usable in the majority of use cases in my opinion, and SD-JWT in a minority of them. (Note that I have not voted No to this work item as I can see a use for SD-JWT, although I am not convinced that the OAuth WG is the right forum for it to be standardised as I believe that it is independent of OAuth. The SD-JWT for verifiable credentials and mDL should be issued by the RS and not the AS.)

Kind regards

David

Best

 

Il mer 3 ago 2022, 00:10 Neil Madden <[e-mail]> ha scritto:

On 2 Aug 2022, at 21:04, Mike Jones <[e-mail]> wrote:



Neil, you wrote:

"SD-JWT is not simpler. Anyway, I think I have learnt enough from this thread, we don’t have to keep arguing the same points. I think the claims of combinatorial explosion are somewhat exaggerated and I don’t see compelling evidence of a real world need for selective disclosure in OAuth, so I don’t support this draft."

 

Speculatively issuing JWTs with combinations of claims because they might be used in the future might be a fine strawman proposal to score debating points but is hardly a practical engineering solution.

Why would it be speculative? 

  Whereas SD-JWT meets the needs of JSON-based use cases for selective disclosure using the issuer/holder/verifier pattern, including those for ISO Mobile Driver's Licenses.

As far as I can see mobile driving licenses are the *only* concrete use case that has been mentioned so far. Did I miss one?

Given that the goal is to reproduce “the user experience of presenting credentials in-person”, let’s look at one. My driving license lists the following information:

* a unique driver id (which itself encodes part of my name, dob, and a male/female bit)

* full name

* address

* date and country of birth

* license issuer, issued-at and expiry dates

* the categories of vehicle I’m entitled to drive

ISO mobile drivers’ licenses are supposed to be unlinkable so the driver ID is out. The expiry and issued-at probably shouldn’t be able to be selectively non-disclosed. So that only leaves 5 fields: full name, address, date of birth, country of birth, and categories of vehicle. 

So even if you issued a separate JWT for each field, that’s only 5 JWTs. Why is that not practical? 

— Neil

 

That's why I support adoption.

 

                                                       -- Mike

 

From: OAuth <[e-mail]> On Behalf Of Neil Madden
Sent: Tuesday, August 2, 2022 2:16 AM
To: Kristina Yasuda <Kristina.Yasuda=[e-mail]>
Cc: oauth <[e-mail]>
Subject: Re: [OAUTH-WG] Call for adoption - SD-JWT

 

 

On 2 Aug 2022, at 03:20, Kristina Yasuda <Kristina.Yasuda=[e-mail]> wrote:

 

I support adoption.

 

To add some color. 

 

One of the use-cases is a flow where issuance of a user credential (collection of user claims) is decoupled from presentation (where both issuance and presentation of a user credential are done using extensions of OAuth flows). The goal of this decoupling is to avoid “issuer call home”, where the user can send a user credential directly to the RP, without RP needing to contact the Issuer directly.

 

So what’s the plan for revocation in this scenario? Something like OCSP Stapling? Short-lived tokens? Either way, the client will need to go back to the issuer regularly.

So the motivations are not limited to offline scenarios, but are applicable to the scenarios that want to recreate in the online environment, the user experience of presenting credentials in-person.

 

I’m not sure why this would be a goal. Presenting credentials in person is subject to many constraints that just don’t apply in the digital world.

 

Driver’s Licence just happens to be an example familiar to many, and there is no reason it cannot be a diploma, or an employee card, or a training certificate, etc. But it is worth highlighting that SD-JWT work becomes critical if we are to enable ISO-compliant mobile Driver Licences expressed in JSON to enable online scenarios and make life of the Web developers easier (as opposed processing data encoded as CBOR and signed as a COSE message). Selective disclosure is a requirement in many government issued credentials, while the usage of advanced cryptography is not always encouraged by the national cybersecurity agencies.

 

I’m not sure what any of this has to do with OAuth?

 

 

Regarding an approach where issuer issues multiple JWTs of a same type but with different subset of claims, it is not an ideal way to do selective disclosure with JWTs (type as a way to differentiate credential with one data structure/syntax from another). It complicates implementations that try to provide RP-U unlinkability (RPs cannot collude to track the user). The simplest way to achieve unlinkability with JWTs without using advanced cryptography is to issue multiple credentials of the same type but with varying use identifiers and enable pairwise identifiers per RP. Now there are multiple copies of each JWT with subset of claims of the same type. This greatly complicates presentation of these credentials too – since credentials are of the same type, now wallet needs to manage the combination of a subset of claims + pairwise identifier…

 

The same is needed in SD-JWT - the wallet needs to manage pairwise identifiers and which subset of claims to disclose.

 

What if the implementation also wants predicates property, where age_over_XX boolean is sent instead of a birthdate string? The simplest way to do predicates with JWTs without using advanced cryptography is to have issuers to issue multiple age_over_xx booleans so that an appropriate one can be selectively disclosed to the RP. How many “JWTs with subset of claims” does the issuer needs to issue to account for all possible age requirements? Note that it’s not just age_over_21 to start gambling, it’s also age_over_65 to get pension benefits. 

 

Being over 65 also proves that you are over 21.

 

 

Managing the combinatorial explosion of sets of claims in speculatively issued JWTs, many of which will never be used, seems unwieldy, to say the least. "A conventional JWT with a subset of claims" approach could be taken in some implementations, but it should not prevent a simpler, extensible alternative of SD-JWT.

 

SD-JWT is not simpler. Anyway, I think I have learnt enough from this thread, we don’t have to keep arguing the same points. I think the claims of combinatorial explosion are somewhat exaggerated and I don’t see compelling evidence of a real world need for selective disclosure in OAuth, so I don’t support this draft.

 

 

Finally, as Giuseppe pointed out, an option to blind claim names is on the table. As discussed on this list previously, we should analyze privacy properties of the mechanism and decide if we want to mandate it – which can be discussed after the adoption.

 

Best,

Kristina

 

 

— Neil

_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth" rel="noreferrer noreferrer nofollow" target="_blank" class="moz-txt-link-freetext">https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth" rel="nofollow">https://www.ietf.org/mailman/listinfo/oauth