Hi Jacob,
and here is the PR https://github.com/oauthstuff/draft-oauth-rar/pull/79
<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 <mailto: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
> > <mailto: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 <mailto:oauth-boun...@ietf.org>] on
> > behalf of Jacob Ideskog [jacob.ides...@curity.io
> > <mailto: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 <mailto:ja...@twobo.com>>a...@curity.io
> > <mailto:a...@curity.io><mailto: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 <mailto: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 <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>
> -------------------------------------------------------------------
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
