December 2016 - WG-UMA - mailman.kantarainitiative.org

Caching, OAuth, UMA, and security considerations
by Eve Maler 06 Jan '17

06 Jan '17

In our 2016-11-10 telecon <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-11-10?…>, we said: *"Sec 3.4: The RS has the option of using cached RPT status results, so include this in the options (has swimlane implications?). This is also an AS TTL strategy thing (including revocation and disconnected RS scenarios, e.g. IoT scenarios), which we should comment on if we haven't already.* - *Add companion security considerations around TTL for RPTs and permissions, since you need to measure risk and risk appetite based on the RS, the resource itself, and even the nature of the policy conditions etc. Without active revocation infrastructure, the risks are higher."* So I poked around the OAuth spec to see if there's similar wording I could align with, and discovered this in Sec 5.1 <https://tools.ietf.org/html/rfc6749#section-5.1>: *"The authorization server MUST include the HTTP "Cache-Control" response header field [RFC2616] with a value of "no-store" in any response containing tokens, credentials, or other sensitive information, as well as the "Pragma" response header field [RFC2616] with a value of "no-cache"."* So...I believe this means the client isn't allowed to cache tokens given to it by the AS, and maybe the RS isn't allowed to cache token introspection responses given to it if the token introspection spec follows along in this pattern. But the RS is allowed to cache tokens that the client brings to it because this isn't an AS response, but rather a client request. And if it has locally validated those tokens, it can hang onto the results as long as it wants as well. I looked a little further, at the OAuth Threat Model spec, and there's potentially some broadly suggestive text in Sec 4.6.6 <https://tools.ietf.org/html/rfc6819#section-4.6.6> about both clients and RS's using Cache-Control: private to protect against leakage through HTTP proxies, but nothing more directly relevant. Some specific questions for people to react to: - Is my interpretation above about the RS's abilities correct? With an analysis of who can cache what completed, would anyone agree it might be helpful to put the result into the spec as a "Note" observation so others don't have to repeat the exercise and possibly get it wrong? - Our spec says it "mainly relies on OAuth" for security considerations. Does this mean we must pick up on the prohibition against the AS letting the recipient cache things? I don't think so because it's in the main body of the spec. - Do we therefore want to *add* similar wording for the same security reasons OAuth itself has that wording? - What exactly should our security consideration about TTL of permissions and RPTs say? I think it should cover the circumstances of both local validation and caching. I could use wording similar to what our telecon notes say, but the trick is that the RS doesn't have access to the policy conditions. However, it does have "Adrian clause" rights it may want to apply, so we could mention that. - In fact, I'm starting to think that a more extended discussion in the Federated Authorization section about this concept -- the fact that the RS retains "edge (local?) authorization" rights -- would be useful to point to from more than one other location in the spec, including this new Security Considerations section. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

5 7

Potential privacy issue with PCT
by Justin Richer 04 Jan '17

04 Jan '17

I was running through our current protocol text and stumbled over what might be a privacy issue with regard to the PCT. Namely, a PCT is meant to represent a set of claims previously presented by the RqP. The question is, how do we store that information? If we store the claims themselves, then we’re potentially storing personal information about the RqP for the lifetime of the PCT. This may or may not be a problem, and perhaps it’s an implementation decision for the AS to decide how much data it wants to keep around to make things happen. My initial thought was that we could store the *results* of the PCT calculation, but the problem of that is that it only makes sense with regard to a given policy set. What if the policies change, should the PCT be re-run, revoked, or represent its initial calculation? What if the PCT is used against a different resource with different policies? A potential implementation solution would be to store hashes of the claims to use in the policy calculation instead of the claims themselves. The policy engine would of course need to account for this, but it would potentially solve the problem of storing sensitive data. We would need to be clear in Privacy Considerations what that would look like and what the tradeoffs would be. Note well: Before you call for the AAT’s return, I’d like to point out that it suffers from the same set of problems when applied to policy calculations in this way. — Justin

2 3

AS flexibility around access token management: simplify?
by Eve Maler 02 Jan '17

02 Jan '17

