> On 2 Aug 2022, at 21:04, Mike Jones <michael.jo...@microsoft.com> 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 <oauth-boun...@ietf.org> On Behalf Of Neil Madden > Sent: Tuesday, August 2, 2022 2:16 AM > To: Kristina Yasuda <Kristina.Yasuda=40microsoft....@dmarc.ietf.org> > Cc: oauth <oauth@ietf.org> > Subject: Re: [OAUTH-WG] Call for adoption - SD-JWT > > > On 2 Aug 2022, at 03:20, Kristina Yasuda > <Kristina.Yasuda=40microsoft....@dmarc.ietf.org> 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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
