August 2015 - WG-UMA - mailman.kantarainitiative.org

IIW week in October -- who's going to what?
by Eve Maler 12 Sep '15

12 Sep '15

Who is attending any of the following activities that week? Please send me a private email (don’t spam the list). Thanks! ___ VRM Day http://www.eventbrite.com/e/vrm-day-2015b-tickets-18263887780 ___ OpenID Foundation workshop http://www.eventbrite.com/e/openid-foundation-workshop-before-fall-2015-iiw… ___ IIW Which days? ___ Tue ___ Wed ___ Thu https://www.eventbrite.com/e/internet-identity-workshop-xxi-21-2015b-ticket… ___ Any local activities on Friday Anything you want to advertise to the rest of us? ________________ For new UMAnitarians, Internet Identity Workshop week, twice a year in Mountain View, CA, is a nexus of a lot of identity-related activities. A fair amount of UMA work has been done at IIWs past; it actually got its name at one. We haven’t talked about it much of late, but our plan has been to conduct some interop activities at this coming IIW, which is XXI (#21). Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

5 5

for those who need the link -
by Dazza Greenwood 03 Sep '15

03 Sep '15

The legal subgroup is reviewing use cases now here: https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Use-Cases,-Role… Also, we are walking through some healthcare wrinkles that Adrian contributed, here: https://docs.google.com/document/d/1wygXX8FvHif07KA0P4IocBL-tsUGoXEFDpEwxNL… Thanks, - Dazza _ _ _ _ _ _ _ _ _ _ _ _ _ _ | Dazza Greenwood, JD | CIVICS.com, Founder & Principal | MIT Media Lab, Visiting Scientist | Vmail: 617.500.3644 | Email: dazza(a)CIVICS.com | Biz: http://CIVICS.com | MIT: https://law.MIT.edu | Me: DazzaGreenwood.com | Twitter: @DazzaGreenwood | Google+: google.com/+DazzaGreenwood | LinkedIn: linkedin.com/in/DazzaGreenwood | GitHub: github.com/DazzaGreenwood/Interface | Postal: P.O. Box 425845 Cambridge, MA 02142 | _ _ _ _ _ _ _ _ _ _ _ _ _ _

5 8

Handling spec writing process @ GitHub
by Maciej Machulak 02 Sep '15

02 Sep '15

Hi, It was discussed today how the current process of spec editing looks like on GitHub (currently the spec is here: https://github.com/KantaraInitiative/wg-uma). All the changes are done on this repository, some via branches and some directly to the master branch. It was suggested that maybe we could use distributed repos (each editor would have a fork of the repo) and changes to the main repo would be done via pull requests. While I agree that using pull requests is best practice, I think we could do without this for UMA spec editing. The current setup which we have is pretty low overhead and sufficient for our needs (we could probably improve on using branches but that's also not something we have to strictly stick to). However, I'd like to hear the opinion of others. Let me know so that we can act accordingly. Maciej -- Maciej Machulak email: maciej.machulak(a)gmail.com mobile: +44 7999 606 767 (UK) mobile: +48 602 45 31 66 (PL)

4 8

Associating the Requesting Party/Authorization client with the permission ticket.
by Farazath Ahamed 02 Sep '15

02 Sep '15

Hi, First of all thanks everyone for helping me out in this mailing list answering my questions that helped me a lot in getting through my GSoC. However, I am yet to complete my implementation. Therefore i will keep on pestering you with questions :) Getting to the question, We use the PAT to register permissions using the Permission Registration endpoint of the Protection API, do we have a standard way of associating the client who requests for access from the UMA protected resource server? Thanks -- *A.Farasath Ahamed* Undergraduate | Department of Computer Science and Engineering,University of Moratuwa Article Writer | MoraSpirit Mobile: +94 777 603 866 Blog: http://thepseudocode.blogspot.com E-Mail: mefarazath(a)gmail.com

3 3

Alice's "term sheet", as envisioned by the VRM folks [legal]
by Eve Maler 30 Aug '15

30 Aug '15

http://blogs.law.harvard.edu/vrm/2015/08/29/vrm-day-lets-talk-uma-and-terms/ They’re talking “Party” language there... Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

UMA legal subgroup notes for telecon 2015-08-28
by Dazza Greenwood 28 Aug '15

28 Aug '15

UMA Legal Subgroup Discussion Fri Aug 28 8-9am PT/11-12 ET Bridge: (605) 475-4700 / passcode: 176720# (due to difficulty using the usual conference line, participants used or switched to this telephone bridge ) UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Attending: Thomas Hardjono (first half), Scott David, Jon Neiditz, Adrian Groper, Mark Lizar, Jeff Stollman and Dazza Greenwood (who took notes and facilitated in Eve's absence). Announced agenda: * Select goal and use case(s) * Proposal: RS liability —> Alice visits PCP and introduces its EHR system (RS) to her AS. AS variations? * Data rights ownership impact? * Work through role perspective(s): * Principal/Agent/Third Party * Identify next steps Dazza took the roll, provided a quick overview of the agenda and where the group has left off the previous week, and confirmed everybody wanted to keep to the announced agenda. Dazza provided a quick overview of Adrian's contribution of scenarios in a use case table and described the intention to use these scenarios (very basic use cases) as a starting point to overlay legal roles in hopes of shedding light on what recommendations may be needed or helpful from the legal subgroup. Dazza thanked Adrian and handed him the active speaker to present a Google doc based Use Case Table of Different Healthcare related scenarios demonstrating different combinations of actors and flows. See: https://docs.google.com/document/d/1wygXX8FvHif07KA0P4IocBL-tsUGoXEFDpEwxNL… Dazza also added a link to this Google doc to the top of "UMA Legal Group 'Use Cases, Roles and Obligations/ wiki page" See: https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Use-Cases,-Role… Adrian's presentation revolved around seven scenarios organized in his use case table, each featuring variations of UMA roles. Some confusion about who was doing what in the scenarios and how the scenarios related to familiar situations. Adrian provided further context by reference to one of the links in the use case table, linking to a standard looking patient consent form for the "Release of Information" under HIPAA. See: https://docs.google.com/document/d/1biUqGwvOinf9Sj6eyh3hiiDzoccSEaz3ewOTa7W… Dazza requested at this point that Adrian step the group through each HIPAA named role (already highlighted on the consent form) and identify the corresponding roles and data in the use case table scenarios. Based on Adrian's cross-walk of HIPAA and every day business names of each party, Dazza confirmed everybody understood the same use case, thanked Adrian for providing the anchoring document and presentation and re-commenced facilitation. Given the relatively short time remaining and the priority of engaging all participants, Dazza used the remaining time soliciting feedback from each participant on 1. their broad and general estimate of the situation and 2. ideas or suggestions about more specific directions the group should consider, especially directions likely to result with timely recommendations. Scott David, among other incisive comments, incidated he agreed that it is a good idea for the subgroup to start with HIPAA because it is a good match for UMA legal evaluation. Also, the statutory duties are the right ones. Also, HIPAA use cases relate directly to contractual practices, which Scott indicated would be fundamental tools for addressing the legal issues. Scott also cautioned UMA won't be bound to healtchare or any single given scenario or field of law and legal results will vary as any particular contractual terms or specific legal measures are applies in other or more generic scenarios of use. John Neiditz indicated UMA offers an approach that starts with the patient and this is a good fit. John noted this may well change the relationship between the operator of the Resource Server and the operator of the Authorization Server. This needs to be managed carefully and well but overall offers an opportunity to improve The current state of affairs. John indicated he felt agency law analysis is a great thing to do as part of the groups work. Jeff Stolman also agrees (w/ Scott and Adrian specifically) on the direction and indicated a need to do a much deeper dive into the process diagrams in order to surface enough relevant detail for more substantive work on the issues. Jeff indicated the issues of "shared party log-in" (is that what he said? like among spouses?) will need to be dealt with either by this group or by others, soon. Jeff also indicated he agreed that it is a great idea to use agency law as part of the work of the group. Dazza raised the question: to what extent does agency law apply the same beyond the US? Scott answered that by use of contracts one can deliberately introduce agency and other relationships and that is also distorted by local law (like a situation he had with Indian law for a large ecommerce company). Mark Lizar indicated he thought we were on the right track here and looks forward to continuing to participate going forward. Adrian Groper indicated the group should watch three way relationship between individual (personal data "owner"/subject) and direct service providers and third parties. Adrian suggest it is ok not to worry so much about business associates, etc. and other flavors of resource owner in a HIPAA context. Rather, it is important to understand and work with the basic triangle use case. (presumably the basic OAuth 2 triangle of 1) the individual resource owner and provider/witholder/revoker of consent, 2) the resource/auth service provider and 3) the third-party client/app). Adrian brought up the Apple's Healthkit as an example of an alternative model of relationships and healthcare personal data and transaction flow. This example sparked a lively and creative round of discussion among several members who informally stayed on the line to continue the dialog after the call was adjournd. As with other contexts, some ambiguity arose between use of the words "Consent" and "Authorization" as well as "User Control" and "User Management". It was noteworthy that the iPhone device is at once apparently "owned" by the user while at the same time housing components and processes that are proprietary to and controlled by others parties. Presumably, further development of nomenclature for legal lawyers of UMA use cases will more quickly and clearly reflect which people, devices and processes in operate at the behest or in the interests of the individual who holds and generate personal data through systems like the Heathkit and which operate as "agent" for and in the interests of other parties. It was also noted that Apple's open source and modular componentization of an "informed consent" function was interesting and should be explored to understand how it would or could relate to OAuth 2 and UMA authorization flows. Dazza added an 8th use case to the use case table as a rough sketch / placeholder to further explore Apple Healthkit/Researchkit. Meeting Results Keyed to Agenda: > Select goal and use case(s): * Yes, start with identified health data related use cases described in use case table provided by Adrian and augmented by the group during the meeting. > Proposal: RS liability —> Alice visits PCP and introduces its EHR system (RS) to her AS. AS variations? * This was not directly addressed. > Data rights ownership impact? * This was touched upon a few times and was an explicit basis for the need to further explore how ownership, control, contractual and agency relationships play out with Apple's Healthkit/Researchkit. > Work through role perspective(s): * One level of legal roles was briefly but completely worked through by use of the HIPAA consent form for Release of Information in the context of Adrian's UMA use case table (ascribing the roles of "covered entity, patient, etc to each actor or other entity in the UMA use cases"). The group also indicated a desire to do that again more comprehensively to use cases in the table and with other use cases. > Principal/Agent/Third Party * A majority of participants voiced a strong interest to apply agency law oriented role based analysis for all UMA legal use cases. The basic formula was felt to be strong fit with the roles, relationships and rules generally intended for UMA. However, some caution was stated about limits of how far agency law may apply in the same way (especially beyond the boarders of the US) and also the potential wild-card effect of unpredictable but over-riding roles, rights and responsibilities agreed by contract. The general sense was that Princiap/Agent/Third Party triangluar analysis will be a valuable reference point to evaluate and describe intended legal context and outcomes. The idea was to use agency analysis as a benchmark to evaluate conformance or need for additional contractual or other structuring of the rules defining rights and responsibilities for roles and the networks of relationships, interactions/transactions that ensure predictable, expected legal results. > Identify next steps: The following next steps were identified: * It was confirmed that the group should continue working through the HIPAA use cases * It was evident participants want to further discuss the Apple Healthkit/Researchkit and so it will be included as a variation of the initial health information scenarios. * Dazza will work with Adrian (and anyone else so inclided) to refactor the use case table scenarios into more detailed cross-functional process diagrams (aka swim lane diagrams) including agency law overlay (and possibly a first guess as to where contracts are formed, already exist or could be monkeyed with). When ready, a link to the diagrams in the wiki will be emailed to the list for everybody to hammer at or at least view them. * Other? Thanks, - Dazza --- Note: Due to technical difficulty, the meeting did not get rolling until nearly 30 minutes after the start time, but covered a lot of ground nonetheless prior to adjournment at slightly after 12pm Eastern Time. Several participants also chose to continue a lively and topical discussion for 15-20 minutes after the meeting was formally adjourned. _ _ _ _ _ _ _ _ _ _ _ _ _ _ | Dazza Greenwood, JD | CIVICS.com, Founder & Principal | MIT Media Lab, Visiting Scientist | Vmail: 617.500.3644 | Email: dazza(a)CIVICS.com | Biz: http://CIVICS.com | MIT: https://law.MIT.edu | Me: DazzaGreenwood.com | Twitter: @DazzaGreenwood | Google+: google.com/+DazzaGreenwood | LinkedIn: linkedin.com/in/DazzaGreenwood | GitHub: github.com/DazzaGreenwood/Interface | Postal: P.O. Box 425845 Cambridge, MA 02142 | _ _ _ _ _ _ _ _ _ _ _ _ _ _

