to send out a revised set math proposal. Based on our telecon discussion, my extended conversation with Robert at the end of the call (see the linked notes), and further consideration, this proposal allows for:
- A client to ask for more scopes when acting on behalf of an RqP (any stage in the UMA flow, basically) than it did when acting on its own behalf (pre-registering for scopes), on the logic that it's acting on someone else's behalf now
- An RS to request whatever resources and scopes it judges are appropriate for the requesting side to have (i.e., asking for less is kosher), on the logic that this is a form of "edge protection" it has the right to apply -- 'cause that's what the "Adrian clause" would mean if applied before, not just after, token issuance
I've kept the proposal in summary (and non-normative) form for now, but have removed most of the interstitial "spec instructions" to keep things more easily readable. All of the cross-refs may not survive; at this point, they are partly to remind me where to add or check spec text. I'm working on rev 10 and rev 03 now, but won't include this proposal in those revs unless, by some miracle, we seem to achieve rough consensus in this email thread prior to our Thursday, January 5 telecon.
Thanks!
====
At several junctures in the protocol flow, the actors communicate and perform mappings regarding protected resources and their scopes, as follows.
- During the process of registering for OAuth client credentials on its own behalf (see Sec 3.5), the client may have pre-registered for a set of scopes about which the authorization server is aware (for example, through the process defined by [RFC7591]).
- When the client makes an initial attempt to access a protected resource (see Sec 3.1.1), the resource server, which is responsible for managing any internal resource complexity (see Sec 1.4.3), maps the access attempt to potentially relevant resource identifiers and scopes and determines which one or more permissions to request on the client's behalf (see Sec 3.2). The resource server has discretion over the extent of access covered by the request (see Sec 3.3.3); for example, it can cover the entire extent of the access attempt, or a greater extent, or even a lesser extent. The authorization server issues a permission ticket that represents exactly the permissions the resource server requested (see Sec 3.2.2).
- Anytime the client approaches the authorization server with a permission ticket to request an RPT on its requesting party's behalf (see Sec 3.5.1), it can request scopes not already included on operative resource identifiers associated with the permission ticket. In this case, the authorization server dynamically extends the requested permissions associated with the permission ticket by mapping each of the requested scopes to any of the resource identifiers that have that scope through an exact matching process. It does this regardless of any scopes for which the client has pre-registered. [use exact match a la this?]
- After the authorization server performs authorization assessment (see Sec 3.5.2) against the requested permissions associated with the permission ticket and policy conditions, if only a subset of policy conditions is met allowing a subset of the resource identifiers and/or their scopes among the requested permissions, it is free to grant a subset of requested permissions or to treat the result as an authorization failure.
- Whenever the client attempts to access a protected resource with an RPT (see Sec 3.1.2), the resource server determines the RPT status (see Sec 3.4), maps the access attempt to a resource identifier and scope that would suffice for success access, and compares the result to the RPT status (see Sec [new?]) as part of considering whether to give access.