- WG-UMA - mailman.kantarainitiative.org

Draft minutes of UMA telecon 2015-08-13
by Eve Maler 13 Aug '15

13 Aug '15

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-13 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-13> Minutes Roll call Quorum was reached. Minutes approval MOTION: Approve the minutes of UMA telecon 2015-08-06 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-06>. APPROVED. Trust Elevation TC request Mike will follow up on Andrew H's request to write something up on UMA for the TC document. He's already on that TC. GitHub repo status Eve's xmlgrrl repo for UMA-Specifications is now moved over to the KI side <https://github.com/KantaraInitiative>. Issue resolution work We agree that a patch release is still the right thing to do. We assigned milestones afresh to all of the current issues. Eve will duplicate issues where they ultimately apply to subsequent releases. Issue 161/162 discussion: The constraint is that the RS must be able, based on the C's access attempt with no token and no other context, to distinguish the AS and RO that match the protected resource set. In practice, this likely means that the URI needs to be unique per resource set. Let's mention this constraint in a few places. E.g., in Core Sec 1.3.1 and Core Sec 2. And we also have to put it into RSR Sec 2 and Sec 2.2. Issue 163 discussion: 200 with a special header has been discussed. Let's align the header with the future! What do we think the V1.1/V2.0 header would be for the ticket, the RO-specific information the client would need, etc.? WWW-Authenticate: UMA parameters. So the name of this parameter would be what? We want to convey that we're not giving an error code, but we're starting a process that requires some additional action if they want to get the protected representation (ish) of the resource. We already have as_uri=as_uri and Justin would suggest that we have ticket=ticket in future. The sheer presence of the UMA header is all that is required – nothing else. Issue 172 discussion: The feedback from the implementation process is that what's in the spec is not enough. The OAuth spec has more guidance on this type of thing. Can we be more specific without saying exactly what the lifecycle is? Can it be forever or not, e.g.? The spreadsheet <https://docs.google.com/spreadsheets/d/1s27E3JsHdvl_UzhGkQ8ZWP2dnyAXQAj5sxE…> has a few more notes and champion assignments. AI status AI: Thomas: Review the charter for potential revisions in this annual cycle. AI: Sal: Investigate IP implications of formal liaison activities with other Kantara groups with the LC, and ultimately draft an LC Note as warranted. AI: Gil: Edit the UIG to add Ishan's content and excerpt it for Eve to add to the FAQ, pointing everyone to the UIG. AI: Sal: Fill out IDESG form to have UMA adopted as a recommended standard for use in the IDESG framework. AI: Mike: Write SCIM protection case study to highlight client claims-based use case. AI: Maciej: Write as many sections for the UIG as he can. AI: Justin: Write a UIG section on default-deny and race conditions. Attendees As of 30 Jul 2015 (pre-meeting), quorum is 7 of 12. (François, Domenico, Sal, Thomas, Andi, Phani, Robert, Maciej, Eve, Arlene, Irwin, Mike) Eve Irwin (regrets for next three telecons) Arlene Thomas Mike Maciej Domenico Sal Non-voting participants: Adrian Justin Sarah Nat Mark Jin Scott Regrets: Andi Robert François Ishan James Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

New swimlane for the issue 153/154 flow, with questions
by Eve Maler 13 Aug '15

13 Aug '15

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

UMA wikipedia page has gotten some updates
by Eve Maler 13 Aug '15

13 Aug '15

https://en.wikipedia.org/wiki/User-Managed_Access I’ve asked if Victor Ake (my colleague and one of the UMAnitarian lurkers here) can work on an update to the Spanish version. Mark D, are you able to update the Dutch version now? And Domenico (who I think is on vacation at the moment), can you update the Italian version when you’re back? Anyone want to take a stab at other translated versions? Thanks! Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Trust Elevation (OASIS) and UMA question
by Andrew Hughes 13 Aug '15

13 Aug '15

Hi UMAnitarians! I'm working on the OASIS Trust Elevation TC document, and would like to include a section that describes the UMA concept / mechanism of trust elevation (the "Needs Claims" flow, I think). In particular, we have a pattern that describes Trust Elevation and are soliciting contributions from WGs/TCs that do authorization protocols/profiles show how that pattern would look in their terms. Is anyone interested in working on this? I'm looking for 1/2 page-ish... Please contact me if you have questions thanks! andrew. -- *Andrew Hughes *CISM CISSP Independent Consultant *In Turn Information Management Consulting* o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000(a)gmail.com ca.linkedin.com/pub/andrew-hughes/a/58/682/ *Identity Management | IT Governance | Information Security *