1 0

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

28 Aug '15

Fri Aug 28 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 <http://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> Select goal and use case(s) Proposal: RS liability —> Alice visits PCP and introduces its EHR system (RS) to her AS AS variations? Data rights ownership impact? Work through role perspective(s): Principal/Agent/Third Party Identify next steps Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

4 3

update on legal subgoup
by Dazza Greenwood 28 Aug '15

28 Aug '15

2 2

Alternate legal subgroup dial-in (was Fwd: Reminder: legal subgroup meeting starts now)
by Eve Maler 28 Aug '15

28 Aug '15

Alternate number below. > Begin forwarded message: > > From: Thomas Hardjono <hardjono(a)mit.edu> > Subject: Re: [WG-UMA] Reminder: legal subgroup meeting starts now > Date: 28 August 2015 at 8:10:50 AM PDT > To: Eve Maler <eve(a)xmlgrrl.com> > Cc: "wg-uma(a)kantarainitiative.org WG" <wg-uma(a)kantarainitiative.org> > > Alternate bridge > > Bridge: (605) 475-4700 / passcode: 176720# > > > /thomas/ > > (Sent from my iPhone) > > > > >> On Aug 28, 2015, at 11:00, Eve Maler <eve(a)xmlgrrl.com> wrote: >> >> …sans me. I’ve sent the host PIN to Dazza. If you guys experience any bridge problems, feel free to ping me on Skype (“xmlgrrl”). Have fun, y’all! >> >> Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com >> >> _______________________________________________ >> WG-UMA mailing list >> WG-UMA(a)kantarainitiative.org >> http://kantarainitiative.org/mailman/listinfo/wg-uma Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Reminder: legal subgroup meeting starts now
by Eve Maler 28 Aug '15

28 Aug '15

…sans me. I’ve sent the host PIN to Dazza. If you guys experience any bridge problems, feel free to ping me on Skype (“xmlgrrl”). Have fun, y’all! Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

2 1

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

27 Aug '15

Many thanks to all the UMAnitarians who made it onto the call today — we made great progress. I really apologize for having the call run over so long. And apologies also to Jon Neiditz, who’s been attending the legal subgroup calls but for whom this was the first WG call — normally I would have had him say a few words of self-introduction… We’ll do that next time, I promise! http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-27 Minutes Roll call Quorum was reached. Minutes approval MOTION: Approve the minutes of UMA telecon 2015-08-13 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-13> and UMA telecon 2015-08-20 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-20>. APPROVED by unanimous consent. Conclude on topic: Restricting GitHub editing Deferred. Workshop space No takers at the moment. Formatting the specs Maciej has an XSLT for turning UMA's XML2RFC source into Kantara specs. He is willing to take it the rest of the way. Let's pursue this. Issue resolution work #163/#168: Given the early stage of UMA implementations, and given the technical soundness of the fig-leaf logic for MAY/SHOULD/MUST, we are going to add the ticket parameter in the header, and greatly soften the need for the ticket body. #176: Why would an RS want to indicate to a client that it's giving it a public version of the resource, but that there is a protected version, and it can't help the client seek access to it right now? Then the client could a) know that there's more, and b) choose to try later. Should the RS try again on its own later? No, because it has no relationship with the client; why would the RS take action on its behalf? The RS could, of course, respond with a non-UMA response (which gives no hint of anything wrong). So if there's any option at all to respond with "an UMA response", then there should be some reason to use it. Suggested: A new header. James suggests (from the HTTP spec <https://tools.ietf.org/html/rfc7234#section-5.5>): Warning: 199 UMA Authorization Server Unreachable The client is not allowed to take any automated action beyond displaying this text to the RqP, but that lets the RqP know that there's "more" behind the RS. "If the RS received an XXX error from the AS, and did not receive a permission ticket, then is unable to create a WWW-Authenticate: UMA header and MUST include a header of the following form: "Warning: 199 UMA Authorization Server Unreachable"." #172: Justin is looking for more implementation guidance, which we're thinking should really go in the UIG rather than here. Should we include a cross-reference out? Let's do it. We will stick to language that supports the RFC 2119 normative assertions in the spec. #171: Eve SWAG'd some text guessing that we would require at least one scope to be registered in future. But no one?? is crazy about making this kind of a decision now. So let's revert it. #164: Goes away because there are no mandated HTTP codes anymore! #161: We are cycling on Justin's wording: Note: When a client attempts access to a presumptively protected resource without an RPT, the resource server needs to derive the authorization server and resource set identifier associated with that resource from some other aspect of the client's request. This effectively means that the resource server’s API needs to be structured in such a way that the client's RPT-free request uniquely identifies the resource set. In practice, this information likely needs to be passed through the URI, headers, or body of the request. Done. #160: Looks good; we'll get review of the whole spec later. The last STRONGLY RECOMMENDED should be in active voice, not passive. #151: We shouldn't have the AS check for URI host/scheme matching, so the second part of the third paragraph in RSR Sec 4 should come out. We don't want to add any SHOULDs. #144: Just needs s/s/z/ in AS. Shall we close all of the issues at this point? We're ready to close them and review the final text, once Maciej has done the final edits tonight. We may be ready to vote on progressing the candidate Draft Recommendations to the LC next Thursday. 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 21 Aug 2015, quorum is 7 of 13. (François, Domenico, Sal, Thomas, Andi, Phani, Robert, Maciej, Eve, Arlene, Irwin, Mike, Jon) Eve Thomas Mike Maciej Arlene François Jon Sal Non-voting participants: Sarah Ishan Mark James Justin Dazza Andi Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 1

The RS liability conundrum and use case proposal [legal]
by Eve Maler 27 Aug '15

27 Aug '15

