- WG-UMA - mailman.kantarainitiative.org

Issue #275: The need_info response doesn't say that the ticket is REQUIRED
by Eve Maler 12 Feb '17

12 Feb '17

This one needs discussion, and I'd rather avoid telecon time on it if possible, so let's please discuss it here: https://github.com/KantaraInitiative/wg-uma/issues/275 There are three problems. - The structural problem is that the error_details structure is always optional, but that's where ticket lives. This could be fixed by moving ticket just outside of error_details. - The spec text problem is that it's underspecified when ticket is supposed to appear. It MUST appear when the AS responds with need_info, and it MUST NOT appear otherwise. - The example problem is that we've got a need_info example that doesn't show a ticket in it. That's easily fixed once we're certain how to fix the other two. Any disagreement/discussion on any of this? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Issue #279: Ticket parameter from the AS on redirecting the RqP back to the client
by Eve Maler 11 Feb '17

11 Feb '17

I thought I'd draw your attention to this new-ish issue: https://github.com/KantaraInitiative/wg-uma/issues/279 We say the ticket parameter is OPTIONAL, but, rather, I think it should be REQUIRED on some responses and it MUST be absent on others. Can I get a sanity check on this? If it's an easy one, I can take care of it in rev 15. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Issue #278: Clients, credentials, client types, and security considerations
by Eve Maler 11 Feb '17

11 Feb '17

https://github.com/KantaraInitiative/wg-uma/issues/278 Because the AS-client (and RqP) relationship is now covered entirely by the definition of the UMA grant, we have removed the last vestigial discussion of client credentials with the rationale that OAuth covers everything you need to know about client identity/credentials/authentication/types. If you think we need to add any language related to this back to Core, speak now. Otherwise, I'll plan to close this issue with no further action by *Monday, February 20*. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

RSVP for Salt House UMAnitarian drinks get-together next Thursday ~6pm
by Eve Maler 11 Feb '17

11 Feb '17

I am going to make reservations to be sure we can get in. The location is Salt House, 545 Mission St, San Francisco, CA <http://salthousesf.com>. It looks like there's still room there at the moment, but I'd like to do this by *first thing Monday morning* to be sure we get what we want. Can people please respond (or ping me in Skype or whatever) as soon as you can, and let me know if you plan to come by at 6-ish vs. much later than that (say, 6:30pm+)? I will report back on this thread with reservation details. Thank you! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2017-02-09
by Eve Maler 10 Feb '17