1 0

Fwd: Four UMA Use-Cases in Healthcare
by Eve Maler 12 Aug '15

12 Aug '15

From Adrian for consideration in our legal subgroup meeting coming up shortly. Thanks, Adrian! > Begin forwarded message: > > From: Adrian Gropper <agropper(a)healthurl.com> > Subject: Four UMA Use-Cases in Healthcare > Date: 7 August 2015 at 6:33:18 AM PDT > To: Eve Maler <eve(a)xmlgrrl.com> > Cc: "Bucci, Debbie (HHS/ONCIT)" <debbie.bucci(a)hhs.gov>, Josh Mandel <jmandel(a)gmail.com>, Justin Richer <jricher(a)mit.edu> > > Eve, > > There may be only 4 distinct use-cases for UMA in healthcare. I wrote this in order to prepare for the legal subgroup this morning. Feel free to share if it's useful. > > > Alice-to-Alice N - The multiple portals problem - Alice wants to direct sharing herself > Alice wants to manage her EHR-1 and EHR-2 authorizations in one place. We call that place the AS. > Alice registers her AS with her practice’s EHR-1. > Alice registers her AS with another practice EHR-2. > From then on, Alice can sign-in to her EHR, view accounting for disclosures, and manage authorizations. > > Alice-to-Custodian - Delegation to a custodian > Custodian creates an AS for Alice. Custodian has a sign-in to Alice’s AS. > Alice registers her AS with her PCP’s EHR-1. > Alice registers her AS with another practice’s EHR-2. > From then on, Custodian can sign-in to Alice’s EHR, view accounting for disclosures, and manage authorizations. > > Alice-to-Bob Directed - Alice wants to authorize her PCP for directed sharing > Alice registers her AS with her PCP’s EHR-1. > The PCP shares an Alice-specific context with Bob. > Bob’s client EHR-2 presents claims to Alice’s AS, gets authorization. > EHR-2 accesses resource from EHR-1. > > Alice-to-Bob HIE - Alice wants to be discoverable > Alice registers her AS with her practice’s EHR-1. > Alice picks up a flier for the state HIE with a Q/R code, reads their Privacy Policy > Alice signs-in into her AS and scans the Q/R code. > The HIE allows Alice to pick her discovery attributes, registers Alice’s AS. > Bob’s client signs into the HIE, discovers Alice, gets authorization to EHR-1. > > > > -- > > Adrian Gropper MD > > RESTORE Health Privacy! > HELP us fight for the right to control personal health data. > DONATE: http://patientprivacyrights.org/donate-2/ <http://patientprivacyrights.org/donate-2/> Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

4 5

Reminder: UMA legal subgroup telecon 2015-08-14
by Eve Maler 12 Aug '15

12 Aug '15

Fri Aug 14 8-9am PT Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines <https://www.turbobridge.com/join.html>), room code 178-2540# Screen sharing: http://join.me/findthomas <http://join.me/findthomas> - NOTE: IGNORE the join.me dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar <http://kantarainitiative.org/confluence/display/uma/Calendar> Work through Adrian email thread to discuss UMA flow and use cases Walk through an UMA demonstration? (Eve) Discuss consent receipts and logging — how do they map to use cases? See consent receipt generator demo? (Mark) How many more use cases do we really need? a lot? a few? none? Discuss licensure vs. contract (if time?) Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Post 1.0 issue prioritization
by Mike Schwartz 12 Aug '15

12 Aug '15

>> In short: we don't have to wait, so let's not. Justin, I think Eve is doing a good job prioritizing the issues, and also getting feedback from the group on which issues to address. We've extended the calls to 90 minutes per week to specifically accommodate recent feedback we've gotten from implementers like you and others who are also now more actively engaged right now in development now that 1.0 came out. I don't think the group can afford to have more than one call per week, as we did last year to get the initial 1.0 spec to the finish line. I guess I'm wondering what else you think we can do to enable us to move in parallel like you suggest. - Mike

3 2

The idea of deferring big issues and focusing on actual bugs in the patch release
by Eve Maler 12 Aug '15

12 Aug '15

