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. 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.
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<mailto: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