A number of folks have been discussing liability topics in side-email, and I wanted to share some excerpted thoughts here in preparation for Friday’s subgroup call. (Unfortunately, I can’t be on the call myself; Dazza has graciously agreed to facilitate.) The top liability/adoption conundrum I think we face is the one of whether a resource server (RS) can become comfortable with “outsourcing” protection to an authorization server (AS). An imperfect but apt analogy in the identity world is the relationship between relying parties (RPs) and identity providers (IdPs). Adrian has been describing this as wanting to define a “safe harbor” for the RS. And looking at what use cases to start with, we’ve got a healthcare elephant in the room, so I suggest we tackle it and see how it goes. :-) A pattern we’re seeing in the HEART group use cases involves Alice visiting a primary care provider (PCP) for the first time; we can imagine her offering for the PCP’s electronic health record (EHR) system to connect up to "her AS" (*more about this in a sec). So we’re just talking about very initial UMA steps here, not even a whole flow, and there don't even have to be any Bobs in the picture yet (unless he’s needed for Third-Party off-screen extra purposes). (I realize not every jurisdiction in the world has private-sector PCPs, but I believe that in some public-sector systems, private PCPs work under contract to the government — might they feel liability pressure?) *What do I mean by “her AS”? Adrian and I had a really interesting exchange about what the relationship should be between the RS, Alice, and "Alice’s AS”. His take: The RS has no right to object to whatever AS Alice wants to tell it to use, because it has no stake in the matter — it just does what the AS tells it to, it gets safe-harbor protection by getting a list of assurances that either come built-in with UMA, or are can be built on top of it (I’m not sure I understand the whole list...). My take: I really want to believe this. Obviously, what I want us to be able to build is an ironclad case for this! But an RS in real life has to act as an OAuth client to an UMA AS, has to trust that the AS actually does the right thing in coughing up tokens, that it’s secure, etc. Without those “trust framework” types of assurances, it would be crazy — or, more to the point, the CEO, CFO, and CIO of the RS operator would be crazy — to allow Alice to just point to Zeke’s Nocturnal AS (motto: “We Fly By Night”). In fact, if Alice built her own AS, it could be even shadier because she could collude with it to put lots of other people’s data at risk — the AS may end up seeing identifiers and claims of requesting parties, and maybe Alice is opening up the AS at home and looking at all the data. (Not that the RS may strictly care about these vulnerabilities, but *I* care…) In case it turns out to matter for use case exercise purposes, here are some candidate variations on the chosen AS that I identified: Alice-AS: Alice runs her own AS, whether on a home server or at her ISP or in AWS or whatever Social-AS: Alice chooses her own AS, say, run by Google or Facebook or some similar service (a la social IdPs) through a “NASCAR" interface Gov-AS: Alice uses a public-sector AS Private-AS: Alice uses the AS offered by the same closed system in which the RS runs (a la the new Privacy Control Center in Google Apps) Do the scenario, the goal, the roles, and the UMA flow give enough to work with in mapping to contractual parties? Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 1

Agenda for UMA telecon 2015-08-27 (final 90-minute call before we revert)
by Eve Maler 26 Aug '15

26 Aug '15

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-27 Date and Time Thu Aug 27 8:30-10am PT (we start 30 minutes earlier and meet for 90 minutes in August – this is the last 90-minute call!) 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-13 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-13> and UMA telecon 2015-08-20 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-20>. Last-minute quick hits Conclude on topic: Restricting GitHub editing Any interest in Kantara workshop space on December 4 in Vienna at Rainer's European Trust and Identity Workshop? Issue resolution work: Links: recent commits <https://github.com/KantaraInitiative/wg-uma/commits/master> (click on each identifier code to review changed text in context) - 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…> This is intended to be our final week for considering/resolving substantive issues, so please review, and please do any outstanding spec action items! Then we are set to approve our Draft Recommendations for next-stage LC approval by Sep 3 or Sep 10 (note: Eve regrets for Sep 10) AOB Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Reminder: UMA legal subgroup telecon 2015-08-21
by Eve Maler 25 Aug '15

25 Aug '15

Fri Aug 21 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 <http://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> Analyze new (positive and negative) use cases sent to the list Is this list complete enough to be going on with, for our purposes? Do we need to capture use cases for different “topologies" (deployment ecosystems) too? What would “structuring the transaction” look like in terms of accomplishing our mission? How would consent receipts/logging/auditing come into play? (I apologize for getting this agenda out so late!) Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

3 9

Rethinking our resolution to #161/#162 (protocol assumes one resource per URL/RO)
by Eve Maler 23 Aug '15

23 Aug '15

When we discussed this on the last call, we gained consensus around wording as follows (emphasis added — hopefully the formatting will make it through): "Note: When a client attempts access to a presumptively protected resource without an access token, the resource server needs to ascertain the authorization server and resource set identifier associated with that resource without any context to guide it. In practice, this likely means that the URI reference used by the client needs to be unique per resource set.” In the previous week’s discussion, I’d had a high-level suggestion for a strategy for providing RO context, which we discussed briefly and concluded didn’t satisfy the goal to let existing APIs stay as they are, but thinking about it again, I’m not sure why that is. Let me run through it in detail. If the RS has an API that is completely generic per RO, such as a singular endpoint that normally depends entirely on an OAuth token to convey the user context, it would similarly register that singular resource set over and over for each of its many users (each using a different PAT) at an AS, getting a unique resource set ID for each in turn. It does indeed have to be prepared to associate some attribute with a resource set that can later be matched up with the PAT, and then what remains is for a client to provide that attribute somehow when attempting access with no token. Depending on the nature of the API, the context could be in a query parameter, or something in the request body. So “without any context to guide it” in our wording isn’t strictly true. The approach I mentioned on the call was what appeared in our wireframes as an “authorization code” that the AS would send in an email notification to the RqP, which the client would use in attempting access. That probably wasn’t quite the right way of envisioning the UX, but I think Justin was saying that this requires propagating changed URI structure all the way through. I don’t believe this is needed. Here are several ways to complete the PAT-to-client-context chain for a resource set given our same example, using the “uri” location property of the resource set description, which is optional and the only part of a resource set description that isn’t entirely abstract: If the RS registered the endpoint with some kind of query parameter on it identifying the RO, discoverability would be possible, at (what I believe is) the small cost of inventing a “new URL” just for the purpose of user discoverability but not real URI namespace management. Thinking about Twitter’s API, it would be possible to look up “Alice in Twitter”, “Bob in Twitter”, etc. in the directory and attempt access to their protected Twitter endpoints without inventing new API structure. If the RS and AS had the opportunity to extend the resource set description JSON structure for extra discoverability features, the RS could add a property for RO identity, enabling an out-of-band means for the requesting side to discover and convey RO identity in, say, a request body. If the RS registered only the generic endpoint, indeed discoverability wouldn’t be possible without a totally out-of-band RO hint provided somehow. If this thinking is correct, I think it would be a good idea to revise our wording because we were trying to signal something about the nature of the RS API, but backed off of it and — while making a potentially true statement about the client API call — overstated the case by getting into implementation detail (“the URI reference used by the client"). I suggest making the following revision: "Note: When a client attempts access to a presumptively protected resource without an access token, the resource server needs to ascertain the authorization server and resource set identifier associated with that resource. If the interface presented by the resource server is not resource owner-specific, the client needs to supply sufficient additional context as part of the resource request. See the [UMA-Impl] for advice on ways to accomplish this.” …and then, obviously, adding something like the analysis above to the UIG. (Note that I call it “interface” and not “API” because we do that elsewhere in the spec; we don’t presume it has an API in the classic sense.) Thoughts? Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

2 5

groundwork for non-vertical-specific legal use cases
by Dazza Greenwood 22 Aug '15

22 Aug '15