This topic is on the agenda for discussion tomorrow. In the case of issue 153/154, at least, there seems to be a definite leaning in the direction of deferral. If we lean that way for similar fundamental breaking issues, I added a column to the issue spreadsheet <https://docs.google.com/spreadsheets/d/1s27E3JsHdvl_UzhGkQ8ZWP2dnyAXQAj5sxE…> to imagine what the patch release workload might look like. The cells in bright yellow are my new proposals/questions for us to consider. You’ll also notice that I have proposed discussing and closing several issues tomorrow, in the pinkish color (mauve?). Judging by our past work cadence, we can likely meet our agreed timeline if we go in the deferral direction. If we don’t, we probably need to seriously rethink the timeline and release strategy. If you’ve got thoughts on the yellow cells ahead of the call (particularly if you can’t make the call), feel free to weigh in on this thread. Thanks, Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

2 3

Agenda for UMA telecon 2015-08-13
by Eve Maler 11 Aug '15

11 Aug '15

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-13 Date and Time Thu Aug 13 8:30-10am PT (we start 30 minutes earlier and meet for 90 minutes in August) Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines <https://www.turbobridge.com/join.html>), room code 178-2540# Screen sharing: http://join.me/findthomas <http://join.me/findthomas> - NOTE: IGNORE the join.me dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar <http://kantarainitiative.org/confluence/display/uma/Calendar> Agenda Roll call Minutes approval Sample motion: Approve the minutes of UMA telecon 2015-08-06 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-06>. Issue resolution work (issues on GitHub <https://github.com/xmlgrrl/UMA-Specifications/issues>) (UMA V1.0.1 issue nominations spreadsheet <https://docs.google.com/spreadsheets/d/1s27E3JsHdvl_UzhGkQ8ZWP2dnyAXQAj5sxE…>) ("sprint" document <https://docs.google.com/document/d/1c50top8X6Aqw3CEVeX_SD2THqO508ihs14QwLem…>) Are we definitely interested in putting significant breaking "upgrades" onto a major/minor release train? E.g., issue 153/154 What would be a reasonable schedule for such an effort? What type of release is it looking like? (SemVer <http://semver.org/> says breaking = major...) Now let's take a fresh look at the patch release Can we tackle a few patch release issues today? AOB Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Draft minutes of UMA telecon 2015-08-06
by Eve Maler 11 Aug '15

