Is the effect of a downscoping request still undefined in oauth-uma-ticket?

[xmlgrrl]

In the new UMA Grant spec, Sec 3.6, we've still said an attempt to downscope is undefined. But this spec doesn't even mention the concept of resource-specific scopes (though the AS and RS may have the concept behind the scenes). What's the scoop?

[xmlgrrl]

The Grant spec actually does mention this concept now; it's needed because, even though clients don't need to know about it, the AS does, for authorization assessment and RPT issuance.

Which brings up the idea: We should probably explain why the effect of including a scope parameter on a downscoping request is undefined (it's because the client is unaware of the resource-specific nature of scopes). This subtlety is actually part of the definition of "permission" in Sec 1.3, so it seems like fair game.

[xmlgrrl]

In UMA telecon 2017-05-12 we thought that "undefined" wasn't quite right. This produced recommendations of several edits:

• In Grant Sec 3.3.5, after "This is because RPTs are associated with scopes that are associated with specific resources." say "Note: The outcome of authorization assessment may result in expiration periods for RPTs, permissions, and refresh tokens that can affect the client's later requests for refreshing the RPT."
• In Grant Sec 3.6, instead of the original "undefined" wording: "If the client includes the scope parameter in its request, the authorization server MAY limit the scopes in the resulting permissions to those requested by the client."
  In Grant Sec 3.6, add "The authorization server MUST NOT treat the client's request to refresh an RPT as if it were a request for a new RPT requiring an authorization assessment calculation."

Further discussion on an adjacent topic led us to add the following editorial instructions:

• Grant Sec 3.1: Instead of "Note: How the resource server arranges for resources to be protected in the context of a resource owner is outside the scope of this specification, but it may be useful to consult [UMAFedAuthz]." say "For an example of how the resource server can put resources under the protection of an authorization server, see UMAFedAuthz."
• Grant Sec 3.2.1: Instead of "Note: How the resource server arranges to obtain the permission ticket from the authorization server is outside the scope of this specification, but it may be useful to consult [UMAFedAuthz]." say "For an example of how the resource server can obtain the permission ticket, see [UMAFedAuthz]."
• Grant Sec 3.3.4: Instead of "Note: [UMAFedAuthz] describes how the resource server MAY obtain the permission ticket from the authorization server." say "For an example of how the resource server can obtain the permission ticket, see [UMAFedAuthz]."
• Grant Sec 3.5: Remove both "Note: How the resource server validates the RPT is outside the scope of this specification, but it may be useful to consult..." and "Note: [UMAFedAuthz] describes how the resource server MAY introspect the token at the authorization server preparatory to responding to the client's request." and replace with "For an example of how the resource server can validate the RPT at the authorization server at run time, see [UMAFedAuthz]."

To be implemented in rev 04 for consideration.

[xmlgrrl]

Per UMA telecon 2017-05-18: The recommendations from the previous week, as implemented in rev 04, are acceptable.