- WG-UMA - mailman.kantarainitiative.org

All the latest on UMA on Wikipedia, in Italian
by Eve Maler 01 Sep '15

01 Sep '15

http://it.wikipedia.org/wiki/User-Managed_Access Thanks, Domenico! Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Reminder: APAC-friendly UMA sync 2015-09-03
by Eve Maler 31 Aug '15

31 Aug '15

Thu Aug 27 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-09-02): 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

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