Hi Kai! The selective disclosure draft has a take on how to preserve privacy which I think is promising and seems fitting for some scenarios that I work with.
https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-02.html Regarding RAR I guess that handling the privacy issues will be up the implementors and their DPIA/risk analysis. In our case we are transmitting sensitive information, and are discussing wether we should encrypt the jwt, or only encrypt the authorization_details structure using JWE. S tor. 12. jan. 2023 kl. 16:44 skrev Kai Lehmann <kai.lehmann= 401und1...@dmarc.ietf.org>: > 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> 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> 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 > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > 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 > -- Vennlig hilsen Steinar Noem Partner Udelt AS Systemutvikler | stei...@udelt.no | h...@udelt.no | +47 955 21 620 | www.udelt.no |
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