10 Feb '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-02-09 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2017-01-26 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-26> and 2017-02-02 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-02-02>: APPROVED. Logistics - No meeting Feb 16 because of RSAC - This week is our last scheduled 90-minute meeting; plans for Feb 23, Mar 2? Interest in ad hoc work Feb 21/22? - At RSAC, Kantara member/IDESG cocktail party on Thursday? No-host drinks somewhere? *AI:* Eve: Schedule 90-minute meetings out through Mar 2, and propose an ad hoc on Tuesday Feb 21, hopefully at the same bat time. *UMAnitarian no-host drinks get-together* at Salt House, 545 Mission St, Thursday evening, 6pm+! Drop Eve a line if you think you can make it, or dm or email her that day/evening. UMA V2.0 work Example doc for permission requests <https://docs.google.com/document/d/1jZ1Hua2jM5x4lcpN9URaAv9nGuP_d0hX54a_H5V…>: We worked through this doc and had lots of conclusions. See that doc for spec instructions. Previous RPT: - Is this a super token? All rsid:scope <http://rsidscope/> tuples are continually added (and expired) - Is this a single token per RqP at the client? Does it also need to be bound to the RS? - Are super-token's a good idea? Do we want to promote them? - Motivation? - reduce coding complexity for the client? - reduce user experience complexity for the user? - i.e. the user doesn't have to keep providing the same claims over and over - Can we get the same behavior (improved user experience) for the user by using the PCT? - If we do want to keep the ability to add a previous RPT to a request, what is the effect on authorization assessment? - Does this effect change in the presence of a PCT on the request? James has weighed in in favor of a single RPT because of the burden, otherwise, on multi-user clients to manage potentially tens of millions of tokens without knowing which one works for which resource. A client can't provide multiple tokens to a resource to see which one works. If you want stateless tokens, you need to keep state in the token. It could be made efficient in various ways, but does it provide an incentive to go stateful instead? Even if the client provides a previous RPT, the AS still has the choice to hand the client a very session-specific token in response. There are various TTL strategies possible. What are the right strategies to simplify client developer logic? We keep dancing around informing the client more precisely what's in the token or what went on between the AS and RS. So far we haven't added anything to the UMA flow to do it. Another way to do it, potentially, is say: Client, if you have a way to introspect the token, go ahead. Is that tenable? (Justin's rant on OIDC's ID "tokens" not being tokens but rather assertions is somewhere in here <https://oauth.net/articles/authentication/>.) Revealing raw permission ticket contents doesn't seem smart because the client has no context to understand *requested* permissions if they go outside the access attempt. Could informing the client about *actually granted* scopes be a middle ground? If you pass in a previous RPT and the token was upgraded, you get an extra Boolean property in the response saying "yes, you were upgraded". If the property is empty, then the client knows it got a new one. In UMA1, the previous RPT had a role that sort of covered both client coding complexity (managing fewer tokens) and RqP experience complexity. In UMA2, now that clients can request scopes and AATs have been supplanted by PCTs, the previous RPT is meant for the former purpose and the PCT is meant for the latter. So how should authorization assessment be affected by both? *Spec instructions:* 1. The PCT, if present, is part of the claims and other information in evidence, as appropriate, in #2 (noting the temporal nature of this information and the opportunity to update it through claims collection). We already have language for this but *we probably need to add a warning about the possibility of out-of-date info getting updated*. 2. *After the assessment, if the result is to issue an RPT, and a previous RPT was on the request, and the AS decides to upgrade it, then add/merge the previous RPT with the CandidateGrantedScopes.* *Add guidance around the process of the AS deciding to issue upgraded tokens vs. not (the AS should pick one model vs. another), and the client having expectations of which one.* 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: - George - Justin - Thomas - Mohammad Regrets: - James *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 2

set-math topics / questions
by George Fletcher 08 Feb '17

08 Feb '17

Here are some topics and questions after thinking about our recent set-math conversations and collaborating with Eve. I think there a few different areas we need to resolve: 1. PreviousRPT - Is this a super token? All rsid:scope tuples are continually added (and expired) - Is this a single token per RqP at the client? Does it also need to be bound to the RS? - Are super-token's a good idea? Do we want to promote them? - Motivation? - reduce coding complexity for the client? - reduce user experience complexity for the user? - i.e. the user doesn't have to keep providing the same claims over and over - Can we get the same behavior (improved user experience) for the user by using the PCT? - If we do want to keep the ability to add a previous RPT to a request, what is the effect on authorization assessment? - Does this effect change in the presence of a PCT on the request? 2. Partial results - Why would the client pre-register for scopes? How does it choose? - How does the client choose what to attempt access to (what API call)? Does it think in terms of scopes at this point? - Note: It attempts access both with and without an RPT. The RPT may or may not be sufficient. It currently doesn't know. - Why would the RS ever *want* to request more, different, or fewer permissions than correspond to the client's access attempt? - Why would the RS ever be *forced* to request more, different, or fewer permissions than correspond to the client's access attempt? - Why would the client request scopes at RPT request time? How does it choose? - Should the AS consider any of the *RequestedScopes* "privileged" such that if they make it to *CandidateGrantedScopes*, it has to grant them (these are the partial results that succeeded)? - Should the AS inform the client about RPT issuance results, say, scopes granted, scopes denied, fact of partial results, etc.? - What to do when the RS (and/or client) requests more than is absolutely necessary for the initial access request? - Is the RS responsible for determining what is "absolutely necessary"? If not, who? - What is the expected behavior if the RS can NOT determine what is "absolutely necessary"? - Should the client be informed that only some of the requested permissions in the permissionTicket were met? - Should the client be informed that scopes it specifically requested on the /token call were denied? - 3. Looping - Whose responsibility is it to determine the user is in a "permissions loop" and stop the loop and help the user? - client? - RS? - How do we envision this worknig? Do we need to add anything to the spec to help with loop detection? 4. API design / scope models - how prescriptive do we want to be about API design / scope models for UMA? - Can we document what API design / scope models we see being used with UMA today? - What guidance can we give on these topics? -- Distinguished Engineer Identity Services Engineering, AOL Inc. Mobile:+1-703-462-3494 Office:+1-703-265-2544

1 0

Agenda for UMA telecon 2017-02-09 (NEW DIAL-IN INFO)
by Eve Maler 08 Feb '17

08 Feb '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-02-09 Date and Time - *Thursdays,* *special meeting times through Feb 9: 8:30-10am PT* - Screenshare AND dial-in: http://join.me/findthomas (NEW) - 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> and 2017-02-02 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-02-02> - Logistics: - No meeting Feb 16 because of RSAC - This week is our last scheduled 90-minute meeting; plans for Feb 23, Mar 2? Interest in ad hoc work Feb 21/22? - At RSAC, Kantara member/IDESG reception on Thursday? No-host drinks somewhere? - 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 14 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-14.html> (updated) and RReg is up to 05 <http://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-05.html> (no change) - 266 <https://github.com/KantaraInitiative/wg-uma/issues/266>: Set math / resource and scope ecosystem AND 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>): - Please see recent ad hoc meeting's notes thread <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/-ucMXGmQl…> and hopefully forthcoming email from George - 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

Agenda for UMA ad hoc telecon 2017-02-07 / Core rev 14 is up
by Eve Maler 07 Feb '17

07 Feb '17

Core rev 14 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-14.html> is up. Some notable edits: - Some text <https://github.com/KantaraInitiative/wg-uma/commit/b29f6e3e23b514f7d8999859…> appearing in Sec 1.4.2 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-14.html#authorizatio…> in an attempt to close #264 <https://github.com/KantaraInitiative/wg-uma/issues/264>, Authentication-related error details. It's not a code example with error_details asking for ACR claims or anything, but it does briefly explain a couple of anticipated more-common design patterns for claims collection flows. - Some text <https://github.com/KantaraInitiative/wg-uma/commit/05ddfcc39d6bdf189fafb9bb…> has been added to Sec 3.6.5 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-14.html#authorizatio…> (Authorization Assessment), at George's suggestion, to discuss the AS's responsibility to be aware of and manage freshness/staleness of information such as claims. - The text in Sec 3.4 <https://github.com/KantaraInitiative/wg-uma/commit/f93a405a699f7e3f60153483…> about how the RS chooses what permissions to request has finally been changed <https://github.com/KantaraInitiative/wg-uma/commit/f93a405a699f7e3f60153483…> according to the consensus reached in the 2017-01-05 telecon <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-05>, namely it's okay to request permissions that don't suffice for the access the client attempted. I added an observation in the text to the effect that if the RS does this, it may result in further back-and-forth (based on our recent convos about inefficiencies). *Please see what you think.* ==== We're meeting tomorrow at what would be our usual time and coordinates (special meeting time/length of 90 minutes, 8:30-10am Pacific), except on Tuesday instead of Thursday: - 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 Our agenda is sort of a tossed salad of topics that really need attention, so that the specs can be in consistent format with substantive issues closed ASAP. I've listed a bunch of items here in what I hope is a rational "easy to hard" order so we can build on success. Please feel free to respond in email ahead of time -- not that there's much left -- to share your opinions. Set math: - Should the AS be forced to grant *CandidateGrantedScopes* if they came from *PermissionTicket*, or not? Let's not take forever to decide this. - What is the purpose of providing a previous RPT -- upgrade in order to manage a single RPT? Let's use current OAuth grant logic by analogy as much as possible ("no surprises"), and not duplicate purposes between a PCT and an RPT provided on the same request. - How to do authorization in the presence of a PCT on the request? a previous RPT? both? - Do we think the AS needs to report scopes granted to the client? - Do we still think the AS needs to report any contextual information about its authorization assessment to the RS? - In Sec 1.4.2, it says the assessment phase starts immediately if the client asks for an RPT without pushing claims. This is also true only if the client doesn’t provide a PCT, right?? Slightly farther afield: - - Do we think the RS SHOULD document its permission request practices, just as it would document its API generally and its scopes, so that clients will know what to expect as they continue down the RPT request path? RReg/permission-related: - I’ve been getting feedback from several people about the goodness of our having added the ability to request multiple permissions at once. Combined with the popularity of the “lazy resource registration” pattern (which I’ve finally reflected in the swimlane <http://www.websequencediagrams.com/files/render?link=Pu0sP0Oe2kjKc2WgdKZd>), the RS will tend to call the rreg endpoint right before calling the permission endpoint. #277 <https://github.com/KantaraInitiative/wg-uma/issues/277> is about allowing rreg of multiple resources. Should we align the request messages in other ways, like changing “scopes” to “resource_scopes”? Also, several people have pushed back on the array-for-multiple and object-for-singular design is inconsistent with frequent identity/LDAP practice and also inconsistent with the pattern we used in a lot of the rest of the spec. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 1

Set math
by Domenico Catalano 07 Feb '17

07 Feb '17

Hi, I’ve worked a little bit around set math for the authorization assessment, using a formal language and symbols, I hope it works :-) Set Math for UMA Authorization Assessment Let define a superset 𝑺 of all possible assignable scopes to protected resources in a UMA context. Let 𝑠 an element of 𝑺 (𝑠 ∈ 𝑺). Let define the following subsets of 𝑺: 𝐴 = ClientRegistered = {𝑠, scopes registered at AS by the Client , s.t. 𝑠 ∈ 𝑺}, A ⊆ 𝑺; 𝐵 = ClientRequested = {𝑠, scopes requested at Resource Server by the Client. s.t. 𝑠 ∈ 𝑺}, 𝐵 ⊆ 𝑺; 𝐶 = PermissionTicket = {𝑠, scopes recently used by the Client, s.t. 𝑠 ∈ 𝑺 }, 𝐶 ⊆ 𝑺; 𝐷 = ResourceRegisteredScopes = {𝑠, scopes registered with a protected Resource at AS by the RO, s.t. 𝑠 ∈ 𝑺}, 𝐷 ⊆ 𝑺; Calculate the RequestedScopes (𝑬 ) set as following: 𝑬 = RequestedScopes = PermissionTicket ⋃ (ClientRegistered ⋂ ClientRequested); 𝑬 = 𝐶 ⋃ (𝐴 ⋂ 𝐵); Let define SatisfiedPolicyCondition (𝑭 ) as the set all the scopes for which the client satisfies the policy condition related to. 𝑭 = SatisfiedPolicyCondition = {𝑠 ⇔ Client satisfies policy condition ∀ 𝑠 ∈ 𝑫}; Calculate the CandidateGrantedScopes (𝑮) set as following: 𝑮 = CandidateGrantedScopes = RequestedScopes ⋂ SatisfiedPolicyCondition; 𝑮 = 𝑬 ⋂ 𝑭; Thanks Domenico