Some groundwork on developing legal use cases for discussion next week is forwarded below. More general background on the law of agency is available at: https://en.wikipedia.org/wiki/Law_of_agency ---------- Forwarded message ---------- From: Dazza Greenwood <dazza(a)civics.com> Date: Fri, Aug 21, 2015 at 2:59 PM Subject: Re: [WG-UMA] Reminder: UMA legal subgroup telecon 2015-08-21 To: Eve Maler <eve(a)xmlgrrl.com> Cc: Mark Lizar <mark(a)smartspecies.com>, Adrian Gropper <agropper(a)gmail.com> Following up: For the next meeting, it sounds like the question is: What 2 or 3 use cases would "flesh out the AS possibilities"? The essence of two distinct alternative possibilities we discussed are: 1) Its an AS world and Alice just lives in it; and 2) The AS works in Alice's Restaurant. Eve, as always, you posed a really good question and I'd be happy to work on it for input to the next meeting. My own instinct is usually to go into the weeds of fact specific contexts like in HIPAA or the EU privacy directive. But upon reflection I like your proposed next step more and more because it logically is the first brick of an otherwise uncertain foundation. Here is my thinking: Currently, most of the legal context and basis for establishing rights and obligations of parties using UMA will source from the economic sectors and verticals in which UMA is deployed and used. This however is complex and confusing to analyze. The focus for next week is therefor to develop use cases that are not vertical-specific to any particular vertical. This also means keeping identity-federation-agnostic. This is a narrow scope focused on identifying, describe and defining the "base-case" legal roles and rules between Alice and the AS. The fundamental assumption in Scenario A is that the AS "works for" Alice in the sense that it "serves the interests of" or "is answerable to" or "directed by" or "the legal Agent of" etc Alice in some meaningful way. Examples of these relationships between individuals and organizations include investment banks who transact money or other assets of an individual and law firms who advocate for an individual. Identifying the legal dimension of the use cases from the perspective of generic "agency law" would give us traction to make good progress on the task for next week. It is possible to apply the rules of agency law without reference to other more specific legal relationships arising from roles associated with any particular economic sector or industry vertical context. Applying the rules of agency law is one way to credibly address the question of who will prevail in a dispute between the parties over protected resources. That means it provides a basis for concluding what bundles of rights or responsibilities any given use case actor has with respect to the other actors and to the protected resources at stake with UMA use cases. For a sound legal analysis it is important to have a sense of the nature of the thing at stake. If is a family member we have one analysis (maybe we can limit their TV watching but not take their TV) and if it is a city we have another (maybe we can out it into receivership but not under occupation). The most relevant legal aspect of OAuth 2 (hence UMA) protected resources is that they are property. These resources are basic boring normal property. They happen to be intangible property and that has been normal and boring for decades. No big deal. The nature of basic property is not specific to the idea of "intellectual property". That is another context that may or may not be important or even apply to any given intangible property, depending on the context. What definitely applies and provides a direct, simple and complete cross-walk to regular old vanilla agency law and heaps of other well understood and widely agreed legal fact patterns is the fact that these resources are also property. There exists a long tradition of roles and expectations about property rights and all that can usefully be vectored directly into the equation for Alice. It may be helpful to connect the dots and make a clear surface area for application of things like business models, legal terms and technical protocols. Among other things, data and other protected resources like services or rights to service levels etc are also property and people have "property rights" to buy, sell and otherwise slice and dice property rights. UMA legal use cases that focus on the specific rights or obligations linked to protected resources are tractable and totally avoid the needless debates about what "ownership" does or should it could mean if only everybody would agree to that definition. The question of ownership has been asked in many a personal data and electronic transactions forum and it is very definitely the case that everybody does not agree on a definition of ownership. And yet, it is frequently possible to find agreement on named rights and obligations with respect to data and other property. The concept of ownership suggested it is the sum total of all rights to property. One could say that "exclusive control, possession and enjoyment" of property is full ownership. Yet, much of the value and fun of having data and other stuff comes from sharing it. Most people would not have a home if the value was not shared with whomever hold their mortgage. Who owns the home when the mortgage is worth 90% or even 110% of the economic value of the property? The deed would says title owner is Alice and yet the word ownership is not really very important to the practical questions of who can do what. The basic roles are Principal (which is a reasonable fit with with UMA's happy Alice and 29100 Principal as well), and Agent and Third Party. It is as good a starting place as any I can think of and better than most. The authoritative source of agency law is the "Restatement" and it is both a source of voluminous case law and also boasts a lot of law school and other pre-argued "fact patterns" with broadly agreed legal "answers" and reasonably expected dispute outcomes. The presence of a lot of well worn fact patterns based on generations of case law and codified/formalized rules (ie the "Restatement") is very valuable for the purposes of this workgroup. The value of such fact patterns is they are carefully designed in a way that can be cross-walked to technical use cases pretty easily, providing a source of existing agreed legal scenarios with named roles and expected legal results to get us started. Coming up with that stuff from a blank slate and getting broad understanding and agreement on the expected legal results can be a daunting long term task and therefore makes it less likely this legal group could achieve its adoption oriented mission. As a side-note, part of what makes the UMA flavored Alice to Bob flows interesting is precisely that they shed light on the nature of roles individuals have in relationship to "service" providers. There are many layers of connotation around the legal concept of a "service provider" and decades of law school text books and bar exam fact patterns that routinely position such parties as agents providing a service for or on behalf of principals. This gives tools for lawyers to deliberately structure transactions by defining defining roles and corresponding legal rules to create predictable and beneficial legal outcomes for their clients. By contrast, typically in the modern mass-market networked economy it is the individual who works for and is the legal "agent" of one or more organizations which are the legal "principal" in that context. These are legal terms that apply to the "roles" of the parties and from which "relationships" can be revealed. Employment relationships, as an example, carry some predictable sets of rights and obligations and also vary to some degree depending on factors like the applicable jurisdiction(s), and other relationships the parties may also have with one another or with others (like when somebody is your patient but also your boss or your student but also your auditor, etc). In doing an AS relationship analysis that "non-vertical-specific" we have an opportunity to start with a very clean slate and just ask the level-setting question: what is the basic legal relationship and which roles in the relationship is played by each "party" (aka actor or entity or person) identified in the use case? This is a great question to level set for the call next week and provides a sound foundation upon which to clearly layer vertical-specific relationships and other important sources of context. It is possible to identify, clarify and simplify the context of use cases by just naming the legal roles/relationships of parties conducting transactions or other interactions. Once the legal dimension of context can be refined down to a few defined roles and interactions it is a lot easier to speculate on and have an opportunity to successfully deliberately structure the relationships and transactions to achieve more predictable intended legal results. Layering on "vertical-specific" financial services, educational, clinical care, municipal, commercial, law enforcement, workplace, etc contexts will provide a well of known and named sets of legal relationships corresponding to definite and repeating roles which can therefor be linked to each identified party in any use case. Typically a technical use case provides to little information to assign vertical (or other) specific legal roles to a given party with high confidence. This is signaled when a lawyer says "it depends..." when asked what legal roles applies. That goes double for the evrn more ambiguous question "who 'owns' this or that data or other property" in a use case. The good news is that by at least by answering Eve's question about non-vertical-specific and then some vertical-specific use cases and developing some consistent documentation of roles and other terms we will have built a tractable legal fact pattern. With that traction we can make progress to resolve the key sources of ambiguity needed for lawyers to make conclusions like "in use case xyz, Alice is the Principal, the AS is the Agent of Alice" and "in use case abc the AS is a "covered entity" under HIPAA and has a legal obligation to share Alice's resource with Bob upon Alice's signed consent and request to share". This is good and such traction is one way to achieve the mission statement of this legal subgroups. When a lawyer says "it depends" the opportunity is to elicit the factors upon which a legal conclusion about the situation depends and therefor to structure (aka architect) systems, relationships and activities to get intended legal results. The opportunity this workgroup had is to surface the important and potentially outcome changing factors upon which legal determination of use case by use case roles depend. The purpose of creating a sound basis for assigning any/all potentially applicable legal roles to parties in use cases is chiefly to deliberately define and design the legal relationships, rights, responsibilities and results. Ok, so beyond writing a lot of blah blah words, here is what I can commit to for input to the next legal group meeting: I commit to publish a roles and definitions wiki page that is cross-referenced/cross-linked to the use cases we have so far and - more importantly - where the group can continue compiling named roles and other defined terms. Each term will be at an HTML anchor point to simplify and streamline identification of the meaning people are using and to provide a "ready to use" resource for popping in the eventual set of terms and meanings chosen by the group for use in a final set of legal use cases and corresponding recommendations. Thanks, - Dazza | Sent from my iPhone | Please Forgive Typos _________________ | Dazza Greenwood, JD | CIVICS.com <http://civics.com/>, Founder & Principal | MIT Media Lab, Visiting Scientist | Vmail: 617.500.3644 | Email: dazza(a)CIVICS.com | Biz: http://CIVICS.com | MIT: https://law.MIT.edu <https://law.mit.edu/> | Me: DazzaGreenwood.com <http://dazzagreenwood.com/> | Twitter: @DazzaGreenwood | Google+: google.com/+DazzaGreenwood | LinkedIn: linkedin.com/in/DazzaGreenwood | GitHub: github.com/DazzaGreenwood/Interface On Aug 21, 2015, at 12:01 PM, Eve Maler <eve(a)xmlgrrl.com> wrote: AI: Dazza and Eve: Coordinate on producing 2 or 3 candidate distinctive use cases that flesh out the AS possibilities, non-vertical-specific and identity-federation-agnostic.

2 1

Fwd: [KI-LC] Of Possible Interest - OTA IoT Trust Framework Public Review
by Eve Maler 21 Aug '15

21 Aug '15

Here’s something called a “trust framework” that looks a bit different from what identity federation (or, possibly, access federation) folks might have in mind, but is very interesting. OTA does good work. If anyone is interested to reach out to them in a more formal fashion around UMA synergies, or would like to coordinate on comment collection, let me know. Eve > Begin forwarded message: > > From: Joni Brennan <joni(a)kantarainitiative.org> > Subject: [KI-LC] Of Possible Interest - OTA IoT Trust Framework Public Review > Date: 21 August 2015 at 12:26:51 PM PDT > To: "LC(a)kantarainitiative.org" <LC(a)kantarainitiative.org> > > Dear LC - the Online Trust Alliance has put out a IOT Trust Framework for public review. I believe the paper is 5 pages (for a send of the scope of review). > > OTA has invited Kantara to comment on the paper. > > https://otalliance.org/iot-trust-framework-submission <https://otalliance.org/iot-trust-framework-submission> The deadline is Sept 14th. OTA would be happy to provide your members a briefing or webinar. > > If WGs / DGs have particular interest we are happy to review organizational liaison opportunities as well. > > Best Regards, > > Joni Brennan > Kantara Initiative | Executive Director > email: joni @ kantarainitiative.org <http://kantarainitiative.org/> > > Connecting Identity for a more trustworthy Internet - Overview <http://www.slideshare.net/kantarainitiative/kantara-overview2014-37969351> > > > > _______________________________________________ > LC mailing list > LC(a)kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/lc Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Greetings
by Nick Roy 21 Aug '15

21 Aug '15

Hello, UMAnitarians, This is a quick note of self-introduction. My name is Nick Roy - a few of you know me from InCommon stuff. I'm a technical director at InCommon, and I started working there in early June. Before that I worked in identity management at Penn State and The University of Iowa. I'm interested in UMA for a few reasons. We're looking at how it fits in to a consent manager that Ken Klingenstein is working on, and I'm personally interested in OpenID Connect for its usefulness in delegation, mobile apps, and API authorization. Best, Nick -- Nick Roy Director of Technology and Strategy, InCommon Internet2, Denver (GMT -6:00)

