Hi Justin (and Brian), (I somehow only received the reply from Brian and not the one from Justin.)
I agree that the privacy issue is broader than RAR itself as any claim inside of the JWT could potentially hold private information. Although I understand that nested JWTs can be used to encrypt data for specific recipients, I have yet been unable to find any standard way to encrypt parts of the JWT information for one audience and encrypt another part for a different audience. Any hint where to look is appreciated and if that is already common standard, it might be worthwhile referencing in the RAR spec. Thanks, Kai From: Brian Campbell <bcampbell=40pingidentity....@dmarc.ietf.org> Date: Wednesday, 21. December 2022 at 16:08 To: Justin Richer <jric...@mit.edu> Cc: Kai Lehmann <kai.lehm...@1und1.de>, "oauth@ietf.org" <oauth@ietf.org> Subject: [SENDER VERFICATION FAILED] Re: [OAUTH-WG] Privacy considerations regarding RAR and authorization_details in AT JWT I'll just add that RAR is in the very latter stages of IESG processing for publication, which is a point in the process that is not particularly amenable to changes from the WG. On Wed, Dec 21, 2022 at 7:30 AM Justin Richer <jric...@mit.edu<mailto:jric...@mit.edu>> wrote: 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=401und1...@dmarc.ietf.org<mailto:401und1...@dmarc.ietf.org>> > 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 > OAuth@ietf.org<mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