Cigdem asked some good questions in a series of comments she sent me: Core Section 3.5.3 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-09.html#give-rpt> (rev 09) has a Note that explains: "The authorization server is free to choose to return either the same RPT that appeared in the request or a new RPT, and it is also free to choose to *invalidate or retain the validity* of the original RPT or any permission that was previously added to that RPT." Cigdem's questions were (slightly edited): *If the original RPT was valid, wouldn't the client have gotten access to the resource at the resource server? Would the client ever ask for another RPT with a valid original RPT? Does it describe the case where the RPT was for one resource/scope and not expired, but the client tried to use it to access another resource/scope and failed?* What we were trying to say was that: 1. *(Client can bring no RPT and ask for one -- not a concern)* 1. *(AS can issue a new RPT A -- not a concern)* 2. Client can bring RPT A that doesn't have a permission for what it wants to do and ask for an RPT that works for what it wants to do 1. AS is allowed to reissue the existing RPT A (same RPT string), having added the relevant permissions to it 2. AS can issue a new RPT B (different RPT string), having added the relevant permissions to it 1. AS can invalidate the old RPT A that the client brought it upon this action 2. AS can retain the validity of the old RPT A that the client brought it and any of its permission(s) -- presumably ones that are still good and that the client didn't just try to exercise but found wanting The question is, do all these options truly make sense? Is it, for example, such a common pattern for an AS to invalidate all previous tokens and stuff all current permissions into the latest and greatest access token (which equates to list item 2.2.1 above) that doing anything else is insanity? Any other option would leave the client juggling multiple tokens, and having to guess which ones unlock which resources. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

Step 3 to Step 4 (client approaches RS with no token) wording
by Eve Maler 30 Dec '16

30 Dec '16

(Edited the subject line and will break up this thread into two for clarity...) Excellent point about "single authorization server", thanks, Justin! The other thing I was wondering about was: Everyone okay if we excise the other *n* instances of this explanation in the next section? As noted during our last call, now that the "normative commentary" about interfaces has largely moved to Section 1, I'd like to ensure that the messaging specifics are cleanly spelled out in the next section, with no holes and no "digressions" -- only xrefs back if we really want them. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Thu, Dec 8, 2016 at 10:03 AM, Justin Richer <jricher(a)mit.edu> wrote: > For my action item from Eve’s post, I would suggest this wording: > > Note: In step 3, the client attempts access to a protected resource with > no token, and in step 4, the resource server requests permissions on behalf > of that client at the authorization server. In order for the resource > server to know which authorization server to approach and which PAT > (representing a resource owner) and resource identifier to supply in that > request, the API being accessed by the client needs be structured in such a > way that the resource server can derive this information from the client's > token-free access attempt. Commonly, this information can be passed through > the URI, headers, or body of the client's request. Alternatively, the > entire interface could be dedicated to the use of a single resource owner > and protected by a single authorization server. > > > > > — Justin > >

2 8

Spec proposal for protected resource and scope communications and mappings ("set math")
by Eve Maler 29 Dec '16

29 Dec '16

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-stri…>?* - *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

1 1

Book Review
by John Wunderlich 23 Dec '16

23 Dec '16

For your holiday reading pleasure. This might be of interest to the Legal UMA group and some on the BSC DG. It's a review <http://www.rogerwhitson.net/?p=3501>of Benjamin Bratton’s The Stack: On Software and Sovereignty <https://www.amazon.ca/Stack-Software-Sovereignty-Studies-ebook/dp/B01D1Q44HE> John Wunderlich, BA, MBA IAPP Fellow of Information Privacy CISA, CIPM, CIPP/C, PbD Ambassador @PrivacyCDN <https://twitter.com/PrivacyCDN> & Privacist -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

1 0

Draft minutes of UMA telecon 2016-12-22
by Eve Maler 22 Dec '16