1 0

Text affecting #163 (public info), #164 (error code returned) -- and even #168 (ticket in JSON)?
by Eve Maler 21 Aug '15

21 Aug '15

In discussing how to implement our decision on issue #163 last week for how to add the WWW-Authenticate header to success responses in addition to error responses when the client presents no access token, we realized that: 1. The API correctly might want to return 300-class responses in addition to 200-class responses (that is, it’s entirely up to the API what “success” means for it). 2. As long as the response contains the WWW-Authenticate: UMA header and the relevant AS location and ticket info, we don’t much care what HTTP status code is used, because this is enough to tell the client what to do next. 3. If we broaden the text to allow any status code at all instead of 403, it’s sort of non-breaking (barring the “other responses by 403 are undefined” wording that’s in there now) — noting that this also allows a 401. (Hello, issue #164. :-) This resulted in the following wording: https://github.com/KantaraInitiative/wg-uma/commit/b784e6c33e45c02b267ad6b2… “It SHOULD respond to the client with a response that MUST include the "WWW-Authenticate" response header field with the authentication scheme "UMA", providing the authorization server's URI in an "as_uri" property in the header, along with the just-received permission ticket in the body in a JSON-encoded “ticket” property.” - What do we think of this wording? - If we like this wording or something similar... 4. Once we got to this point, I felt increasingly uncomfortable with leaving issue #168 to a later major version because of point no. 1. It’s crystal-clear that the API (which could just be a web app) might want to return a web page or a graphic or whatever. How do you return a JPEG along with a JSON body with a ticket in it? This issue seems not just “critical”, but “blocking”. The downside seems large, the upside seems large, and it seems like a low-impact change to the spec and implementations. The discussion in that issue seemed to be going in the direction of returning the ticket as part of the WWW-Authenticate header. - Are we willing to choose a “breaking” solution along these lines in the patch release? - If we’re not, would we be interested in a “non-breaking” solution along the following lines? “SHOULD provide the ticket in ticket=“ticket-value” in the header, or in the body in a JSON-encoded "ticket” property but the latter is deprecated”. Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

2 6

Issues
by Maciej Machulak 20 Aug '15

20 Aug '15

Hi all, Since we have not covered all the issues today, I include links to commits. Some were not yet covered - e.g. 172. Please review if you have a chance prior to the next call. https://github.com/KantaraInitiative/wg-uma/commit/c66e54a2ff435d4f3c1c1d97… https://github.com/KantaraInitiative/wg-uma/commit/05461d2a45defc9c65c0e1b5… https://github.com/KantaraInitiative/wg-uma/commit/8b99c122a38779733101b06f… https://github.com/KantaraInitiative/wg-uma/commit/1196c74190c87a4dbb0597e8… https://github.com/KantaraInitiative/wg-uma/commit/5c76f22d043bc99109cfef53… Also 1 comment: https://github.com/KantaraInitiative/wg-uma/issues/146 Cheers, Maciej -- Maciej Machulak email: maciej.machulak(a)gmail.com mobile: +44 7999 606 767 (UK) mobile: +48 602 45 31 66 (PL)

1 0

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

20 Aug '15

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-20 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-20> Minutes Roll call Quorum was reached. Minutes approval tbs Trust elevation TC writeup reviews and trust elevation/ABAC generally Andrew wants a half-page, and it's hard to keep it that short! Please review and shorten. Is the permission ticket an essential concept for trust elevation, or not? Step-up authentication is one mechanism; non-uniquely identifying, but nonetheless trusted, claims are another that seems special to UMA ("CBAC"). There's a conversation <http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20150810/0056…> going on about the role of software statements and OIDC in trust elevation. Mike has been following this. NIST has an ABAC "building block" under review; Bill Fisher has reached out to offer a conversation with UMAnitarians. Eve will coordinate. Restricting GitHub editing Do we need to worry about this? The upside is total IP protection. The downside is the pain of making all WG participants get GitHub accounts (a pain to the people) and become collaborators on the repo to submit GitHub issues (a pain to the repo admins). Current sensibility is positive. Legal subgroup report We've been in massive use-case collection mode. The APAC sync folks had interest and asked about the big thread. We hope to start mappings to legal concepts very soon. Andi expresses a hope that specific jurisdictional legal requirements won't impact the specs. E.g., US healthcare examples often don't apply to UK and Europe. Adrian would like to focus at some point on adoption strategy, apart from specific legal strategy. We can cast our eye over lessons learned and release strategy. Issue resolution work We cleared about half the outstanding items in the spreadsheet and in the issues list. AI: Maciej: Tweak spec text related to #147, #170, and #172, and close issues as appropriate. AI: Eve to send email to WG links highlighting newly proposed #163 text, which impacts #164 as well; WG to discuss before next week. AI: Eve to send email to WG discussion topic around #168; WG to discuss before next week. AI: Maciej, Eve, and Andi: Do issue assignments before next week. 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 Arlene Mike Maciej Thomas François Non-voting participants: Adrian James Sarah Scott Jin George Regrets: Mark Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Notes from APAC-friendly UMA WG sync 2015-08-20
by Eve Maler 19 Aug '15

19 Aug '15

Attending: Eve, Gil, Allan, Colin Agenda: - "The very long thread” on legal use cases Eve was driving at “negative use cases”, to get at the points where things go wrong and legal experts are needed. E.g., what happens if Bob gets access outside Alice’s stated policy? Mark is intending to map use cases to consent receipts. Adrian is keen to explore Alice-run/built AS variants. - UMA release schedule update We have all hands on deck for working on the patch release, and we’re on track for our stated timeline. We refactored the non-backlog issue list. - UMA Dev update Save the date: A kickoff call is planned for that WG on Sep 9 (in APAC time zones). - GitHub repo hygiene Eve is thinking about requiring collaborator status to submit GitHub issues (that is, “closing" the repo). Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Legal Use Case - User Managed vs. Controlled Access
by Mark Lizar 19 Aug '15

19 Aug '15

