I support such change. Odesláno z iPhonu
> 19. 6. 2021 v 15:36, Torsten Lodderstedt > <torsten=40lodderstedt....@dmarc.ietf.org>: > > > 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 >>> <bcampbell=40pingidentity....@dmarc.ietf.org>: >>> >> >> 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 and >> mentioned at >> https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-1-8 and >> in https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-7-1 >> >> [2] >> https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#name-token-request >> >> 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.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1624644831000000&usg=AOvVaw1Ol8hiDotFufYe9jQCTi1m > _______________________________________________ > 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
