Re: [OAUTH-WG] Privacy considerations regarding RAR and authorization_details in AT JWT
Hi Steinar, I did look into Selective Disclosure already and I did not mention it because I don’t think that it is applicable to Access Token JWTs for selectively disclosing data to RS because a RS will receive the AT from the Client and would like to decrypt the part only visible to this particular RS without additional remote calls (e.g. the AS). Without the Disclosure part, the RS cannot do that. Attaching the Disclosure part to the AT JWT would allow any receiver of that JWT to access the disclosed part. Kai From: Steinar Noem Date: Thursday, 12. January 2023 at 17:30 To: Kai Lehmann Cc: Brian Campbell , Justin Richer , "oauth@ietf.org" Subject: Re: [OAUTH-WG] [SENDER VERFICATION FAILED] Re: Privacy considerations regarding RAR and authorization_details in AT JWT 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 mailto: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 mailto:40pingidentity@dmarc.ietf.org>> Date: Wednesday, 21. December 2022 at 16:08 To: Justin Richer mailto:jric...@mit.edu>> Cc: Kai Lehmann mailto:kai.lehm...@1und1.de>>, "oauth@ietf.org<mailto:oauth@ietf.org>" mailto: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 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 > 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&
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 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 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
Re: [OAUTH-WG] Privacy considerations regarding RAR and authorization_details in AT JWT
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 > 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
[OAUTH-WG] Privacy considerations regarding RAR and authorization_details in AT JWT
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