Pushing the penny forward an inch. As a follow up to the MVCR, there are it seems, some legal considerations that surround the application of policy in terms of what takes precedent, the privacy policy, the terms of use policies. As well, liability around who owns, controls and manages the data is also critical and needs to be clear. T A simple way to start putting this all together is to look at applying the MVCR roles ( that are anchored in ISO 29100 “roles") as an overlay to Adrian's (and any other) UMA use cases to address the legal questions and topics that arrise. To get things going here are a couple of items and their flows for the legal eagles. . A. Data Rights Ownership; User Managed Access Vs. User Controlled Access. (see use case below) B. Are T&C’s subjected to a Privacy Policy? Does the legal chain of authority that leads to the provisioning of roles and privileges, for access to personal attributes, start with the privacy policy for enrolment, then the terms and conditions? For example: 1. In the MVCR their is an undiscussed assumption that the privacy policy which provides the consent is counted as the primary contract for the use of personal information so the service provider may then use the personal information. At which point, The service provider uses the PI provided with the consent and then enrols the service user with a secondary policy, the terms and conditions, which Alice needs to contractually abide by, to use the service. As the requirement for a privacy policy and consent is legal infrastructure, and the T&C’s is organisation specific, the T&C’s are subjected to the privacy policy. i.e. legal requirements trump the business requirements in a court of law. 2. In regards to the above Issue 2 . What are the legal connotations - I.e. If a user blocks access to a PII resources (using EU law), the terms for that service might be that the service is stopped. But, the user may be required by the contract to keep paying for that service according to the contract and licence agreed too, and the service may be legally required to keep the user data while still charging for the service. (of course this is over simplified) i.e. the org indemnifies themself by give the functionality to users to manage the access to a copy of the user data the org controls. But in a very privacy by design way. The point being, this would appear to be different UMA Legal Flows than the user (in control of her own data) licensing access to the use of an attribute using UMA, which seems to me, like a different legal flavour of UMA all together. (closer to the UMA Health Flow) I.e.. Alice can turn on and off access to all or just a single attribute at any time in any scoped context. 3. Legal Flow/Use Case: User Managed Access Vs. User Controlled Access. UMA profile that is of two flavours Flavour A. Alice controls access to her own PII, authorises access using UMA to personal profile Flavour B. Alice Manages Access to her own PII . Using UMA installed behind a company siloed (and own Company copy of PII that the user maintains) that runs UMA so users can have more functionality through this silo. Note: this is the difference between the user being the data controller or the user being the data subject. Who controls and owns the data rights? if the service user is also the data controller, then data protection and privacy laws are effected in that the liability and policy for protecting the data lies with the service user, and the liability or contract/license for the usage of the data lies with the company. - this would be a different policy structure, with a consent directive and UMA, for orgs to agree too. Like a Personal Privacy Policy (PPP) to cover the different liability. liability of being a data controller no longer applies the same way as data protection liability is moved (reduced, or changed into another form) if the data subject is owner/controller of the data and its access. For Example: A good example here is in health care where consent directives and laws and frameworks are mature. (i.e. consent and access controls are being bound together already) With Flavour A, Alice Owns and Manages PII, gets to see how many times her personal data (medical records) were accessed, when and by whom Flavour B, Alice, gives away PII - that is already under the T&C’s of service, and owed by the company or institution. in the second circumstance she does not get to see how many times her data was accessed or even what the live status is of her active consents and medical data usage, unless she pays a fee to the Experian like company that owns them. With the MVCR based authorisation log Alice knows that her permission and access to her data should line up to the purpose of the sharing, the permission to access data, and the specified purpose of the active consent the company now maintains for her This would be a very helpful tool for alice to quickly understand medical sharing policies Without clarity between UMA Flavour A & B, does UMA have the opportunity to be : incredibly good (the good guys), because Alice is in full control of their own data incredibly bad, because Alice thinks she has control of a copy of their data. Or that another service provider, that she is forced to trust, has her best interests at hear. should their be a different flavour of UMA (in terms of legal considerations) that designates between A & B? Can their be a flavour of UMA that is both A&B? The MVCR - Binding A & B Together A consent receipt is being developed as a tool that will help bind consent and legal requirements to access roles and policy rules for sharing data. The MVCR is designed to make explicit the policies and notice requirements to make binding these together legitimate and understandable - i.e. this can be used to tie the role of data subject to the liability of access controls and vice versa For example the various frameworks that are used in the space of consent and access control can be added to a receipt. In this scenario, we would see Alice is at a hospital in the US Alice consents to provide PII to hospital for medical treatment Alice gets a consent receipt On receipt is UMA Icon and a HIPPA icon linked to legal requirements, or maybe just a field for a URI that links directly to the PPP, which has all the links and info needed for Alice’s medical records and consent directives (from her AS) Every test or comment can be then linked to her PPP and available for the next health data context This receipt under info sharing would have the PPP Icon, the HIPPA TrustMark icon, and the UMA icon all linked to the audit, enforcement and complaint processes that all of these frameworks require. In parallel to the US health System The UK’s heath care system is the reverse and has the same problems but for different reasons it is a universl health care system, where it costs the infrastructure money to provide medical services. (as oppose to the US) where the infrastructure makes money by providing medical services. In the UK you (the patient) are unable to see if you have consented to sharing PII, with whom you have shared, what medical records you have with Sensitive Medical Data spread on computers ranging from win 95 and up. An UMA enabled doctors office in the UK should be able to receive consent, use the medical data from the US and provide seamless service. So how would a consent receipt look like if it was used to bind ths A Consent Receipt extend the MVCR by: Adding UMA Framework Adding PPP (Personal Privacy Policy: Like a Consent Directive) police requirements Adding HIPPA: Add UK Jurisdiction profile and Medical PII profile to the consent requirements, add these processes at point of consent or enrollment at UK health care centre. These might all appear as ICONS of the above listed to the receipt and managed by 3rd parties operating the trust frameworks for the above elements. Mark > On 10 Aug 2015, at 18:36, Dazza Greenwood <dazza(a)civics.com <mailto:dazza@civics.com>> wrote: > > Ok Eve, I'm on it. Looking forward to see the negative cases. > > Hi Mark, do you have any additional use cases to consider? > > Thanks, > - Dazza > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ > | Dazza Greenwood, JD > | CIVICS.com <http://civics.com/>, Founder & Principal > | MIT Media Lab, Visiting Scientist > | Vmail: 617.500.3644 > | Email: dazza(a)CIVICS.com <mailto:dazza@CIVICS.com> > | Biz: http://CIVICS.com <http://civics.com/> > | MIT: https://law.MIT.edu <https://law.mit.edu/> > | Me: DazzaGreenwood.com <http://dazzagreenwood.com/> > | Twitter: @DazzaGreenwood > | Google+: google.com/+DazzaGreenwood <http://google.com/+DazzaGreenwood> > | LinkedIn: linkedin.com/in/DazzaGreenwood <http://linkedin.com/in/DazzaGreenwood> > | GitHub: github.com/DazzaGreenwood/Interface <http://github.com/DazzaGreenwood/Interface> > | Postal: P.O. Box 425845 Cambridge, MA 02142 > | _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > On Mon, Aug 10, 2015 at 3:44 PM, Eve Maler <eve(a)xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote: > Hi Dazza— Please feel free to send links and updates to the list. I have an action item to work on additional use cases (“negative” ones), and health use case patterns definitely aren’t the only ones we want to consider (nor am I positive that Adrian has captured all of those). Mark may want to contribute some too. And we probably want to spend more than one week on reviewing and understanding them. :-) > > Eve > >> On 10 Aug 2015, at 12:12 PM, Dazza Greenwood <dazza(a)civics.com <mailto:dazza@civics.com>> wrote: >> >> Update - As promised, I put the draft mission, use cases and other background materials on the current GitHub wiki and am UMA-customizing a basic "how to use GitHub issues and wiki pages - for lawyers" faq. >> >> Are the use cases from Adrian solid enough to work on and reflect the business case(s) you need to focus on? Also, do these use cases correctly and completed highlight the UMA functions and flows or is anything off base, incomplete etc? >> >> Anything else needed before next meeting? Should probably send links and ask people to contribute or think about something. Minimally, I'd suggest maintaining some focus on the use cases for now, to ensure an apples to apples anchor for legal conversation and to provide a double check basis for mapping stuff people say from legal to tech and vice versa. >> >> Thanks, >> - Dazza >> >> | Sent from my iPhone >> | Please Forgive Typos >> _________________ >> | Dazza Greenwood, JD >> | CIVICS.com <http://civics.com/>, Founder & Principal >> | MIT Media Lab, Visiting Scientist >> | Vmail: 617.500.3644 <tel:617.500.3644> >> | Email: dazza(a)CIVICS.com <mailto:dazza@CIVICS.com> >> | Biz: http://CIVICS.com <http://civics.com/> >> | MIT: https://law.MIT.edu <https://law.mit.edu/> >> | Me: DazzaGreenwood.com <http://dazzagreenwood.com/> >> | Twitter: @DazzaGreenwood >> | Google+: google.com/+DazzaGreenwood <http://google.com/+DazzaGreenwood> >> | LinkedIn: linkedin.com/in/DazzaGreenwood <http://linkedin.com/in/DazzaGreenwood> >> | GitHub: github.com/DazzaGreenwood/Interface <http://github.com/DazzaGreenwood/Interface> >> >> On Aug 10, 2015, at 2:59 PM, Eve Maler <eve(a)xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote: >> >>> I created a (really huge) swimlane and a pro/con list, and a bit more... I ended up writing a recommendation. You can find the whole thing linked from here: >>> >>> https://docs.google.com/document/d/1OsIqPbVNx66vypnCzjxoFjX0AHCD_rEmgP8Q-5h… <https://docs.google.com/document/d/1OsIqPbVNx66vypnCzjxoFjX0AHCD_rEmgP8Q-5h…> >>> >>> Eve >>> >>> Eve Maler | cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com <mailto:xmlgrrl@gmail.com> >>> >>> _______________________________________________ >>> WG-UMA mailing list >>> WG-UMA(a)kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> >>> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma> > > > Eve Maler | cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com <mailto:xmlgrrl@gmail.com> > >

4 12

Agenda for UMA telecon 2015-08-20 (those with assignments, please do them...)
by Eve Maler 19 Aug '15

19 Aug '15

See the spreadsheet for assignments and which ones I’m hoping we’ll knock down on Thursday. Thanks! http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-20 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-20> Date and Time Thu Aug 20 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-13 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-13>. Last-minute quick hits Trust elevation TC writeup reviews Legal subgroup report APAC sync report 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…>) Our timeline has us trying to knock down all of our issues by this week and next Then approving our Draft Recommendations for next-stage LC approval the following week or so AOB Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Fwd: NCCoE Seeks Collaborators for Access Control, PIV, and Mobile Device Security Projects
by Adrian Gropper 18 Aug '15

18 Aug '15

The ABAC one-pager mentions UMA by name. https://nccoe.nist.gov/sites/default/files/ABAC.pdf We're in the big leagues! Happy weekend, Adrian ---------- Forwarded message ---------- From: *National Cybersecurity Center of Excellence* < nccoe(a)service.govdelivery.com> Date: Friday, August 14, 2015 Subject: NCCoE Seeks Collaborators for Access Control, PIV, and Mobile Device Security Projects To: info(a)healthurl.com Today's Federal Register contains notices inviting technology vendors to collaborate with the National Cybersecurity Center of Excellence on three new projects to provide mobile device security, attribute based access control, and derived personal identity verification (PIV) credentials for mobile devices. Commercially available and open source products will be the modules in end-to-end example solutions to these challenges. All collaborators will enter into a Cooperative Research and Development Agreement (CRADA; see an example <http://links.govdelivery.com:80/track?type=click&enid=ZWFzPTEmbWFpbGluZ2lkP…>) with NIST in order to participate in a consortium for each build team. The projects will result in NIST Cybersecurity Practice Guides that show organizations how they can adopt these or similar capabilities. Companies with product characteristics that meet the desired characteristics in the Federal Register notices can submit letters of interest indicating that they'd like to work on one or more of these projects. Each Federal Register notice contains instructions for how to submit a letter of interest. Project pages and Federal Register notices can be found at: - Mobile Device Security Building Block <http://links.govdelivery.com:80/track?type=click&enid=ZWFzPTEmbWFpbGluZ2lkP…> - https://federalregister.gov/a/2015-20040 <http://links.govdelivery.com:80/track?type=click&enid=ZWFzPTEmbWFpbGluZ2lkP…> - Attribute Based Access Control Building Block <http://links.govdelivery.com:80/track?type=click&enid=ZWFzPTEmbWFpbGluZ2lkP…> - https://federalregister.gov/a/2015-20041 <http://links.govdelivery.com:80/track?type=click&enid=ZWFzPTEmbWFpbGluZ2lkP…> - Derived Personal Identity Verification Building Block <http://links.govdelivery.com:80/track?type=click&enid=ZWFzPTEmbWFpbGluZ2lkP…> - https://federalregister.gov/a/2015-20039 <http://links.govdelivery.com:80/track?type=click&enid=ZWFzPTEmbWFpbGluZ2lkP…> To learn more, read the NIST press release <http://links.govdelivery.com:80/track?type=click&enid=ZWFzPTEmbWFpbGluZ2lkP…> . SUBSCRIBER SERVICES: Manage Preferences <http://links.govdelivery.com:80/track?type=click&enid=ZWFzPTEmbWFpbGluZ2lkP…> | Unsubscribe <http://links.govdelivery.com:80/track?type=click&enid=ZWFzPTEmbWFpbGluZ2lkP…> | Help <http://links.govdelivery.com:80/track?type=click&enid=ZWFzPTEmbWFpbGluZ2lkP…> ------------------------------ If you have questions or problems with the subscription service, please contact subscriberhelp.govdelivery.com <http://links.govdelivery.com:80/track?type=click&enid=ZWFzPTEmbWFpbGluZ2lkP…> . Technical questions? Contact inquiries(a)nist.gov <javascript:_e(%7B%7D,'cvml','inquiries(a)nist.gov');>. (301) 975-NIST (6478). This service is provided to you at no charge by National Institute of Standards and Technology (NIST). 100 Bureau Drive, Stop 1070 · Gaithersburg, MD 20899 · 301-975-6478 [image: Powered by GovDelivery] <http://links.govdelivery.com:80/track?type=click&enid=ZWFzPTEmbWFpbGluZ2lkP…> -- Adrian Gropper MD RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

