Thank you Torsten, that's a good addition, it helps to have that clarified.
BR Jacob Den mån 6 sep. 2021 kl 16:05 skrev Torsten Lodderstedt < tors...@lodderstedt.net>: > Hi Jacob, > > and here is the PR https://github.com/oauthstuff/draft-oauth-rar/pull/79 for > review. > > Thanks for the proposed text. I modified it a bit because I think the AS > should only omit data (not mask) and data can be provided even if > considered sensitive as long as there is a reasonable purpose and a legal > basis. > > best regards, > Torsten. > > Am 06.09.2021 um 09:52 schrieb Jacob Ideskog <jacob.ides...@curity.io>: > > Yes, privacy considerations could be more explicit about this. It should > probably explicitly mention the token response and the Client. > > I also suggest clarifying in 7 or 7.1 that the token response MAY be less > explicit or even different than the authorization details issued in the > tokens. > > This is not simple, since it may lead the Client to think it has more (or > less) access than it actually does, but since the intended audience of the > authorized data is the RS it should be ok. > A scenario I see is that the client requests Account access based on > pseudonyms or names of the accounts ("accounts" : ["foo", "bar"]) . The AS > replaces these with the actual account numbers ("accounts" : ["123-123", > "234-BCD"]) so the RS doesn't have > to deal with those translations. So: in the token response the pseudonyms > are still used, but in the issued token the explicit account values are > used. > > Suggestion for section 7: > "The AS MAY omit, mask or hide values in the authorization_details to the > Client in the Token Response if these are deemed sensitive and of no > intended use for the Client." > > Something in that direction would make it more clear that it is allowed to > do so, and that the Token Response doesn't prevent the issued token from > containing sensitive data. > > /Jacob > > > Den lör 4 sep. 2021 kl 11:41 skrev Torsten Lodderstedt < > tors...@lodderstedt.net>: > >> The AS intentionally shares the list of accounts in the mentioned example >> with the client. The assumption is the client asks for access to some >> accounts and the user decides which accounts to grant the client access to. >> This means the AS is authorized by the user to share this data. >> >> The privacy considerations section already has text about sharing data >> with resource servers. I suggest to add some text re data sharing with >> clients. >> >> Would that work for you? >> >> > Am 04.09.2021 um 03:12 schrieb Justin Richer <jric...@mit.edu>: >> > >> > This is a fair point... The privacy and security considerations talk >> about this a bit as I recall, but likely need to in more depth and >> specificity. This is an intentional message channel to the client from the >> AS, but if the AS is blindly sending all information it might be saying >> more than it means to say to an entity that doesn't need that detail to >> function. Scopes have similar issues, but this structure adds more >> opportunities for mistakes just due to the possible increased complexity. >> > >> > -Justin >> > ________________________________________ >> > From: OAuth [oauth-boun...@ietf.org] on behalf of Jacob Ideskog [ >> jacob.ides...@curity.io] >> > Sent: Friday, September 3, 2021 10:42 AM >> > To: oauth >> > Subject: [OAUTH-WG] RAR 05 - Token response with sensitive data in >> draft-ietf-oauth-rar-05 >> > >> > Hi all, >> > >> > I have a question about section 7.0 and 7.1 in draft-ietf-oauth-rar-05 >> that describes the token response. >> > >> > The authorization_details values could be sensitive in their nature. >> The example in section 7.1 highlights this nicely. The accounts array is >> empty when the client requests it, but is enriched by the AS and returned >> to the client in the token response. >> > >> > This means that the AS may leak potentially sensitive information to >> the client in a new place. Before this was only possible in the ID Token or >> UserInfo or if the AS returned a JWT as an access token which the client >> popped open (even though it shouldn't). >> > >> > I understand that the spec considers this an option for the AS to >> enrich or not. I think the enrichment is good and necessary, but with the >> side-effect of it ending up in the token response it becomes an issue. >> > >> > Is the token response a mirror of the authorization_details claim in >> the corresponding access token, or can it be a masked version? >> > >> > Perhaps the security considerations section should be updated with a >> statement with regards to the fact that the client may see claim data only >> intended for the RS? >> > >> > Regards >> > Jacob Ideskog >> > >> > >> > >> > -- >> > Jacob Ideskog >> > CTO >> > Curity AB >> > ------------------------------------------------------------------- >> > Sankt Göransgatan 66, Stockholm, Sweden >> > M: +46 70-2233664 >> > j<mailto:ja...@twobo.com>a...@curity.io<mailto:a...@curity.io> >> > curity.io >> <https://www.google.com/url?q=http://curity.io&source=gmail-imap&ust=1631519577000000&usg=AOvVaw06CD-jyXY8ZUbe6Se8zTxW> >> < >> https://www.google.com/url?q=http://curity.io&source=gmail-imap&ust=1631322760000000&usg=AOvVaw0O7NO5RiGVK6v1SxLCSz4k >> <https://www.google.com/url?q=https://www.google.com/url?q%3Dhttp://curity.io%26source%3Dgmail-imap%26ust%3D1631322760000000%26usg%3DAOvVaw0O7NO5RiGVK6v1SxLCSz4k&source=gmail-imap&ust=1631519577000000&usg=AOvVaw2ZHL9POUAiJQwAjO7-eI2g> >> > >> > ------------------------------------------------------------------- >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > >> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1631322760000000&usg=AOvVaw2Fa1GyOiE6a7mRCghwMI5J >> <https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.ietf.org/mailman/listinfo/oauth%26source%3Dgmail-imap%26ust%3D1631322760000000%26usg%3DAOvVaw2Fa1GyOiE6a7mRCghwMI5J&source=gmail-imap&ust=1631519577000000&usg=AOvVaw1DvMqrevDRPlpmrI_WCM6t> >> > > > -- > Jacob Ideskog > CTO > Curity AB > ------------------------------------------------------------------- > Sankt Göransgatan 66, Stockholm, Sweden > M: +46 70-2233664 > j <ja...@twobo.com>a...@curity.io > curity.io > <https://www.google.com/url?q=http://curity.io&source=gmail-imap&ust=1631519577000000&usg=AOvVaw06CD-jyXY8ZUbe6Se8zTxW> > ------------------------------------------------------------------- > > > -- Jacob Ideskog CTO Curity AB ------------------------------------------------------------------- Sankt Göransgatan 66, Stockholm, Sweden M: +46 70-2233664 j <ja...@twobo.com>a...@curity.io curity.io -------------------------------------------------------------------
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
