- WG-UMA - mailman.kantarainitiative.org

Ad hoc meeting next Tuesday, 8:30-10am Pacific
by Eve Maler 02 Feb '17

02 Feb '17

I've already created a calendar entry and invited all the same people who get invitations to the regular meetings. If you're a voting participant, don't sweat quorum, as this meeting won't count towards quorum expectations. We'll primarily be discussing the set math issues in priority order (as you'll see in the meeting minutes I'll send out in a moment). If we miraculously get through those, we can tackle other issues... *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2017-02-02 (90 minutes)
by Eve Maler 01 Feb '17

01 Feb '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-02-02 Date and Time - *Thursdays,* *special meeting times through Feb 9: 8:30-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 2017-01-26 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-26> - Logistics: - Next week is our last scheduled 90-minute meeting; extend? - No meeting Feb 16 because of RSAC - UMA V2.0 work - 2016 roadmap <http://kantarainitiative.org/confluence/display/uma/UMA+Roadmap+for+2016> / GitHub issues for V2.0 <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…> (all issues to be kept here for the duration!) / dynamic swimlane <http://www.websequencediagrams.com/files/render?link=Pu0sP0Oe2kjKc2WgdKZd> - Core is up to 13 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-13.html> (no change) and RReg is up to 05 <http://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-05.html> (no change); expect Core 14 before the call - 266 <https://github.com/KantaraInitiative/wg-uma/issues/266>: Set math / resource and scope ecosystem - Discuss and clear the RReg issues - 269 <https://github.com/KantaraInitiative/wg-uma/issues/269>, 270 <https://github.com/KantaraInitiative/wg-uma/issues/270>, 271 <https://github.com/KantaraInitiative/wg-uma/issues/271>, 272 <https://github.com/KantaraInitiative/wg-uma/issues/272>, 273 <https://github.com/KantaraInitiative/wg-uma/issues/273>, 276 <https://github.com/KantaraInitiative/wg-uma/issues/276>, 277 <https://github.com/KantaraInitiative/wg-uma/issues/277> - 260 <https://github.com/KantaraInitiative/wg-uma/issues/260>: Cascading authorization servers - Discuss Mohammed's input - Decide next steps - Claim token profiling: 263 <https://github.com/KantaraInitiative/wg-uma/issues/263>: Claim token profiling / 119 <https://github.com/KantaraInitiative/wg-uma/issues/119>: Create an IANA registry for URIs that stand for claim token formats - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Default-deny
by James Phillpotts 01 Feb '17

01 Feb '17

