Hi all, I created a PR for this change.
https://github.com/oauthstuff/draft-oauth-rar/pull/76 <https://github.com/oauthstuff/draft-oauth-rar/pull/76> Please review and comment/approve. best regards, Torsten. > Am 19.06.2021 um 17:01 schrieb Filip Skokan <[email protected]>: > > I support such change. > > Odesláno z iPhonu > >> 19. 6. 2021 v 15:36, Torsten Lodderstedt >> <[email protected]>: >> >> >> Hi Brian, >> >> the idea was to use resource indicators as convenient short cut to support >> audience restricted access tokens. However, I agree this can be achieved by >> specifying authorization details in the token request as well. >> >> So I‘m fine with dropping resource indicators for RAR at all. This means RAR >> on one hand and scopes + resource indicators on the other hand are clearly >> decoupled and independent. >> >> best regards, >> Torsten. >> >>> Am 18.06.2021 um 20:13 schrieb Brian Campbell >>> <[email protected]>: >>> >>> >>> In my reading and understanding of the text and intent, the content and >>> meaning of a particular authorization details object are fully governed by >>> its "type". And while the draft provides a set of common data elements >>> intended to be usable across different types (locations, actions, >>> datatypes, identifier, privileges) a specific type is free to define >>> whatever suits its needs. A type definition may or may not involve those >>> common elements and could even use the same name(s) with different meaning >>> or structure. >>> >>> So, while I understand the motivation behind the RFC8707 resource parameter >>> being usable in a token request to make the AS filter, the included >>> authorization details of the resultant token based on the "locations" >>> element[1], I'm a bit concerned about a layering problem here. The >>> authorization details objects of the grant might not contain a "locations" >>> element or might have one with a different meaning or structure. >>> >>> The draft also describes using the authorization_details token request >>> parameter to specify the authorization details a client wants the AS to >>> assign to a particular access token[2]. So the problematic resource >>> parameter behaviour is also kind of redundant. I think maybe it should be >>> removed. >>> >>> [*] described in >>> https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-6.2 >>> <https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html%2523section-6.2%26source%3Dgmail-imap%26ust%3D1624644831000000%26usg%3DAOvVaw2Neq-jZjDLFKLvk4ORFZgL&source=gmail-imap&ust=1624719721000000&usg=AOvVaw3VREfBmTcEdimVCRXcGUpu> >>> and mentioned at >>> https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-1-8 >>> <https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html%2523section-1-8%26source%3Dgmail-imap%26ust%3D1624644831000000%26usg%3DAOvVaw1RV1Hi3T3GesR4hdU-tNIj&source=gmail-imap&ust=1624719721000000&usg=AOvVaw3Ccx5Oj2Y6lY4zx0PxUwGH> >>> and in >>> https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-7-1 >>> <https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html%2523section-7-1%26source%3Dgmail-imap%26ust%3D1624644831000000%26usg%3DAOvVaw0ALWuf7bYYCKFQZUkl4NFz&source=gmail-imap&ust=1624719721000000&usg=AOvVaw0B5JKz5Tm3oF4SQv0Olywy> >>> >>> [2] >>> https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#name-token-request >>> >>> <https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html%2523name-token-request%26source%3Dgmail-imap%26ust%3D1624644831000000%26usg%3DAOvVaw1rkJogfzl-0dbnMhVtiOwW&source=gmail-imap&ust=1624719721000000&usg=AOvVaw3BVO3rOm3nxewYzy1aOVqt> >>> 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 >>> [email protected] >>> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1624644831000000&usg=AOvVaw1Ol8hiDotFufYe9jQCTi1m >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