4 4

Trust Elevation Model for OASIS Trust-El TC
by Mike Schwartz 18 Aug '15

18 Aug '15

UMA WG, Here is the copy I worked up per Andrew's request on the trust-el model for UMA: https://docs.google.com/document/d/1nRrQe9U0EiQpibYnUl-uYFW92LSRcegQfsQ6kfv… Andrew only wanted 1/2 page, so I tried not to get to lost in the details (i.e. that's why I didn't mention the permission ticket...) Anyway, if its so summary as to be misleading, any suggestions are welcome! - Mike ------------------------------------- Michael Schwartz Gluu Founder / CEO mike(a)gluu.org

1 0

Reminder: APAC-friendly UMA sync 2015-08-20
by Eve Maler 18 Aug '15

18 Aug '15

Thu Aug 20 at APAC-friendly times Voice: Skype: +99051000000481, room code 178-2540# Screen sharing: http://join.me/findthomas <http://join.me/findthomas> - NOTE: IGNORE the join.me <http://join.me/> dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) See the UMA calendar for additional dial-in and timing details (e.g., in the Pacific time zone the call will be held on 2015-08-19): http://kantarainitiative.org/confluence/display/uma/Calendar <http://kantarainitiative.org/confluence/display/uma/Calendar> If you wish to be added to the calendar invitation, send a private message to me. The standing agenda is to review recent WG progress, collect participant feedback, check on action item status, and attend to any other relevant business. Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

UMA Legal - Release of Information (ROI) Form
by Adrian Gropper 17 Aug '15

17 Aug '15

The ROI form is one of the three common legal documents in healthcare. (The other two are the Notice of Privacy Practices that's a meaningless and often unsigned notification about HIPAA and informed consent notices for specific procedures. ) The ROI form (attached) is quite typical and demonstrates all of the common elements. I've annotated it with the UMA terms. Jim Hazard and I have some experience translating the ROI form into the Common Accord format. I see the ROI form as the institutional complement to the 4 use-cases I shared last week. The use-cases were presented entirely from Alice's perspective. The ROI form is presented entirely from the service provider perspective. There is, of course, a third dimension: the third parties and intermediaries in the real world that have contractual relationships with Alice and her service provider. These are sometimes called Business Associates in healthcare and sometimes overlap with federations. Alice's third parties often look like software clients and apps. Adrian -- Adrian Gropper MD RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

2 2

Notes from UMA legal subgroup telecon 2015-08-14
by Eve Maler 14 Aug '15

14 Aug '15

Attending: Eve, Jon, Dazza, Mark, Tom, Adrian, Jeff S The wg-uma GitHub area has a wiki <https://github.com/KantaraInitiative/wg-uma/wiki> that Dazza has been populating. 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?) We walked through the UMA FAQ descriptions of the UMA flow. An autonomous web service client can often be in a data broker role: an institution where the RO doesn’t have a login. What about where “data rights ownership” resides in multiple parties? UMA the technology settled on a simplification where only a single entity (meaning a hunk of software or operator of same) can be an RO. But in reality, multiple parties (meaning persons or non-person entities that can do things like sign contracts) could have rights. Adrian says “There’s only one Alice”. Are we focusing exclusively, or primarily, on “Alice” use cases? UMA was originally intended to focus first and foremost on the individual as an RO, which is why our BO spec <https://docs.kantarainitiative.org/uma/draft-uma-trust.html> points to NSTIC (while slightly debugging its definition of Individual). Action item/issue: We should circle back around to revising the definitions of party/entity/role etc. Look at the BO spec <https://docs.kantarainitiative.org/uma/draft-uma-trust.html> for background. The notion of data sharing with third parties is not very well covered in law, so UMA is significant in this area. The proposed EU Data Protection Law revisions do seem to have some relevance here, though. And this is where Consent Receipts are also relevant. Dazza suggests that the ISO 29100 statutory privacy roles <https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Use-Cases,-Role…> have relevance here, but Adrian isn’t so sure. Analysis of Alice-to-Alice N use case: The OAuth model is “pairwise” between each service and client app. UMA, by contrast, allows Alice to aggregate the records of all of her consents (and ultimately receipts of her consents). “Accounting for Disclosures” (A4D) is a HIPAA term of art; think of this just as a record of the consents, not as the “CDC" point. Ultimately, the use cases can blend; each is just meant to highlight a few aspects of desired features but they’re not mutually exclusive. How would we map the people and organizations named to roles? Would one of the EHRs be something like a Microsoft HealthVault? Where would a physician come into play? Adrian has kept PCPs and personal health records (PHRs) out of this use case for simplicity. Adrian’s “Release of Information” (ROI) form goes into detail about the “who to sue” question. In the US, frequently a PCP has a hospital affiliation, and the hospital uses a SaaS product run by an EHR vendor like Cerner. Eve has a login to evergreenhealth.cerner.com <http://evergreenhealth.cerner.com/>. She can use the (proprietary but UMA-like) portal to share the allergy portion of her health record with her husband. In this case, Cerner is a “Business Associate” of the institution. What Eve calls “figuring out who to sue” is what the pros would call “structuring the transaction”. When using a standard that allows multiple parties to hook up and use others for authorization, this is the goal. Next time: Accelerating on the use cases, and mapping to consent receipts, given our deeper understanding. Today counts as excellent progress — thanks, all! Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

2 1

UMA Legal - Mapping Roles
by Mark Lizar 14 Aug '15

14 Aug '15

Dazza and I were chatting about how roles might map between UMA and the MVCR, (which references roles from ISO 29100). We thought this might be useful in providing a place to start. - Mark Extracted from Binding Obligations Requesting Party Resource Server Operator Authorization Server Operator Authorizing Party Statutory Privacy Roles Extracted from ISO 29100 2.11 PII controller entity (or entities) that determines the purposes and means for processing PII other than individual persons who use data for personal purposes NOTE A PII controller sometimes instructs others (e.g., PII processors) to process PII on its behalf while the responsibility for the processing remains with the PII controller. 2.12 PII principal natural person to whom the PII relates NOTE Depending on the jurisdiction and the particular data protection and privacy legislation, the concept of a “PII principal” may also be defined as a “data subject”. 2.13 PII processor entity that processes PII on behalf of and in accordance with the instructions of a PII controller 2.26 third party an entity other than the PII principal, the PII controller and the PII processor, and the persons who are authorized to process the data under the direct authority of the PII controller or the PII processor UMA Healthcare Use Case Roles Extracted from Adrian's use cases Alice Bob EHR-1 Operator EHR-2 Operator PCP (Primary Care Provider) Custodian 3.1.1 Extrapolating from Existing Legal Scenarios"

1 0

UMA Specifications @ GitHub
by Maciej Machulak 13 Aug '15

13 Aug '15

Hi, The specs now have a new home - please updated your bookmarks :-) https://github.com/KantaraInitiative/wg-uma Cheers, Maciej -- Maciej Machulak email: maciej.machulak(a)gmail.com mobile: +44 7999 606 767 (UK) mobile: +48 602 45 31 66 (PL)

2 1

OASIS Trust-El TC UMA description
by Mike Schwartz 13 Aug '15

13 Aug '15

Andrew, Per the WG minutes, I'd be happy to write up a description of the trust elevation features of UMA. - Mike ------------------------------------- Michael Schwartz Gluu Founder / CEO mike(a)gluu.org

1 0

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

Completing my action item on issues 153 and 154 (RPT->token and AAT->nothing)
by Eve Maler 10 Aug '15

10 Aug '15

I created a (really huge) swimlane and a pro/con list, and a bit more... I ended up writing a recommendation. You can find the whole thing linked from here: https://docs.google.com/document/d/1OsIqPbVNx66vypnCzjxoFjX0AHCD_rEmgP8Q-5h… Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 1

Fwd: Draft minutes of UMA telecon 2015-08-06
by Maciej Machulak 07 Aug '15

