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