Hi all, Thanks for the reminder to send this email Eve! ;) The paragraph in question is: The authorization server MUST use a default-deny authorization assessment model in adding permissions to RPTs, that is, "everything that is not expressly allowed is forbidden" for resources for which resource servers have requested access permission on behalf of clients. Exercise caution in implementing default-deny because corner cases can inadvertently result in default-permit behavior. For example, it is insufficient simply to assume that all resources have some non-zero set of claims required for access, and then accept an empty set of supplied claims as sufficient for access. I'm not convinced that this paragraph is really very useful, but that may be because it isn't clear at what level the 'deny' is relating to in this context - is it on a per-resource, per-scope, or an RPT level? If per-resource, I think this is a reasonable thing to express, but I'm not sure the paragraph does a particularly good job of it. If per-scope, does this only apply to additional scopes requested by the client? If RPT, then I don't think the idea is correct, as the RPT shouldn't be denied based on the outcome of a particular policy for a particular resource. On one of the calls I thought someone had mentioned that the RPT should only be granted if all of the scopes requested in the permission ticket were able to be granted, but I think it should be perfectly reasonable to grant a subset - e.g. if ticket requests view, edit for resource A and view for resource B but all that can be granted is view for A, then that is a perfectly reasonable response? This was partly triggered by Mike's suggestion of patterned URIs, where I was thinking about the RS wants *either* view on A, view on B or view on C, because it knows that the actual requested URL is covered by all 3 of those registered resource sets (although as per other email, I wouldn't like that to be a pattern). Sorry if this is slightly rambling. Cheers, James

4 16

The UMA resource and scope ecosystem: goals and appetite
by Eve Maler 01 Feb '17

01 Feb '17

I've been trying to think of why we're struggling so much with the scope challenge. I put together the following multi-part swimlane as a discussion tool: https://www.websequencediagrams.com/files/render?link=0XEvf__PVcpdxGGsQb38 Part 1 illustrates the "UMA1" path through the current spec, where a "dumb" client can get by just fine without asking for any scopes and just accepting the context that's in the permission ticket. The RS gets to dictate whatever resource IDs and their scopes are to be considered, they get associated with the permission ticket, and this flow from AS to RS to client and then back to AS. The thinking in UMA1 was that, since it's party-to-party sharing and "user-managed access", whatever is in what we now call *RequestedScopes* is at the mercy of the calculated result of *CandidateGrantedScopes*; any access a client actually attempts that's allowed by policy would ultimately be granted, the whole thing generally acting in a minimal disclosure fashion. Part 2 illustrates (at a high level) the "OAuth" path we've been working to design into the spec, where a "smart enough" client can request scopes at the token endpoint (if it's been smart enough to pre-register for them first). We tend to get stuck, I think, because the AS and RS are privy to information the client doesn't have and seems to need -- mostly a) which scopes were granted, but also b) which "resources in a generic sense" the requested and granted scopes belong to. Unfortunately, a resource ID represents a resource that's bound to its resource owner context by virtue of the RReg mechanism; we don't currently have a way to give the client the rest of the resource information without that context. (I've been looking at this I-D <https://tools.ietf.org/html/draft-jones-oauth-resource-metadata-01> and can't tell if it applies or not.) Part 3 assumes a putative way to pass around that information, which I'm calling "resource types" for now. I guess my questions are, How valuable do we think it is for a client to request scopes while asking for an RPT, and if it's really valuable, how much effort should we put into solving the problem "correctly" and "thoroughly" in the context of UMA and the goals of the current release? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Issue 260 Cascading authorization servers
by Kathleen Connor 30 Jan '17

30 Jan '17

Hi Everyone, Mohammad intended to response to the minutes from UMA telecon 2017-01-19 about Issue 260 https://github.com/KantaraInitiative/wg-uma/issues/260 but apparently, his message was not published [shown below]. So I am resending since I agree with him that issues raised in the WG seem to be based on policy that the example use of Cascading OAuth that Mohammad presented exemplified. Other policies would make very different rules about which AS is "on first". I know that there's no time until late in February to have further discussions on our request that UMA WG consider this proposed profile. I've requested time at the next available agenda slot. Thank you for this first round of discussion. -K * Putting the RS in charge of orchestrating the cascaded authorization flow will involve the RS in making authorization decisions and handling authorization logic, including policy processing. The RS will have to decide what ASes need to be consulted and how to combine their decisions. Such arbitration must inevitably be based on some policy rules and this will end up putting the burden of authorization and policy processing on the RS, which is contrary to separation of concerns, and also defeats one of the primary purposes of UMA, which as I understand, is to take the burden of policy processing off the shoulders of the RS. In other words, let's draw a rectangle around that component in the RS which is in charge of this orchestration and handling these authorization decisions and call it the "Downstream AS". * The question of who controls each AS is a matter of policy and orthogonal to this design. The downstream AS is the eventual arbiter that should decide for any given access request, what ASes must be consulted and how their decisions must be reconciled and combined. Moreover, in the process of combining introspections from the upstream ASes, the downstream AS has the authority augment/abridge the scope/permission set as well. This provides the capability to enforce various kinds of policy combining strategies. For instance, in your example of the so called "data blocking", if the organizational policies override patient consent, then the downstream AS should be configured with the combining policy that combines the decisions that way. Likewise, if the patient consent overrides, the respective combining policy can be stated at the downstream AS. Other combining logics (e.g. simple AND/OR, majority vote, and more sophisticated combining logic with respect to scopes/permissions) can be implemented in a similar vein (*). In all of these cases, the design is the same and thus is agnostic to the particular policy/configuration -be it authorization policy, or decision combining policy. * I think leaving the cascaded authorization logic to out-of-band protocols, is outside the scope of this discussion and somehow beside the point. We are in a standard WG because to standardize the flow where multiple policy authorities host their own respective ASes which is a generalization of the basic UMA use-case. Of course, this, or for that matter, even the main authorization use-case of UMA, can all be considered out of band but that's not the point. Regards, Mohammad (*) To clarify a technical detail, I'm aware that if any of the upstream RPTs refuse to issue the RPT altogether (a 403) then the flow halts and this means a disjunctive (OR) combining can't take place. However, this can be fixed by having the upstream ASes issue an RPT with an empty scope/permission set when they intend to deny an access so that the flow can move on. *260 <https://github.com/KantaraInitiative/wg-uma/issues/260>: Cascading authorization servers:* Recall that the use case (from the FHIR world) is that the RS has "edge authorization" it needs to perform, which it has ensconced in enterprise policies in its own authorization server. This is a way to have the "Adrian clause" reified in RPTs, and the client/RqP meet multiple sets of policy conditions, all the way. This connects to the shoebox question if you can get the RS to report what they've done. In the swimlane, the "downstream AS" is Alice's and the "upstream AS" (and any further upstream ones) belongs to the RS. So, in a way, this has positives and negatives: the incentives change because on the one hand an RS gets a lot more formal and dynamic control of liability, but on the other, it can control much more strongly what Alice gets to share, possibly enabling "data blocking" (a phrase from the health world). This has been done as an extension already, so it could remain an extension for now. It has "set math" implications, because it introduces another set. Eve's observations about the flow: - AS needs to know about the other AS because it's a client of the permission request endpoint - Client needs credentials for the upstream AS(s) too - Client needs to keep an "AS stack" and to hold multiple RPTs for "that resource" (whatever that means to the client) - (George added:) There's new set math that each downstream AS has to calculate Kathleen Connor VHA Security Architecture - Framework Engineering (Edmond Scientific Company) HL7 Security and Financial Management Cochair Office - 360 357 3536 [Primary] Cell - 360 480 7599

1 0

UMA RequestedScopes Venn representation
by Domenico Catalano 26 Jan '17

26 Jan '17

Hi, Here is a Venn representation of the RequestedScopes set, based on the following formula: RequestedScopes = union ( intersection (ClientRequested, ClientRegistered), PermissionTicket). RequestedScopes = C ∪ (A ∩ B) = (C ∪ A) ∩ (C ∪ B) I hope it’s accurate! Thanks Domenico

2 1

Draft minutes of UMA telecon 2017-01-26
by Eve Maler 26 Jan '17

26 Jan '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-26 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2017-01-19 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-19>: APPROVED. Logistics - Idea: Vote on WG draft on Feb 9 and open it up to a "last call" period for about four weeks? We need burn-in/beta time, it seems - No meeting Feb 16 because of RSAC We like the idea of a Last Call period to shake out things. Several of us are doing some incremental implementation work. We can never make people look, but we can do our best to draw attention. So our new plan of record is to publish a WG draft by Feb 9. UMA V2.0 work *266 <https://github.com/KantaraInitiative/wg-uma/issues/266>: Set math:* Typo: "RequestedScopes contains view, print, and print" should obviously be "RequestedScopes contains view, print, and download". The list discussion, netted out, is: Should the AS be able to issue fewer scopes than the RS put into the permission ticket, or not? And if so, should it be able to do so on a per-resource basis? Since OAuth happily tells the client what scopes were issued, why can't we do the same? Can we do this and not share the resource IDs? We have seen the resource IDs as privacy-sensitive personal information. It's unfortunate that the OAuth architecture overall hasn't yet had a way to identify specific resources. Eve had put this language in rev 13: "The client attempts what the resource server interprets as view access to rsid_1. The resource server chooses to request view and print scopes on its behalf". (Should be "...to request view and print scopes for rsid_1...") This is hinting at what the RS is authoritative for: interpretation of the API call and choices about the extent of the permission request. This needs to be discussed in a proper place in the spec. All this probably belongs in Sec 1.3 somewhere. The client should be discussed here too! George proposes, and James supports, that *PermissionTicket* scopes MUST be met per resource, which ties the AS's hands in terms of what it rejects and incentivizes the RS in terms of requesting "too much". Park this for a moment. This would change the Venn diagram, and the decision on the issue below would change the outcome of this discussion. --- James proposes having the AS report rejected scopes in the token introspection object so that the RS can decide if it wants to keep trying (that is, requesting permissions on behalf of the client again and again). But what if the RS is tired of dealing with looping? We do have a clause that says "The recipient of each request message SHOULD respond unless it detects a security concern, such as a suspected denial of service attack that can be mitigated by rate limiting." Cigdem says: "I agree with the second option. If RS records what permissions it asked for the client, and then checks it against received RPT, it can diff what is denied. (And the missing permissions in the RPT was a result of RS being permissive and AS granting only resources that fully match RS’s permission, RS can try again)." A more informative token introspection object allows the RS to craft a permission request that is responsive to what the requesting party/client is actually seeking access to, while adhering to minimum disclosure principles if it wants to. Could we still have the concept of the client including a previous RPT on its request? It appears so, because all the scopes in such an RPT are associated with resources. Because the client doesn't know how its tokens relate to its successful accesses, its only choice is to try and send all of its previous RPTs. But it would only have one because it would have had to invalidate each last one. The idea is that the AS would provide the last-issued ticket, broken out with the state it had kept associated with it. AI: James: Send concrete example of how to solve this problem. *Other:* The "easy issues" will be resolved as noted: - 264 <https://github.com/KantaraInitiative/wg-uma/issues/264>: Authentication-related error details (will close with only editorial/example text) - Shoebox: Will remove V2.0 label from 246 <https://github.com/KantaraInitiative/wg-uma/issues/246>, 245 <https://github.com/KantaraInitiative/wg-uma/issues/245>, 224 <https://github.com/KantaraInitiative/wg-uma/issues/224>, 63 <https://github.com/KantaraInitiative/wg-uma/issues/63>, 24 <https://github.com/KantaraInitiative/wg-uma/issues/24> and make them a parallel activity *Spec instructions:* - Fix typo shown above - Fix permission request language shown above - "Easy issues" Attendees As of 19 Jan 2017 (post-meeting), quorum is 5 of 8. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem, Sarah) 1. Domenico 2. Sal 3. Maciej 4. Eve 5. Mike 6. Cigdem 7. Sarah Non-voting participants: - James - George - Justin - Ishan - Kathleen - Jin Regrets: - JohnW - Andi *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

276: Scope string: "friendly name" and "identifier" the same: do they need to be split?
by Eve Maler 25 Jan '17

25 Jan '17

This message discusses an issue not brought up yet in our meetings. Please read and weigh in (even with a +1, if you agree...) by *Tuesday* if possible!) 276 <https://github.com/KantaraInitiative/wg-uma/issues/276>: Scope string: "friendly name" and "identifier" the same: do they need to be split? ==== In the ad hoc discussion post-UMA telecon 2017-01-19 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-19>, we had a discussion that I don't think I captured in the notes: While the "name" property for a scope description defines itself (Sec 2.1.1 <https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-04.html#ac…> in RReg 2.0 rev 04) as being a human-readable string, that leaves it without a separate (if desired) machine-readable scope string. In implementations it's been treated primarily as the latter and displayed also as the former, so effectively serving as both. In the case of resources, these two concepts are naturally split because the AS gives back an identifier. ==== Note that the current "name" property is OPTIONAL, and that this is part of the scope description document that the AS resolves if it's gotten a URI from the RS (keep in mind the email sent earlier today about issue 269!). In this case, the URI could simply have served as the machine-readable name. Here are the options I can think of. (Let me know if I missed any.) 1. Do nothing. 2. Add a new bit of description to the existing "name" property to say that it's meant to serve as the machine-readable name as well. 3. Add a "scope_id" property of some kind. 4. Change the "name" property to have the machine-readable name semantic, and add a "friendly_name" property of some kind. ==== Here is my proposal: *Option 1*. Rationale: - I believe it's correct to interpret the URI as the "scope identifier". If we need to say so in the spec, then we can. - The "name" property for a scope has, and should have, the same role as the "name" property for a resource. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

