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 | Skype: xmlgrrl | Twitter: @xmlgrrl