You are too fast 😊 I am still replying to your other comments! 😃 Yes, it is possible for resource servers to define sub-resource specific scopes, but it cannot be mandated- and it can be extremely problematic when your AS is multitenant. The resource identifier in those scenarios can be a LONG URI, and forcing people to do scope stuffing (eg : csutomresource:// 1f150b81-c98e-45ec-8252-ab47ef0645ff/read) is hard from the management, provisioning and even bandwidth use standpoints. I have experienced this firsthand when Azure AD moved from v1 style resource identification (where resource was a mandatory request param) to v2, where the resource was inferred from the scopes via scopes stuffing.
From: OAuth <oauth-boun...@ietf.org> on behalf of George Fletcher <gffletch=40aol....@dmarc.ietf.org> Date: Tuesday, March 24, 2020 at 11:48 To: Vittorio Bertocci <Vittorio=40auth0....@dmarc.ietf.org>, Takahiko Kawasaki <t...@authlete.com> Cc: oauth <oauth@ietf.org> Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" Focusing just on this comment... This assumes the system uses a specific implementation of scopes values (e.g. 'read', 'write', 'delete'). It is very possible that in the context of a calendar services and an inbox service... the system defines scopes like 'cal-r', 'cal-w', 'mail-r', mail-w' in which there is no ambiguity. On 3/24/20 2:14 PM, Vittorio Bertocci wrote: I don't think the rule referring to the "scope" parameter is worth being defined. That "aud" is missing but "scope" is available is enough for resource servers. In other words, if "aud" is determined based on the "scope", why do we have to set "aud" redundantly? Scope is actually not sufficient for many resource servers. Whenever an RS is facading a collection of existing finer grained resources, scopes representing permissions might be ambiguous - if my API facades both calendar and inbox, what does the "read" scope refer to? Having an audience resolves that ambiguity.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