22 Dec '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-12-22 MinutesRoll call Quorum was not reached. Approve minutes Approve minutes of UMA telecon 2016-12-01 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-12-01>: tbs Logistics - This is our last meeting of the year - Refer to telecon 2016-12-01 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-12-01> minutes to see how voting/balloting process goes Regarding what to include in V2.0 work, Ishan brings up the RS's need to pass requirements for minimal authorization to the AS. This seems to be the only addition to Eve's proposed list so far for our final V2.0 work. There's support for seeking a set of WG drafts. UMA V2.0 work *Set math:* In the question of discretion applied by the RS during its permission request compared to discretion applied by the client during its initial access attempt: What's the motivation of the client? What's the motivation of the RS? Justin has proposed wording in the past that recommends requesting enough permissions for the request to succeed, which softens the previous requirement. Eve and Cigdem discussed the notion that this seems like "bad faith", since the (100% untrusted) client can only communicate one thing at this point: "I want resource X with Y scope" (or rather, some kind of resource among some set XX with YY scope). Eve notes that XACML expects the PEP to transmit a faithful representation of the application's access request to the PDP as an authorization request. What are use cases for the RS to reduce the permission request vs. adding permissions and/or scopes? Should the RS be completely dumb and send no scopes at all when it requests permission? If it didn't do this, then suddenly the client's pre-registration for some scopes A, B, C and its potential dynamic addition of scopes X, Y at RPT request time become a lot more "normative". Reminder: A "permission" is "Authorized access to a particular resource with one or more scopes." Now it's possible to request more than one permission on behalf of the client. (The formal call ended and Robert and Eve continued discussing.) Different APIs design their resource boundaries and scopes differently, so perhaps it's not a good idea to discriminate between what an RS can do with one vs. the other. Adrian had suggested earlier that it's good advice to say that the client should ask for as few scopes as possible, for least privilege reasons. The same is likely true for the RS requesting permissions. But is *less than* what the client asked for a case of least privilege? Can we park the notion of changing things drastically for now (e.g. removing the RS's current capability of requesting scopes on permissions) and come back around to it? What about this notion of equitable risk and responsibility distribution? The client, representing some RqP, which are initially 100% untrusted and seek partial trust at maximum: - Can pre-register for scopes with the AS and can dynamically request scopes on every RPT request - Can attempt access differentially on tokenless attempt #1 and RPT-bearing attempt #2 at the RS The RS, which outsources resource protection to the AS but has the right to apply "edge protection" (the "Adrian clause" but strengthened to apply to the beginning of the chain): - Is allowed to request permissions and scopes on behalf of the client that are smaller that would allow the initial access attempted by the client (Justin's proposal) - (This logic could be applied to allow "cascading authorization servers" to enable the RS's risk management vs. the RO's wishes) - ... The AS, which is accountable to the resource owner and RS for resource protection: - Is allowed to reject or partially fulfill RPT requests *AI:* Eve: Send out note with revised set math proposal. *AI:* Eve: Publish rev 10 and rev 03 for people's holiday reading pleasure. Attendees As of 20 Dec 2016, quorum is 6 of 10. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Mike, Cigdem, Sarah) 1. Domenico 2. Robert 3. Maciej 4. Eve 5. Mike 6. Sarah Non-voting participants: - Adrian - Ishan - Justin Regrets: - Cigdem - James - Andi - Sal *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2016-12-22, holiday edition (hope you can all make it!)
by Eve Maler 20 Dec '16

20 Dec '16

This is our last telecon of the year. We got only a couple of regrets from voting participants last week for this meeting -- hope we can get good representation, and raise a virtual cup of egg nog while solving lots of open issues in this last session of 2016. :-) http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-12-22 Date and Time - *Thursdays,* 9-10am PT - Skype: +99051000000481 / US +1-805-309-2350 / international lines <https://www.turbobridge.com/join.html> / web calling interface <https://panel.turbobridge.com/webcall/> / code 1782540 - Screen sharing: http://join.me/findthomas - NOTE: do not use the join.me dial-in line - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2016-12-01 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-12-01> - Logistics - This is our last meeting of the year - Refer to telecon 2016-12-01 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-12-01> minutes to see how voting/balloting process goes - UMA V2.0 workAOB - 2016 roadmap <http://kantarainitiative.org/confluence/display/uma/UMA+Roadmap+for+2016> - Core is up to 09 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-09.html> and RReg is up to 02 <http://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-02.html> (no changes from last meeting) - Dynamic swimlane <http://www.websequencediagrams.com/files/render?link=Pu0sP0Oe2kjKc2WgdKZd> - Complete set math decisions *today*: see email proposal <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/QVr9Egbfv…> - Proposal for "the rest of the issues to consider/take out of the backlog"; let's decide the final list by our first meeting in January and figure out our completion roadmap: - Use Cases for FHIR Security Authorization with Patient Consent <http://kantarainitiative.org/confluence/download/attachments/17760302/Use%2…> ("cascading authorization servers") - Shoebox endpoint/"audit whether RS gave access per permissions" (issues 24 <https://github.com/KantaraInitiative/wg-uma/issues/24> , 224 <https://github.com/KantaraInitiative/wg-uma/issues/224>) - Hashed claims discovery (issue 254 <https://github.com/KantaraInitiative/wg-uma/issues/254>) - Issues that came up in editing: - What is the proper way to complete the specification of the UMA grant? e.g., how do the client's credentials actually get used in the flow? - Remove policy-specific resource/scope description properties from RReg and add as extensions in Core? - claim_token_profiles_supported: Provide real profiles for OIDC and maybe SAML? - What to do with the extensibility profiles? - Need to have IANA registry entries for both old uma-configuration and uma2-configuration? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Health wearables + big data collection = bad news for your privacy
by John Wunderlich 19 Dec '16