3 3

Agenda for UMA telecon 2017-01-26 (90 minutes)
by Eve Maler 25 Jan '17

25 Jan '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-26 Date and Time - *Thursdays,* *special meeting times through Feb 9: 8:30-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 2017-01-19 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-19> - Logistics: - Idea: Vote on WG draft on Feb 9 and open it up to a "last call" period for about four weeks? We need burn-in/beta time, it seems - No meeting Feb 16 because of RSAC - UMA V2.0 work - 2016 roadmap <http://kantarainitiative.org/confluence/display/uma/UMA+Roadmap+for+2016> / GitHub issues for V2.0 <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…> (all issues to be kept here for the duration!) / dynamic swimlane <http://www.websequencediagrams.com/files/render?link=Pu0sP0Oe2kjKc2WgdKZd> - Core is up to 13 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-13.html> (updated) and RReg is up to 05 <http://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-05.html> (updated) - Core: mostly authorization assessment <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-13.html#authorizatio…> and editorial changes; "claim token" also now defined (closing #256) - RReg: #276 trial text for the scope property - 266 <https://github.com/KantaraInitiative/wg-uma/issues/266>: Set math - Critique new wording and spec structure (Sec 1.4.2 / Sec 3.6.5) - What should be done about previous RPTs on requests – if they're allowed, why, what does the AS do in return, and what does the client do with its various RPTs? - How (and where in the spec) should the RS document its permission request practices so the client has an idea what's in its RPTs? - Are our "notes" for default-deny and everything else as they should be? - Can we close the issue after this? - Discuss and clear the RReg issues - 269 <https://github.com/KantaraInitiative/wg-uma/issues/269>, 270 <https://github.com/KantaraInitiative/wg-uma/issues/270>, 271 <https://github.com/KantaraInitiative/wg-uma/issues/271>, 272 <https://github.com/KantaraInitiative/wg-uma/issues/272>, 273 <https://github.com/KantaraInitiative/wg-uma/issues/273>, 276 <https://github.com/KantaraInitiative/wg-uma/issues/276>, 277 <https://github.com/KantaraInitiative/wg-uma/issues/277> - 260 <https://github.com/KantaraInitiative/wg-uma/issues/260>: Cascading authorization servers - Discuss Mohammed's input - Decide next steps - Claim token profiling: 263 <https://github.com/KantaraInitiative/wg-uma/issues/263>: Claim token profiling / 119 <https://github.com/KantaraInitiative/wg-uma/issues/119>: Create an IANA registry for URIs that stand for claim token formats - "Easy issues": - 264 <https://github.com/KantaraInitiative/wg-uma/issues/264>: Authentication-related error details (will close with only editorial/example text) - Shoebox: Will remove V2.0 label from 246 <https://github.com/KantaraInitiative/wg-uma/issues/246>, 245 <https://github.com/KantaraInitiative/wg-uma/issues/245>, 224 <https://github.com/KantaraInitiative/wg-uma/issues/224>, 63 <https://github.com/KantaraInitiative/wg-uma/issues/63>, 24 <https://github.com/KantaraInitiative/wg-uma/issues/24> and make them a parallel activity - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

