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=1631322760000000&usg=AOvVaw0O7NO5RiGVK6v1SxLCSz4k> > ------------------------------------------------------------------- > > _______________________________________________ > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