11 Aug '15

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-06 Minutes Roll call Quorum was reached. Minutes approval MOTION: Approve the amended minutes of UMA telecon 2015-07-30 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-07-30>. APPROVED by unanimous consent. APAC-friendly sync update This sync schedule is working really well. Spec versioning process update No update. Eve hasn't moved the repo over. Issue resolution work Goal is to discuss and resolve issues 165/153/154 (all ranked #1) – please review! Issues on GitHub <https://github.com/xmlgrrl/UMA-Specifications/issues> UMA V1.0.1 issue nominations spreadsheet <https://docs.google.com/spreadsheets/d/1s27E3JsHdvl_UzhGkQ8ZWP2dnyAXQAj5sxE…> Issues 153 and 154 Not meaning to guess Justin's exact thought process in any way... Observation #1: AS has a special "RPT endpoint", making up the entirety of the special "UMA authorization API", at which the UMA client asks for a special UMA "RPT" with authorization data on Bob's behalf, that acts suspiciously just like an ordinary OAuth token endpoint. If it were more like an OAuth token endpoint, greater UMA-OAuth alignment could be achieved. Observation #2: The UMA "authorization API token" (AAT) is an extra layer and hindrance to the entire OAuth-friendly cycle in this case, particularly because it appears to require that Bob have a login at the AS. Discussion: Isn't the last bit, about the login, just an implementation decision? He has to either be SSO'd into the AS, or have a local login at the AS, or be offered a federated ("NASCAR-like" or whatever) login option at the AS. More accurately stated, he has to be able to establish an authenticated relationship with Alice's AS. Observation #3: If the AAT flow were entirely removed and the RPT endpoint were turned into a ordinary token endpoint, then Bob's client would approach it to ask for "an access token" (perhaps of some UMA-flavored type?). Discussion: Eve contends that, since we are trying to keep everything as much the same as possible, then this new "UMA-flavored grant flow" would still (so far) have the the client approach the RS, fail, get a ticket, go to the AS's (now) token endpoint, ask for a token, and engage in the trust elevation flow we have already designed. Observation #4: Instead of using an AAT in the header of the token request, it would use its client credentials to identify itself, basically using its own recognizance. Discussion: Where else is the AAT required in headers? Is it required in the redirect of Bob for claims-gathering? No, there are other security measures imposed. What about in the case of an autonomous web service client? We think that this could use pushed claims to the token endpoint as well. More discussion: The AAT isn't very high-value! So a kind of "merge" to elevate what was the AAT flow up into what was the RPT flow to become an analog of a typical OAuth flow looks attractive. That means the claims flow would be the very first thing Bob does – no AAT step before. That seems kind of clean as a UX, if we're not missing anything like Bob's consent. And we don't think we're missing that, because that's what the OAuth flow is designed to do. The RPT represents everything the AAT did, but more. Why didn't we consider this before? In fact, we did <https://tools.ietf.org/html/draft-hardjono-oauth-umacore-03#section-3.3>. More discussion: In both the authorization API circumstances and the newly imagined grant flow circumstances, how does Bob know exactly what claims the client is pushing? Observation #5: UMA is still OAuth++ or value-add or something, in that the protection API that makes the AS and RS loosely coupled and makes possible trust establishment between them (using OAuth) is added on top, and in that Bob is a completely autonomous actor wrt Alice (which is why the grant flow we're considering has trust elevation as a key part of it), and in that the grant flow we're considering has asynchronicity as a key part of it. All the value-add still seems to adhere even if the AAT isn't part of the picture. Discussion: Regarding the Privacy concerns: if the Client does a POST on the RPT to get the AuthzData added to it, the AS can still decide to return a new RPT to the Client (if the presented RPT had AuthzData for another RS attached to it). So that could be a AS-privacy setting? According to the APAC discussion yesterday, the answer appears to be yes. We can use a MUST to force the AS to mint a new token per RS. (Justin also noted in email that if the client tries to present a token from RS1 for upgrading with authorization data for RS2, the AS should not allow that.) Discussion: Is UMA all pseudonymity-based? The AS knows Alice by AliceID(AS). The AS knows Bob through some set of claims, potentially. Each RS knows Alice by AliceID(RSn). Each PAT is a kind of pseudonymous federated ID by which both the AS and that RS know Alice. Each client has a set of access tokens (in the putative new solution) with a set of permissions, but not identifiers. Discussion: How would the client manage multiple access tokens? All it knows is that it's trying to access a resource. How would it know that the token it has been given is new for this RS? What if the spec said this (bold is new)? "If the client did not present a token in the request for authorization data, the authorization server creates and returns a new token. If the client did present a token in the request, the authorization server returns the token with which it associated the requested authorization data, which MAY be either the token that was in the request or a new one. In any case, the authorization server MUST return a new token when the client presents a token that is associated with a different resource server." Summarizing our sense: Generally positive about most aspects, but there is a concern about how clients handle the token situation, and some uncertainty about ensuring that the requesting party really has a chance to authorize the interaction. Next steps: AI: Eve: Develop swimlanes (web sequence diagrams) of the putative new flows, along with pros and cons, and share with the group by Monday. Let's TRY and have an active discussion, drawing in Nat, about the client concerns, before next Thursday. Let's TRY and conclude issues 153 and 154 in the early part of next Thursday's meeting. If we have a specific proposal in front of us for issue 165, we'll consider it, otherwise not. We'll also take up 160, 161, 162, and 168 next time. Regrets for next time: Andi, Robert, François, Ishan, James, Domenico. Ooh, next week is going to be tough for quorum, so everyone else please try and attend if they can! AI status AI: Thomas: Review the charter for potential revisions in this annual cycle. AI: Sal: Investigate IP implications of formal liaison activities with other Kantara groups with the LC, and ultimately draft an LC Note as warranted. AI: Gil: Edit the UIG to add Ishan's content and excerpt it for Eve to add to the FAQ, pointing everyone to the UIG. AI: Sal: Fill out IDESG form to have UMA adopted as a recommended standard for use in the IDESG framework. AI: Mike: Write SCIM protection case study to highlight client claims-based use case. AI: Maciej: Write as many sections for the UIG as he can. AI: Justin: Write a UIG section on default-deny and race conditions. Attendees As of 30 Jul 2015 (pre-meeting), quorum is 7 of 12. (François, Domenico, Sal, Thomas, Andi, Phani, Robert, Maciej, Eve, Arlene, Irwin, Mike) Eve Andi Irwin Domenico Maciej Robert Mike Arlene François Non-voting participants: Adrian James Rene Mark Ishan Allan Jin Regrets: Thomas Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

3 6