1 0

Draft minutes of UMA telecon 2017-02-02
by Eve Maler 02 Feb '17

02 Feb '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-02-02 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2017-01-26 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-26>: Deferred. Logistics - Next week is our last scheduled 90-minute meeting; extend? - No meeting Feb 16 because of RSAC Currently our Core spec is inconsistent; we can't publish a WG draft for Last Call in this state. UMA V2.0 work *266: Set math / resource and scope ecosystem:* What is the deal with the Protected Resource Metadata spec <https://tools.ietf.org/html/draft-jones-oauth-resource-metadata-01>? Eve wondered if it has a hint of something in it that would be valuable for our current discussion. Just relates the history: Mike J created a "throwaway draft" just to save the idea somewhere on the Internet. The notion is to prevent a client from sending a token to a rogue endpoint. In the AOL case, if the Mail team creates a new endpoint, it's a way to have loose coupling and dynamic discovery of endpoints. But George agrees that the OAuth WG is not taking this up as a work item. Eve's specific idea about the usefulness of the static declaration approach vs. the active registration approach was that, if OAuth is chosen as the security mechanism for the RReg endpoint (and OAuth is an awesome security mechanism), that choice *requires* a binding of whoever/whatever the resource owner is – natural or legal person (individual or enterprise) – to the resources. Static declaration allows the resource to be generic, without any RO context. Proposal: Instead of having the RReg spec with a resource description document that passes the resource description by value and the scope description by reference (or a simple scope string), we develop a OAuth protected resource metadata spec that suffices for our needs, and then incorporate the RReg API into the UMA spec such that the RReg process simply binds a generic resource and its possible scopes together in an RO context with the PAT. Could this be achieved by simply extending Swagger? But then the client, in order to request scopes, would need to know about resource IDs as well. But that was why Eve went in this direction; a smarter client should be this smart. Eve's fear is that our design where clients only know about scopes will incentivize design of APIs and scopes in the exact same direction that OAuth does now: pushing APIs to put all the "juice" into scopes, the way Salesforce does, so that a client with only id scope can ask for chatter_api scope. In FHIR, if you have read scope and ask for write scope, you might get it added to the three resources you already had in your RPT, but you can never request access to other resources you didn't already have access to except by attempting access to them, thus hinting to the RS that you want them. Eve's proposal using the "scenario 3" approach in the WSD <https://www.websequencediagrams.com/files/render?link=0XEvf__PVcpdxGGsQb38> is akin to the direction Phil had sketched where the token is bound specifically to resources (actually, the RPT already is, but the client doesn't know it). In scenario 2, if we have a case of *CandidateGrantedScopes* that's partial, and the AS got a previous RPT, Discussion: Are we clear about not choosing scenario 3, "super-smart client"? Ishan: The client would have to know the RO in some fashion. Yes, presumably OOB. Agreed. Kathleen: The RO might have set policy that requires the client (and presumably the RqP) to meet various clearances; that's all still true. Yes. Summary by George: What we'd "lose" if we don't go this route is to potentially access a new resource without first attempting access to it. Eve adds: Whatever existing encouragement there is in the current OAuth design center for scopes to have a lot of power, there still is, but there isn't any further power in that direction. Mike: We could have potentially avoided some round trips in the messaging, but our spec schedule would take a hit. George: But we can extend the token introspection endpoint, maybe add a hint, to improve the current messaging. *We have consensus not to go the super-smart client route for now.* Justin notes, as the token introspection spec editor, that the notion of the hint was yanked. But you can add parameters on the request. Adding the permission ticket seems unreasonable since it's meant to be ephemeral. We have a couple of big decisions to make right now, then: - Efficiency of the RS permission request / response to client loop - We seem to have two loops where we have optimization opportunities: - James's: - 10 RS requests resourceA(scope1, scope2) 20 AS issues RPT resourceA(scope1) 30 RS introspects RPT, finds insufficient scope for request, GOTO 10 - George's: - The normal flow is client access attempt on R1, get ticket, go to AS, get RPT valid for R1; go to R2, get ticket, go to AS, get RPT valid for R2. We could say: On the R2 pass, we could say that the AS should check the previous RPT to see if it works for R2 already before going through the existing assessment logic. It would be on a different endpoint, not baked into the existing assessment logic flow. - Ishan observes that there's no harm in having the AS do this, as it's internal logic. - Effect of *PreviousRPT* on authorization assessment Open questions: How does the AS deal with partial results? Specifically, is PermissionTicket inviolable? How does the RS deal with rejected requests? Specifically how can it optimize? (James) How does the PreviousRPT affect set math? (optional) Can the AS optimize dealing with a previous RPT prior to engaging in assessment logic? *Publishing UMA endpoints in Swagger/OpenAPIs:* Does anyone want to research this? Justin speaks against; some others may be interested. Mike will look into it. OpenAPIs.org <https://www.openapis.org/>. IPR compatibility is a question. *Ad hoc meeting on Tuesday during the same 90-minute period as today:* George, James, Eve, Domenico, Kathleen?, Cigdem?, and Mike can attend. Attendees As of 19 Jan 2017 (post-meeting), quorum is 5 of 8. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem, Sarah) 1. Domenico 2. Eve 3. Mike 4. Cigdem 5. Sarah Non-voting participants: - Justin - George - Adrian - James - Kathleen - Ishan Regrets: - Maciej *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0