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