More set math / Default-deny / Previous RPTs
by Eve Maler 25 Jan '17

25 Jan '17

Domenico created a cool Venn diagram (huzzah!) showing what we've decided for set math thus far. I've attached it below. I believe it's accurate as far as the client-requested scopes, client-registered scopes, and permission ticket go. When it comes to allowed scopes and granted scopes, these unfortunately may be impossible to show in any diagram because the policy conditions that have been configured into the AS are "invisible", and thus the allowed scopes could fall wholly within, fall partially with, or fall totally outside the requested scopes. This means the granted scopes are impossible to show as well. (Unless we show each option in turn, or something.) James and I were talking earlier about how this connects to the paragraph about "default-deny". I'll let James say more about it for further email discussion. Finally, how shall we account for the presence of a previous RPT on a client's request to the token endpoint? In the call, we got as far as saying "The AS would have to find all the claims relevant to having met all the scopes in that RPT. The task in email now is to look at when the previous RPT a) did and b) didn't contain resource IDs that were in the current request for access." Let *PreviousRPT* stand for all the scopes in an RPT present on a client's request at the token endpoint. Presumably, *the reason the client included this RPT* is because *the token failed* when it was trying to accomplish some access over at the RS and *the client would like the AS to upgrade that token, please*. Is that correct? It could have been that the token already had some scope (say, *read*) but didn't have some other scope (say, *write*) for resource ID *123* (say, a file), or it had all permissions for read resource *123* (the file) but no read access for resource *456* (its "enclosing" folder). So the RPT might have permissions *123:read* but not *123:read,write*, or it might have *123:read,write* but not *456:read*. Importantly, it might also have collected a bunch of other stuff that's not relevant to what the client is currently seeking, like *6317:foo,bar,baz* and *83452:man,from,uncle*. Remember that these individual permissions may have individual expiration timestamps on them. What's clear is that *RequestedScopes* as currently defined (whether coming through client reg/req action or through RS permission request action) could have, say, *123:write* or *456:read* in it in order to give the client what it needs right now. If *PreviousRPT* has permission structures in it for *123* and *456*, we can probably say something sensible. What's really not clear yet is: What should happen to the *6317:foo,bar,baz* and *83452:man,from,uncle* permission structures in *PreviousRPT*? Okay, that's an opening bid... What else? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

3 6