07 Aug '15

---------- Forwarded message --------- From: Maciej Machulak <maciej.machulak(a)gmail.com> Date: Thu, 6 Aug 2015 19:44 Subject: Re: [WG-UMA] Draft minutes of UMA telecon 2015-08-06 To: Allan Foster <allan.foster(a)forgerock.com> Allan, My 2 cents: 1) There is a proposal considered not to use this endpoint but just token endpoint (it's not fully accurate but good enough - the user endpoint can still be used in trust elevation) 2) Bob is not asked for consent to allow the client to provide specific claims to AS. It was just uma_authz scope. Maciej On Thu, 6 Aug 2015 19:29 Allan Foster <allan.foster(a)forgerock.com> wrote: > In the discussion there was talk of the new flow, and how we get Bob's > consent. > > It came to me that we are only talking about using the token endpoint, at > the moment. In order to collect claims about Bob, wouldn't we need to use > the User Endpoint? > > If so, this should happen early in the flow, and is where the actual > consent can be captured > > > Allan > > > > > On 8/7/15 1:05 AM, Eve Maler wrote: > > 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) > > 1. Eve > 2. Andi > 3. Irwin > 4. Domenico > 5. Maciej > 6. Robert > 7. Mike > 8. Arlene > 9. 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 > > > > _______________________________________________ > WG-UMA mailing listWG-UMA@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/wg-uma > > > _______________________________________________ > WG-UMA mailing list > WG-UMA(a)kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/wg-uma >

3 3

Notes from UMA legal subgroup telecon 2015-08-07
by Eve Maler 07 Aug '15

07 Aug '15

Attending: Eve, Scott, Adrian, Dazza, Jon, Mark, Jim, Thomas, Tim Our schedule and deadline are meant to be a forcing function to align with UMA V1.0’s and V1.0.1’s needs. Eve read the draft mission statement in italic: Develop recommendations about resource owner-and-requesting party [Alice-and-Bob], resource server-and-authorization server [service-and-hub], and any other transactional relationships in the UMA environment, keeping in mind international jurisdictional friendliness; applicability to many different vertical and horizontal use cases, including health; and support of higher-level access federation trust frameworks and similar efforts. What does “transactional” mean here? It’s probably not a term of art, just a word. Scott could see substituting “interaction”, but it’s not strictly necessary. Transactions imply some formalism. When you have intermediation without being able to monitor the transaction fully, you have a problem. He has seen problems in supply chains where there are no measurements the middle. Reliability is a goal. The parties and intermediations need to be listed and understood. Eve described the overall goal of the exercise, from her perspective, is giving comfort to those interested in deploying UMA — in any size of “cloud” — that any sets of parties involved who have misaligned interests can nonetheless have enforceable and predictable ways to do it. Adrian’s take is a little different, but related: For those parties in a potential ecosystem who are *not* interested, he wants to create some kind of “safe harbor” that shifts liability appropriately away so that they will be willing to play along. He thinks these will be the resource servers in healthcare. Scott says this is two ways of expressing the same thing. Liability is just cost. Standardization of result, such as standard contracts, is one of the ways, to reduce such costs. Accelerate adoption! Reduce inhibitors! Dazza notes that the UETA, with the essential notion of actors and actions, is relevant. At the end of the day, you may have hundreds of intermediaries. A good place to start is the use cases, such as those Adrian sent. The selection of use cases inherently surfaces the parties of interest to us, and sets the prevailing context. Enumerating the transactional relationships is something we’ll have to do. What would deliverables look like to meet these goals, in order to be most effective? It may be too early for this. What makes a good use case? Generic UMA use cases count, as well as “things going wrong” use cases. These are like the “negative tests” in software testing. And we need success and failure conditions. In fact, all of the warnings you see on consumer goods are the result of something having gone wrong. (“Do not use this toaster while sleeping.” Samples: http://idiot-dog.com/disclaimer.html :-) Mark notes that the MVCR (Consent Receipt) work is getting to V0.7. There are some strong relationships here. Consent receipts are a species of transaction receipt, and since UMA is bristling with transactions, there are a lot of opportunities for receipts. If you add consent (a consent record) to a transaction, you can bind them. Adrian connects this to his use case that mentions “accounting for disclosures”, which Alice would want to hang onto for dear life, since it’s the only evidence that her data was shared — similarly to a confirmation number received when travel plans are changed. The correspondence to the logs of the servers where their own liability gets protected is a key element. Mark remarks that different UMA scenarios along the lines of “who owns the data” (at the resource server) may be an important dividing line. Adrian dislikes “data ownership”, other than RTBF. Scott thinks “data ownership” is a nonstarter, but “data rights ownership” could be workable. Next steps: - Anoint Dazza our GitHub wiki master — thank you, Dazza! - Begin use case collection and label them on wiki with “legal-*” labels for emergent categorization . AI: Eve, Adrian, and Mark especially: Contribute starter use cases . AI: Dazza: Explain in email how we engage on the wiki - Agenda for next time: . Remedial UMA flow explanation . Use case discussion and logging/receipts and data rights ownership . Licensure vs. contract Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Reminder: UMA legal subgroup telecon 2015-08-07
by Eve Maler 06 Aug '15

06 Aug '15

Fri Aug 7 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> We’ll get to know each other and mission-bash (see the previous message on that here <https://groups.google.com/forum/#!searchin/kantara-initiative-uma-wg/missio…>). Looking forward! Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Reminder: 90min WG August meetings start a half-hour early...like 20 minutes from now
by Eve Maler 06 Aug '15

06 Aug '15

If you have a Skype handle, aren’t yet in our UMA Chat thread, and want to be there for meeting start reminders, ping me at “xmlgrrl” and I’ll add you. Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Notes from APAC-friendly UMA WG sync 2015-08-06
by Eve Maler 06 Aug '15

06 Aug '15

Attending: Eve, Allan, Colin, Paul, Gil, Nat The NZ POC is proceeding, and “going better and better”. ==== Looking at issues 153 and 154: The two-token idea seems attractive. One subtle change is that the old RPT contains permissions for, at most, that RqP, that client, that AS, a single RS, and all the ROs at that RS, whereas the new access token would contain permissions for, at most, that RqP, that client, that AS, all the RS’s connected to that AS, and all the RO’s using the AS that the RS’s are connected to. So the new element is the multiple RS’s. Right! If the RS introspects the access token, it’s inappropriate for it to get back any portion of the token that is targeted at other RS’s. It turns out we had to go back to UMA Core rev 03, not rev 05, to find the old two-token “HAT/RAT” model that did this: https://tools.ietf.org/html/draft-hardjono-oauth-umacore-03#section-3.3 “The AM returns the token's status in an HTTP response using the 200 OK status code, containing a JSON document supplying the token status description. The token status description either contains all of the permissions that are currently valid for this requester access token at the host in question (and thus for the requesting party on whose behalf it is acting), or indicates that the token is invalid (see Section 1.4).” It seems to break the claims/JWT model somewhat to have to filter the results of token introspection. Is there an elegant way to solve it? Allan suggests a potentially elegant way. Could the AS only ever hand out (or upgrade) access tokens per RS? We already do have language in Core that has the “feel” of what we want to achieve: https://docs.kantarainitiative.org/uma/rec-uma-core.html#rfc.section.3.4 “If the client did not present an RPT in the request for authorization data, the authorization server creates and returns a new RPT. If the client did present an RPT in the request, the authorization server returns the RPT with which it associated the requested authorization data, which MAY be either the RPT that was in the request or a new one.” We could use this style of spec language to mandate that the authorization server MUST (or, as a privacy consideration, SHOULD?) issue new RPTs/access tokens. SHOULD seems way too weak. Nat points out that it’s a security leak as well, since it’s a bearer token. Nat observes that in OIDC, you have the same kind of constraint, so this seems like a reasonable way to handle the constraint. Naturally, we noted, whatever token profile you define, it has to be opaque to the client. ==== Looking at issue 165: We poked around at the various disconnects here: RS’s don’t know anything about clients, by design. On the other hand, clients are operated by parties who aren’t the resource owner, and are generally expected to “take what they get”. On the third hand, clients might be capable of working with only some subset of scopes, and know better than AS’s what they can handle. The requested-permission-and-ticket flow is a natural place that suggests itself for extension, either for client hints to the RS or client requests to the AS. Another possibility, suggests Allan, is for the client to have a completely new and additional way to construct tickets (or, said another way, to request permissions?) of its own directly. We didn’t take this too far — just “woke up the topic” a little. Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

2 3

Issues to be discussed in APAC-friendly sync and regular WG call: please read up
by Eve Maler 05 Aug '15

05 Aug '15

There’s a lively discussion going on in the GitHub issues. If everyone attending these meetings (and even *not* able to attend them) can please read up on issues 153, 154, and 165 at a minimum, and think, research, and comment as they see fit, we will be much better prepared to take action on resolutions. If you want to read ahead, issue 160 is also sitting there waiting for you. :-) https://github.com/xmlgrrl/UMA-Specifications/issues Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Agenda for UMA telecon 2015-08-06 (starts 30 minutes earlier, runs 90 minutes)
by Eve Maler 04 Aug '15

04 Aug '15

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-06 Date and Time Thu Jul 30 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-07-30 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-07-30>. Quick hits: APAC-friendly sync update Spec versioning process update Issue resolution work Goal is to discuss and resolve issues 165/153 (ranked #1) and issue 154 (ranked #2) – 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…> AOB Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0