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

[Torsten Lodderstedt <[e-mail]>]

> Am 02.08.2022 um 11:06 schrieb Warren Parad <[e-mail]>:
> 
> I was following your train of thought, let me paste that here for transparency, you specifically said:
> In an OAuth scenario, the user‘s wallet would act as AS and issue access tokens (those could be short lived) that effectively are verifiable presentations (based on a verifiable credential) audience restricted for a certain RS. The client wouldn’t even know it’s a verifiable presentation since the access token is opaque to the client.
> 
> Which I replied:
> If the user's wallet acts as the AS issuing tokens, then there is zero need for this draft because we could pass the scopes that relate to the claims directly to the AS, and have the AS return a limited JWT, and we would actually do that every time because:
> we can
> because the tokens have short lifetime
> So that isn't a valid argument, unless there's a reason why the AS wouldn't be able to do this.
> 
> In this conversation, I'm still not able to parse what you are saying. Yes, of course the user having a physical device (as the AS) to issue tokens is privacy enhancing, but then we don't need this draft as I just proved. Or are you talking about a different point?

In the model I envision, OAuth clients are able to obtain access tokens for the user’s services through the user’s wallet. Since the wallet is not the AS the RS trusts, I would like to utilize verifiable credentials as basis for issuing access tokens from the wallet. That means the credential is issued by the AS and the wallet can mint access tokens containing a presentation of such a credential. From a RSs standpoint this retains the standard trust model since the RS only accepts access tokens containing a credential from an AS it trusts. 

I also assume that a single AS is managing access to several RSs as that was the case in almost all deployments I was involved with. 

I think the most efficient and flexible way to implement this scenario is to issue a single SD-JWT based credential and to mint RS-specific access token as needed by using SD-JWT’s selective disclosure capabilities. So an access token for the user’s contacts API would only include the claims needed for this service (e.g. the privilege to use the service) whereas an access token for the streaming API would include the data needed there (e.g. authorised channel lists and so on). 

> 
> On Tue, Aug 2, 2022 at 10:54 AM Torsten Lodderstedt <torsten=[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
>> Am 02.08.2022 um 10:48 schrieb Warren Parad <wparad=[e-mail] <mailto:[e-mail]>>:
>> 
>> 
>> Can you please reread what you wrote and rephrase it differently? Telling us to look at the OAuth JWT RFC isn't helpful here.
> 
> You say the AS can issue an access token every time and I say the wallet can issue access tokens on its own without the need to go back to the AS every time again. That’s privacy enhancing and helps scalability.
> 
>> Also it isn't clear which part of your statement you are trying to clarify. What does "original AS" mean? Are you suggesting a "multi AS" configuration? What does that look like?
>> 
>> On Tue, Aug 2, 2022 at 10:44 AM Torsten Lodderstedt <torsten=[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>>> Am 02.08.2022 um 10:35 schrieb Warren Parad <wparad=[e-mail] <mailto:[e-mail]>>:
>>> 
>>> 
>>> Why would we not include those seemingly critical details in the draft then?
>>> Let's define what a verifiable presentation is (is that already defined somewhere? I didn't see it in the draft)
>>> Require the JWTs to be signed with a private key from a certificate chain, and include the whole certificate chain in the body. (I don't think there is already a RFC for this, but I could be wrong)
>>> Let's also talk about this comment:
>>> In an OAuth scenario, the user‘s wallet would act as AS and issue access tokens (those could be short lived) that effectively are verifiable presentations (based on a verifiable credential) audience restricted for a certain RS. The client wouldn’t even know it’s a verifiable presentation since the access token is opaque to the client.
>>> 
>>> If the user's wallet acts as the AS issuing tokens, then there is zero need for this draft because we could pass the scopes that relate to the claims directly to the AS, and have the AS return a limited JWT, and we would actually do that every time because:
>>> we can
>>> because the tokens have short lifetime
>>> So that isn't a valid argument, unless there's a reason why the AS wouldn't be able to do this.
>> 
>> Well, how many access tokens have you seen in the wild that only contain an access token? I haven’t, any of the carriers some for of user claims, e.g. a sub, in most cases some privileges/roles. Please take a look at https://www.rfc-editor.org/rfc/rfc9068.html <https://www.rfc-editor.org/rfc/rfc9068.html> for best current practice.
>> 
>> Using a VC in the way I described means the original AS doesn’t need to be involved in the
>> 
>>> 
>>> On Tue, Aug 2, 2022 at 10:14 AM Torsten Lodderstedt <torsten=[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> 
>>>> Am 02.08.2022 um 09:53 schrieb Warren Parad <wparad=[e-mail] <mailto:[e-mail]>>:
>>>> 
>>>> 
>>>> If we are in a offline scenario how does the verifier got ahold of the public key associated with the id token?
>>> 
>>> Why id token? I would assume we are talking about verifiable presentations, right?
>>> 
>>> There are a couple of ways to provide the verifier with the public key needed to verify. The (raw) key could be contained in the credential or the presentation. If a trust chain is required, a x.509 certificate could serve the same purpose.
>>> 
>>> Beside that offline has different facets. In a Point of Sales scenario, even though the wallet would be offline the checkout counter would most likely have connectivity. That would also allow to resolve the public key on demand.
>>> 
>>>> 
>>>> 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.
>>> 
>>> Absolutely. That’s the reason a verifiable credential has a much longer lifetime simply because the user should be able to use it in a sensible way. As this makes replay more likely, all verifiable credentials formats utilize holder binding for reply detection. The public key mentioned above is part of the cryptographic holder binding that only the legitimate user is able to execute.
>>> 
>>> In an OAuth scenario, the user‘s wallet would act as AS and issue access tokens (those could be short lived) that effectively are verifiable presentations (based on a verifiable credential) audience restricted for a certain RS. The client wouldn’t even know it’s a verifiable presentation since the access token is opaque to the client.
>>> 
>>>> 
>>>> 
>>>> On Tue, Aug 2, 2022, 04:21 Kristina Yasuda <Kristina.Yasuda=[e-mail] <mailto:[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 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 <[e-mail] <mailto:[e-mail]>> On Behalf Of Rifaat Shekh-Yusef
>>>> Sent: Thursday, July 28, 2022 8:17 PM
>>>> To: oauth <[e-mail] <mailto:[e-mail]>>
>>>> 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
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>