Hope you all had a good Christmas break and are on your way to a good New Year. I took an action on our last telecon http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-12-22 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 https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-09.html#give-access" 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 https://xml2rfc.tools.ietf.org/public/rfc/html/rfc3986.html#comparison-strin...?]* - 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. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Mon, Dec 19, 2016 at 9:31 PM, Eve Maler wrote:

Cigdem and I continued meeting for a bit after Thursday's call officially drew to a close. This allowed us to explore a couple of the outstanding "set math" questions in greater detail, which in turn allowed me to form a concrete proposal. After trying it out on Cigdem -- thanks a million! -- in email (see our *italic commentary* in sub-bullets), I wanted to share it with the WG to try and collect discussion before this Thursday.

If possible, *let's see if we can get quorum/critical mass this Thursday* to decide these matters.

The following is written as a summary that would go somewhere in Section 1, with plentiful cross-references to later sections (currently mentioning the relevant sections in rev 09 http://docs.kantarainitiative.org/uma/ed/uma-core-2.0-09.html) where full normative text either currently appears or would need to be added.

====

At several junctures in the authorization process and the surrounding flow, the actors communicate and perform internal mappings regarding relevant protected resources and their scopes, as follows.

- Based on the client's 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 a resource identifier and scope that would suffice for successful access and then requests one or more permissions on the client's behalf that include at least that resource identifier and scope (see Sec 3.2). The authorization server issues a permission ticket that represents exactly the permissions the resource server requested (see Sec 3.2.2). - *In 3.1.1: Add explanation that the client's access attempt implicitly indicates some set of resource identifier possibilities, and cross-ref to 1.4.3 and 3.2* - *1.4.3 has the text it needs already (modulo an editing tweak)* - *In 3.2: Add explanation about interpreting the client's access attempt and mapping to one of the resource identifiers and scopes that suffices* - *3.2.2 has the text it needs already* - Anytime the client approaches the authorization server with a permission ticket to request an RPT (see Sec 3.5.1), if the client requests scopes not already included on operative resource identifiers associated with the permission ticket, 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. It does this regardless of any scopes for which the client has pre-registered (see Sec 3.5). - *Because of new clarity around this whole resource/scope ecosystem, we found ourselves kind of uncomfortable with the newly added scope-requesting feature; discuss whether dynamic additions of scopes by the client makes sense given that the RO can "dynamically reduce" again through policy and the AS can "dynamically reduce" through the partial fulfillment/rejection option? (see below)* - *Assuming the feature is kept: In 3.5.1: Add explanation of how scopes are matched; use exact match a la this https://xml2rfc.tools.ietf.org/public/rfc/html/rfc3986.html#comparison-strin...?* - *3.5 has the text it needs already* - 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 the entire subset of requested permissions or to treat the result as an authorization failure. - *3.5.2 currently words this more softly, whereas it's stated as a binary choice above; since policy conditions are out of band, it's currently impossible to enforce it as a binary; what wording makes sense?* - When 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 ?) as part of considering whether to give access. - *In 3.1.2: We should note that the client could actually attempt to access a different resource, or the same resource with a different scope, than originally when it had no token; there's no way to stop it, and it doesn't harm anything wrt access control.* - *3.4 has the text it needs already, modulo breaking out some of the text to form a new section that focuses on the (RS-internal) RPT assessment process*

*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl