February 2016 - WG-UMA - mailman.kantarainitiative.org

Notes from UMA legal subgroup telecon 2016-02-12
by Eve Maler 12 Feb '16

12 Feb '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes 2016-02-12 - If you have terminology comments, speak up; issue #240 is closed otherwise - Update on overall roadmap <http://kantarainitiative.org/confluence/display/uma/UMA+Roadmap+for+2016>: initial priorities settled; new #shoebox use case - #RSctrl, #ROctrl, and #shoebox use case are related; let's pick our highest-priority use case and specific set of clauses to work on, and work on them right now! (current clauses <http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative…>) (current relevant issues <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…> ) Attending: Eve, John W, Kathleen, Scott, Adrian, Mary, Jim, Ann Terminology Shall we leave this till we have specific needs? We agree that Individual is best, over something like Natural Person. (Meatspace person, bag of protoplasm, ugly bag of mostly water...) What about "data subject" and "PII subject" (which terms are defined in different standards)? We could refer to them from our Individual definition, or put them in a concordance appendix that is separate. Whether it's "next to" or "separate from" the definition text – and either could work in CommonAccord, because it could be modularized nonetheless, the question is whether we in this WG want to be responsible for keeping that text up to date. We've discussed that we don't want to be responsible for text that isn't UMA-specific. Jim notes that "any law firm that wants to make themselves useful" could keep up a text module like this. We would divest ourselves of any responsibility at all for the freshness or staleness of such text if we simply advised our model-text users of the existence of that third-party model text, rather than pulling it into our own model definition. It appears there are at least two companies that provide this sort of concordance, but they are paid services. Nymity (Toronto) and Privacy Guidance (UK) charge $10K/yr. "Model definition" is a good name for the specific kind of model text that contains a full term or abbreviation definition. If we want to put a "comment field" in any of these, what would be the purpose? It apparently shouldn't render in a "final" legal agreement; it should just be there to guide how a legal agreement builder should use the definition. *Not just about terminology but about "agency"* Is the RO always the data subject (etc.)? If elderly RO Alice gives access to her protected resources to adult child Bob to help her manage them, UMA makes him her RqP. How do we understand "agency" in this light? Note that UMA calls it "resource owner" only because OAuth does, and "ownership" is problematic as a term. "Resource controller" is more accurate, and it maps nicely to the old WG concept of the "split RO" problem. Note that we have introduced the Authorizing Party phrase on the legal side of our terminology to help get around the "owner" problem, which aligns nicely with the concept of who has the "authority" in each context. Scott introduces the "*legal capacity*" phrase. Every jurisdiction has a different definition of the point at which a natural person has it, and different kinds of health data are regulated in each jurisdiction. Sometimes legal capacity is down to age, and sometimes it's determined by other criteria. John mentions tests that a physician can perform to determine capacity. In the case of "aging-in" or certain other automatic types of capacity tests, if resources can have standard data taxonomies applied to them when RS's register the resources at AS's, then it might be possible for automatic policy changes to take place. Kathleen mentions that HL7 wants to use our deliverables for FHIR contracts. This is for its work coming out in September. They'd be interested in both the model definitions and the model definitions, for "substitute decisionmakers" – Alice would be the grantor, and Bob would be the grantee. In some other contexts, Eve has heard terms like subjects and delegates, and citizens and proxies, etc. *AI:* Adrian: Write up ROI form concerns wrt to UMA phase 1 implications for the group's consideration. Next up We need to ensure we have a very firm handle on the legal capacity in our terminology (and possibly clauses). And then we need to make good progress on our beta model text timeline, for all sorts of reasons (both IDE and customers). *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 2

Agenda for UMA legal subgroup telecon 2016-02-12
by Eve Maler 11 Feb '16

11 Feb '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes Date and Time - *Fridays,* 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 - *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 2016-02-12 - If you have terminology comments, speak up; issue #240 is closed otherwise - Update on overall roadmap <http://kantarainitiative.org/confluence/display/uma/UMA+Roadmap+for+2016>: initial priorities settled; new #shoebox use case - #RSctrl, #ROctrl, and #shoebox use case are related; let's pick our highest-priority use case and specific set of clauses to work on, and work on them right now! (current clauses <http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative…>) (current relevant issues <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…> ) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Notes from UMA APAC-friendly sync 2016-02-10
by Eve Maler 11 Feb '16

11 Feb '16

Attending: Eve, John W, Paul T, Colin - How did the ad hoc issue #239 meeting go? - Consent receipts and UMA - Budget requests - 2016 roadmap - #RSAC The ad hoc meeting today went great! We have a set of recommendations we hope the WG will come to consensus on, or if not that, something else reasonable. :-) There has been some discussion around potentially getting consent receipts and UMA closer together in various ways. At least when UMA is in use, it would be unfortunate to be forced to have to go out to a separate service to get a receipt. We've talked in the UMA group about incorporating (or colocating) a "shoebox" endpoint into an AS. Do we need to talk in the WG meeting tomorrow about a #receipt roadmap use case bucket? Let's hope Mark can join, and that Mark and Eve can finally have the chat they've been planning for a while. John will share information about Nat's work on ISO consent standards. Regarding budget requests, Eve has heard tell of a matching-funds opportunity (for the UMA-Dev WG proposal, not the UMA WG one) that she should talk to Colin and Ken about synchronously. We'll work out times in email. The Kantara board is meeting at #RSAC on Thursday March 3, 10am-2pm. Eve could join the board for lunch! (Mmm, sandwiches.) Also at #RSAC, Kantara is again one of the sponsors of the Non-Profits on the Loose event <https://www.rsaconference.com/events/us16/agenda/sessions/2376/non-profits-…>. Tell your friends! Gluu has put together a nice blog entry <https://www.gluu.org/blog/gluus-rsa-conference-2016-events/> with some Kantara, UMA, and Gluu events at and near the conference. Regarding our 2016 roadmap <http://kantarainitiative.org/confluence/display/uma/UMA+Roadmap+for+2016?sr…>, we can't do everything at once, but we've already made progress! (Congrats to Colin on the news he shared! ;-) ) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2016-02-11
by Eve Maler 10 Feb '16

10 Feb '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-11 Date and Time - *Thu Feb 11,* 9-10am 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 - *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 Agenda - Roll call - Approve minutes of UMA telecon 2016-01-07 <http://internetidentityworkshop.com/> - Kantara OTTO WG and how it relates to UMA (Mike) - Confirm initial use case prioritization (UMA Roadmap for 2016 <http://kantarainitiative.org/confluence/display/uma/UMA+Roadmap+for+2016>) in the whole-WG telecon series: 1. #security 2. #wideeco 3. #IoT 4. .... - Appoint a small contingent to look at revising our charter <http://kantarainitiative.org/confluence/display/uma/Charter> as required - Review the recommendations from our issue #239 ad hoc subgroup and decide on next steps - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Notes from ad hoc meeting to discuss issue #239
by Eve Maler 10 Feb '16

10 Feb '16

Attending: Eve, Andi, Sarah, Domenico, Justin, Mike, James, John W, Maciej, George (partial)? Thanks to the intrepid attendees of this ad hoc meeting series! *The progressive agenda for this meeting series:* 1. Analyze the nature of the vulnerability and the use cases at risk at the various time horizons (now/near-future/far-future) to be sure we understand its parameters 2. Analyze the proposed mitigations and see if there are any others we have missed 3. Assemble pros and cons for the mitigations and the forms in which they can be "packaged" to bring forward to the whole WG *NOTE:* We have renamed the issue to call it "Session Fixation Attack on UMA *Claims-Gathering* Protocol (UMA 1.0.1 Section 3.6.3)". This is because in the spec <https://docs.kantarainitiative.org/uma/rec-uma-core.html>, trust elevation encompasses all of the ways to test the RqP (and even the client) for suitability, including any extension mechanisms, not just claims-gathering. *Logistics:* We will hold a *short ad hoc meeting in the 30 minutes prior to Thursday's WG telecon*. We nearly got through agenda item 1b; the agenda will be to finish 1b, start 2a, and set up next week's ad hoc meeting schedule. We may be able to complete all the agenda items by next week at this pace. *AI:* Eve: Set up the next ad hoc meeting in the calendar. *1a. Analyze the nature of the vulnerability* The preconditions are laid out in the issue <https://github.com/KantaraInitiative/wg-uma/issues/239> in GitHub. Let's see if we can identify other "truths" in the scenario: - The nature of the grant flow that was used to mint the AAT is irrelevant to this attack. - We're assuming that the attack is possible even if only one of the two RqPs is compromised and nothing else (AS, client, etc.). This doesn't have to do with step-up authentication; there may be vulnerability dragons there, but they're not the same as this vulnerability. We talked about asking the guys who just formally analyzed OAuth 2.0 to analyze UMA too. *AI:* Eve: Reach out to the security researchers <http://arxiv.org/pdf/1601.01229v2.pdf> who analyzed OAuth. Recall that we are showing in our WSD <https://www.websequencediagrams.com/?lz=cGFydGljaXBhbnQgUmVzb3VyY2Ugb3duZXI…> two clients because the attacker uses either the same client or a different client with the same client ID, but with the same session that is able to compromise the existing permission ticket. The (persistent) permission ticket is usable by both pieces of software (or the "same" piece of software used by both victim and attacker). The attacker is able to phish the true RqP and substitute the true RqP in front of them as soon as interaction with an RqP is needed for any claims-gathering, and then substitute themselves back with the original permission ticket when it's time to "turn in the winning ticket to get the winnings" (get the RPT and then go on to access the resource). You're getting the legitimate winner Bob to present their ID as is proper to get their winnings, but at the last minute, Eve the Eavesdropper <https://en.wikipedia.org/wiki/Alice_and_Bob> swoops in and knocks the winning chit out of his hands and runs up to the counter. Here is a consolidated web sequence diagram (which will update whenever I make changes to it!) that reflects, I think, a current understanding of the attack. I've added a few comments, and some questions that we can ponder regarding additional potential mitigations. Many thanks to Justin for kicking off this flow. http://www.websequencediagrams.com/files/render?link=tQ9pVR17H-5H93gM2wzU *1b. Analyze the use cases at risk at the various time horizons* Eve's point in suggesting this topic is that it helps us figure out when and how to *potentially* apply tactical (less invasive/disruptive?) and strategic (more invasive/disruptive?) mitigations. One possibility: NOW........SOON........LATER (tactical?)...........(strategic?) This is necessarily a more subjective conversation because vulnerability is technical and risk is business-legal. Mike's deployment doesn't use interactive claims-gathering. It should be noted that he has deployed only #APIsec use cases. Which use cases are likeliest to use interactive claims-gathering? Justin has implemented for it. His use cases are cross-domain (#wideeco) and the human RqP is present and using a client app. He expects interactive claims-gathering. Eve and James are seeing imminent deployments where interactive claims-gathering isn't expected at first; this is because the human RqP experience is expected to be extra-smooth, and the client apps are either published by the operator of the AS or by close partners, and the first deployments are likely to use "hub-and-spoke" identity federations where the AS is also where the RqP's claims from. However, wider -- at least "medium" -- ecosystem deployments will eventually be on the scene. ...tbs: more to come... *2a. Analyze the proposed mitigations* ...tbs... *2b. Identify additional potential mitigations* ...tbs... *3. Assemble pros and cons for the mitigations and their "packages"* ...tbs... *(we should add this one too:)* *4. How to communicate about this attack and related information* ...tbs... *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 2

Reminder: APAC-friendly sync 2016-02-11
by Eve Maler 09 Feb '16

09 Feb '16

- *Thu Feb 11* at APAC-friendly times - Voice: Skype: +99051000000481, room code 178-2540# - Screen sharing: 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) - See the UMA calendar for additional dial-in and timing details (e.g., the call time = *Wed Feb 10 4pm PT*): http://kantarainitiative.org/confluence/display/uma/Calendar If you wish to be added to the calendar invitation, send me a note. If you wish to be added to our Skype chat group to receive reminders before I open the bridge, include your Skype handle. The standing agenda is to review recent WG progress, collect participant feedback, check on action item status, and attend to any other relevant business. Others besides those in APAC-ish regions are welcome to join. This sync series has been useful for some who have a standing conflict with our weekly WG calls. However, the sync series doesn't "count towards quorum" if you're a voting participant. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Ad hoc times for issue #239 discussion this week
by Eve Maler 08 Feb '16

08 Feb '16

The UMA calendar now shows the times we're meeting: - Wednesday 11am PT/1pm CT/2pm ET/7pm UK/8pm CET - Thursday during the half-hour after our normal WG telecon ends If you weren't added to the calendar invite and would like to be, let me know. Thanks! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Is the right to agency core to VRM and to UMA?
by Adrian Gropper 07 Feb '16

07 Feb '16

(Apologies for cross-posting but I think it's appropriate in this case) I'm a member of the hi:project http://hi-project.org/ (click 90 sec. video) Today's newsletter <http://hi-project.org/?wysija-page=1&controller=email&action=view&email_id=…> had interesting links to open banking API initiatives: > *" Retail banks*. Her Majesty's Treasury, ably supported by the Open Data > Institute, is progressing an open banking API > <https://www.gov.uk/government/consultations/data-sharing-and-open-data-in-b…>. > With the involvement of the Open Bank Project > <https://openbankproject.com/about/>, located in Germany. According to > the trade newspaper American Banker, "U.K. Push for Open Bank APIs Makes > U.S. Look So Last Century > <http://www.americanbanker.com/news/bank-technology/uk-push-for-open-bank-ap…> > ." > I don't know what the HM Treasury will conclude after their open banking API "Call for Evidence" but I can see dark clouds for hi:proj, decentralization, and VRM if the Open Bank Project and the American Banker articles are the path. The problem is that these articles promote an app store controlled by the bank rather than the individual. This effectively shuts out open source apps and introduces a rent-seeking app certification process controlled by the bank just like the control by Apple or Google through their app-store. Now, to be sure, I have no problem at all paying my bank a transaction fee for checks or API access. I do however have a big problem if my bank restricts who I can send a check to or what app can connect to my account. This is exactly what I am directly involved in with hehathcare APIs in the US. Here, for example, is my testimony a couple of weeks ago: https://www.healthit.gov/FACAS/sites/faca/files/APITF_Testimony_AdrianGropp… The ability to grant unconstrained ***third party*** access to an API that is all over the HM Treasury call is absolutely essential to decentralization and, I would claim VRM. This is what UMA and HIE of One is all about. It's much easier in US healthcare because US law treats access to patient data as a "right" and will likely impose a corresponding "duty" to respect an individual's right to specify their "agent" for access to the API. In the HIE of One (and hopefully HEART) approaches, the individual specifies the UMA-standard Authorization Server and that Authorization Server, acting as my agent, has sole discretion over what app and what app user can see my data (or is it midata?) at the hospital or the bank. Adrian -- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

1 0

Notes from UMA telecon 2016-02-04
by Eve Maler 06 Feb '16

06 Feb '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-04 MinutesRoll call Quorum was not reaching. Approve minutes Deferred. Force-rank use cases What's A and what's B in terms of priority (since we probably can't get more "rank-y" than that)? John W suggests working from "likelihood of error occurring" and "impact of the error". The other factor is "detectability of the error". If the exploit is 100% undetectable, that's bad. This is a good way to prioritize #security work (which is overtly about bugs). For feature work prioritization, we had talked about gathering "customer need" in 2016 or 2017. Mike adds that this could include "developer adoption" – so are we targeting developers and deployers both? "Customers" would typically mean those who know they need UMA. "Developer adoption" is about building community among those who may not know they "need UMA" yet. (This is what Adrian's goal is around an always-on AS, to entice RS and client developers.) George questions that UMA should be looking for adoption in the OAuth fashion. How do we define #wideeco? If we correctly define mechanisms for dynamic onboarding of disparate parties, wouldn't it be the case that the narrower ecosystems would tend to use those mechanisms to build their deployments? The question is whether dynamic mechanisms add too much overhead for static partnerships to be willing to use. So maybe it's not just about correct definition of mechanisms; it's about a continuum of needs. There's definitely a tension present around when to optimize for #wideeco, and what our options are. It's not just about how to gather claims securely from Bob when his claims providers and Alice's AS-as-a-claims-client have not pre-established trust between them. There are other considerations as well, as we look at the broader implications of what "value-add features" are desired. AI: Eve and James: Share technical paper/thoughts on potential solutions to "Bob when his claims providers and Alice's AS-as-a-claims-client have not pre-established trust between them" So far – all still being discussed: #IoT (Eve), #APIsec, #fedauthz, #RSctrl, #ROctrl, #wideeco (Adrian, Justin), #trust, #security (Justin, Eve) Justin adds a vote for the issues he submitted that have to do with implementation simplification and, in some cases, making it an OAuth extension grant (?). This needs a new "hashtag". *AI:* Eve: Add a #simplification label and add the self-contained token discussion to that issue. John W notes that constraining sharing based on geolocation would be a good idea. Eve suggests adding an issue on this. *AI:* Eve: Set up one more round of ad hoc #239 meetings next week, in hopes of finishing then. Validation of self-contained token discussion on that back channel: - Mike Schwartz@All: I don't think self-contained tokens is limited to IOT... - Mike Schwartz@All: And also, I'm not sure its possilble... - Justin Richer@All: Self contained tokens are in no way limited to IoT and that's not hte only issue of IoT. And how is it not possible? People have been doing it for many, many years. - George Fletcher@All: agreed that self-contained tokens are limited to IoT. I also think that while we should use JWT for the token syntax there are some real issues to solve here. - Mike Schwartz@All: of course self contained tokens are possible, but the way we defined the RPT flow - Mike Schwartz@All: the RPT gets issued, and its empty - Mike Schwartz@All: and then permissions get added. - Mike Schwartz@All: So its not that RPT can't be self-contained, but it can't be used as an access token - Mike Schwartz@All: because the access token value would change - Justin Richer@All: That's not how we issue RPTs. We don't issue RPTs until there are permissions to it. If we add permissions we'd issue a new RPT which is valid. - George Fletcher@All: Yes, or become a "super" token which has it's own security issues. - Justin Richer@All: Right, super tokens are a big problem in wider cases. Charter revision Deferred. Use case work See the issue #239 meeting series email thread for the continuing notes on that. Attendees As of 20 Jan 2016, quorum is 7 of 12. (Evariste, François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Søren, Mike) 1. Eve 2. Mike 3. Kathleen 4. Andi Non-voting participants: - Justin - John W - George - Adrian - Sarah - Jin *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

4 4

uma privacy definition
by arr＠worldknowledgebank.com 05 Feb '16

05 Feb '16

Is there an uma definition of privacy? Regards, Ann Racuya-Robbins "When you share what you know in a just way you sustain life and transform the way the world works." Ann Racuya-Robbins Founder Virtual Democratic Countries https://www.worldknowledgebank.com<https://www.worldknowledgebank.com/> 4440 Willard Ave #729 Chevy Chase, MD 20815 and 2 Placita Road, La Puebla, Espanola, New Mexico 87532 202.304.7103, 505.216.5343, 301.951.1809 This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication.

8 25