Re: [OAUTH-WG] Privacy considerations regarding RAR and authorization_details in AT JWT

[Justin Richer <[e-mail]>]

Hi Kai,

Both of those approaches are common approaches for preventing the leakage of private information in JWTs, and neither is specific to the RAR specification. The use of RAR objects does make it easier to have more specific detail, but that detail could have easily been leaked through a scope or any other custom claim in a JWT. The important thing for RAR is to point out the RAR object as a :source: of that kind of data and call out the desired effect of mitigation (ie, limiting to the intended audience of the token). General mechanisms for reaching that mitigation, such as introspection and multi-target encryption, aren’t really for RAR to define since they aren’t specific to RAR in the slightest.

In the end, you’ve drawn exactly the right conclusions from the text that we would hope an implementor would draw from reading this text. As such, to me, that means the text is doing its job. If we can make that clearer, and help more people reach that same conclusion more quickly, the editors would love any hint on what you think we might be able to do.

Thank you,
 — Justin

> On Dec 19, 2022, at 3:02 AM, Kai Lehmann <kai.lehmann=[e-mail]> wrote:
> 
> Hi,
> 
> In the privacy considerations section of the RAR specification (https://www.ietf.org/archive/id/draft-ietf-oauth-rar-21.html#name-privacy-considerationsit) it is stated:
> 
> 
> “The AS needs to take into consideration the privacy implications when
> sharing authorization_details with the client or resource servers.
> The AS should share this data with those parties on a "need to know"
> basis as determined by local policy.“
> 
> The proposed standard recommends to embedd the authorization_details in the JWT-based Access Token "filtered to the specific audience".
> 
> I assume audience restricted ATs are meant here.
> 
> My concern is that there can be multiple RS which the client intents to use the AT for. Even with audience restricted ATs, it may be the case that personal information being part of the authorization_details should only be visible to one of the AS and not the others. I don't really see how the Authorization Server is able to craft ATs which can be used for all of the given audience while only one or some ought to be able to read the authorization_details. Even if the AS is able to enforce a policy to allow only one audience with the authorization request, it does not prevent the client from accidentally misusing the issued AT with another RS for which it was not intended and thus leaking personal information to that RS.
> 
> I think that in order to prevent authorization_details to be accessible by multiple RS, Token Introspection should still be used to validate JWT-based ATs and only include the authorization_details in the Token introspection response which the RS need to know.
> 
> Another approach would be to have an authorization_details section encrypted asymmetrically for each audience separately so that each RS can only extract the authorization_details it needs. That could mean JWTs inside of JWTs.
> 
> I think it would help to add more details to the privacy considerations or even describe how exactly this can be achieved.
> 
> Best regards,
> Kai
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth