If we are in a offline scenario how does the verifier got ahold of the public key associated with the id token?
They would need to be online, that defeats any benefit this could provide. Or what if the token you have expires. Many providers issue tokens only good for 1 hour. If that expires, the user has to go through the online flow again. Unless we can add some provisions to ensure long lived token validity, I think in practice we're cripling the usefulness. On Tue, Aug 2, 2022, 04:21 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 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. > > > > 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. > > > > > > 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… > > > > 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. > > > > 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. > > > > > > 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 > > > > > > *From:* OAuth <oauth-boun...@ietf.org> *On Behalf Of * Rifaat Shekh-Yusef > *Sent:* Thursday, July 28, 2022 8:17 PM > *To:* oauth <oauth@ietf.org> > *Subject:* [OAUTH-WG] Call for adoption - SD-JWT > > > > All, > > > > This is a call for adoption for the *SD-JWT* document > > https://datatracker.ietf.org/doc/draft-fett-oauth-selective-disclosure-jwt/ > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-fett-oauth-selective-disclosure-jwt%2F&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Ca2d72420ea2c40f2d7c908da70f7b388%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637946506426392735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=d1EoHuRcBi40%2B1h1p5yZ28O7l8oq%2FibDewlJObT1Gwc%3D&reserved=0> > > > > Please, provide your feedback on the mailing list by *August 12th*. > > > > Regards, > > Rifaat & Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