19 Dec '16

http://mashable.com/2016/12/16/wearable-health-data-privacy-report/#E7h_hbn… -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

1 0

Notes from UMA telecon 2016-12-115
by Eve Maler 15 Dec '16

15 Dec '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-12-15 MinutesRoll call Quorum was not reached. Critical mass was reached. Approve minutes Approve minutes of UMA telecon 2016-12-01 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-12-01>: Deferred. Logistics - *Dec 16:* Legal subgroup meets as usual - *Dec 22:* meet as usual; RSVP – Dec 23: no Legal subgroup meeting Who's not available for next Thursday? Andi, Cigdem, François. Work on UMA.next issues * Use Cases for FHIR Security Authorization with Patient Consent <http://kantarainitiative.org/confluence/download/attachments/17760302/Use%2…> (aka "cascading OAuth"):* Mike Davis is the security architect for the Dept of Veterans Affairs. Kathleen, Mohammad, and Tony are on the security architecture team and have been working on enabling patient choice. What they'll show is what they've been working on for the HIMSS '17 conference. They've developed a profile that integrates patient and enterprise access control systems. Kathleen notes that Adrian has articulated the "multiple portals problem" in the past. The Word document linked from above "cascades" authorization decisions. This version of the doc makes both parts OAuth-based, where the token expires within a period of time. They had demonstrated UMA in 2015. This next level is where there are multiple authorities governing access – different sources of policy. The VA is a US federal agency. As such, it makes its IP available freely. The notion is that there are at least two AS's. There is an external third-party authorization server connect to a consent directive management system. A "consent directive" is an authorization policy stored in a FHIR server in FHIR-dictated form. That's not UMA, but a FHIR server has the capability to query that in order to enforce a decision. The flow starts with a client requesting some data. The client is redirected, or is hinted to go to the local AS, where it asks for an RPT. At this point, the overarching policies in the organization are checked. It's determined whether the patient's consent is needed. If so, a second hint is produced after the token is issued, and it proceeds to get a "patient consent token", which here is called an RPT. Verification and introspection later needs to take place, with each relevant AS. Data labeling and transformation subsequently takes place, which is not related to UMA. They have a beta implementation of this right now. Adrian: What is the resource that is being registered? There's the HEART profile, and the Argonaut profile. These talk about what you're supposed to register in terms of the permission structure. What goes into the scope portion is basically the security labels. If you're only supposed to have non-confidential data, that goes in. The resource ID portion, according to the spirit of HEART and other profiles, that gets registered is Alice/Medication, followed by the necessary clearances. It's a standard UMA server. What connects the AS's is the patient identity. This allows finding the relevant policies that the patient has filed. Eve: If these are UMA AS's, are these all RPTs, and are the hints all need_info hints? This is still classic UMA, and this is all being done with permission registration (which would now be called requesting permissions on behalf of the client), only having a different party making the request. Eve suggests that a next step could be a detailed message flow for the swimlane and numbered list on pages 11-12 of the Word document. Colin: Encourages looking at Consent Receipts as well. Eve: Is this a way for an RS to constrain what an RO can share so as to control its liability in a technical, vs. just legal fashion? Kathleen: Yes, but it's also a way to ensure central patient policy *information* management of their own policies per se, not just have a central administration point. Next steps: Decide if we want to make this a part of UMA2. *Set math:* Decision 1: What to do when the client has pre-registered parsimoniously but the rest of the scope ecosystem has been more generous? 1. Client pre-registers for scopes at the AS (dynamically, or out of band, or updates a previous registration, etc.) 2. Client attempts access, nominally "using some scope" by virtue of making an API call 3. RS requests one or more permissions on the client's behalf 4. Client requests an RPT, possibly explicitly requesting one or more scopes 5. (At some point) RO configures the AS with some policy conditions, which would ultimately grant the client (on the RqP's behalf) some permissions with some scopes 6. AS grants the client (on the RqP's behalf) permissions with some scopes 1a. *What if, in #1, client registers for only A, B, C, but in #3 and/or #5, the AS gets the idea that it's supposed to grant a permission that involves scope X?* 1b. *What if (given the RO/RS context above), in #4, client requests X even though it only registered for A, B, C?* Note that there is no requirement that a client has to pre-register for scopes. And there's no hard semantic for scope pre-registration, so the act doesn't necessarily mean "I can handle only these scopes". And we can fast see the day coming where scope pre-registration becomes so awkward because of its implicit association with only some resources in many OAuth-protected APIs that *resource* pre-registration will become available (scopes are *explicitly* associated with specific resources in UMA already). Eve had tried a "least privilege" strawman in email was to mask out scope X from any client that didn't pre-register for it. But we can't seem to think of a reason to deny granting that permission. Mike S could imagine a really paranoid trust model that would have the AS deny granting it, though. So do we want to be deterministic, or continue to allow the AS to use discretion? E.g., see the wording in Core V1.0.1 Sec 3.5.2 <https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html#authorizati…> about partial fulfillment of scopes vs. rejection. Ishan: At least coming up with a maximal list of scopes and saying it's okay to mask it or not would be *more*deterministic. If an UMA AS is also an OIDC OP, would conflicts arise? We don't want that. (The WG call officially ended, and Eve Cigdem continued.) 1c. *What discretion or determinism should there be around #3?* In Core V1.0.1 Sec 3.2 <https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html#register-pe…>, we currently say that the RS has to request a permission that at least suffices for what the client attempted. Of course, there is even some discretion in figuring this out. But it still seems practical to continue requiring the RS to request something minimally sufficing, and then – because it alone is authoritative for resource boundary management and complexity – enabling requesting of multiple permissions (that is, multiple resources) as required or desired, along with multiple scopes on those resources, based on its judgment as we have been saying all along. It's a matter not only of resource boundary management but also of stinginess/permissiveness. Client pre-registration of scopes seems so discretionary and so unclear as to its purpose that we think it shouldn't be relied on as any guidance towards UMA normative text. Maybe in future, it *might* be more meaningful if an RS could register its resources for protection in a way that allows clients to pre-register for *resources with scopes* (generically, outside of an RO context). But for now, this isn't possible. At that later time, we could extend UMA to allow clients to request specific resources when asking for an RPT in #4. We're not willing to define this mechanism as an extension to dynamic client registration, or as an OOB mechanism. (Or are we? A way to do it either dynamically or OOB would be to use something like the optional RReg type property (see RSR V1.01. Sec 2.2.1 <https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0_1.html#c…>), or an extension scopetype property or whatever, to convey the generic resource type you mean. From there, you could drill down on the scopes you mean, with an array. Etc. A client could use an object that leverages all this stuff to pre-register in some fashion for the specific scopes it can handle. Probably way too ambitious for UMA2, but there's an obvious path for how to extend it if someone wants to do this.) The way we're heading in our logic, #4 – the client requesting scopes – is something that's kind of unattractive because of this scope/resource skew. However, we had made this decision to add it because OAuth allows it, and because of the presumption that the client "knows its own mind", has to know the API, and therefore has to code to the scopes. Should we consider the above analysis to be sufficient new information to make us reconsider the new functionality we've added (client requesting scopes at the token endpoint, and the associated invalid_scope error)? Or should we consider it directly relevant to the AS's calculation, as in *1b* above? It's a kind of dynamic addition to whatever is in the permission ticket. The client – presumably acting on behalf of the RqP no matter whether the RqP is human or enterprise – has two opportunities to express the latter's wishes, or perhaps three. In #1, pre-registration for scopes is an act that takes place outside of any RqP's context, so that has nothing to do with the RqP, so let's not count that. In #2, the client actually attempts access, so that's a direct expression of a wish for access of a particular kind to something, directly at the RS itself. So we should take that very seriously (and do, according to the discussion above). In #4, the client currently has the ability to request scopes, a la OAuth, though we haven't been super-clear about the semantic of such a request: is it on the RqP's behalf, or is it on the client's own behalf, or what? Our previous discussion leading to this decision leans more on the side of the client's own behalf, connected somewhat to things like pre-registration. So, how much do we actually care – in set math reality – what the client requests at token-endpoint run time? Is it more important than pre-registration for scopes, and if so, by how much? *AI:* Eve and Cigdem: Draft sample spec text for "set math", with a choice point between client scope request effect options. Attendees As of 3 Oct 2016, quorum is 6 of 11. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Cigdem, Sarah) 1. Andi 2. Eve 3. Mike S 4. Cigdem 5. Sarah Non-voting participants: - Andrew - Ishan - Adrian - François - Kathleen - Scott F - Mike Davis - Jin Guests: - Tony Mallia - Colin Lurking - Mohammad Jafari Regrets: - Sal - James - Domenico *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0