- WG-UMA - mailman.kantarainitiative.org

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 05 Feb '16

05 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

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

05 Feb '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes 2016-02-05 - Term definition work (see issue #240 <https://github.com/KantaraInitiative/wg-uma/issues/240>) – for reference, here are all the open #trust issues <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…> Attending: Eve, Scott, Paul, Jim, John W, Adrian, Ann, Jon N, Mark, Kathleen *Regulation of consent* Should we be concerned about EU regulators "regulating away" the potential power of UMA around proactive enduring consents (e.g., policies that are indefinite until revoked) because on subsequent reference to them by an AS they're not "explicit"? Is there a way to influence the thinking of regulators and/or have two-way conversations with them so that implementations and deployments can give individuals the right buttons and knobs and UX's? It's certainly possible to make appointments with regulators. The US regime has a property basis, whereas the European basis is human rights. Revisiting one's consent in context (monitoring one's consent) would theoretically be a powerful way to exercise one's rights. In the healthcare world, coming from paper vs. digital, notice was expensive. But in the digital world, notice is free at the margin. Mark notes that: "We are working on a model practice papers to send to regulators wth the Kantara sponsored workshops." He will send a note to the list with more information as required. He thinks we don’t think we need to worry about regulators regulating away consent directives, as consent is regulated by purpose and notice. *AI:* John W: Find ways to reach out to regulators to start conversations. *Digital Contracts, Identities, and Blockchain - new event at MIT <http://www.commonaccord.org/index.php?action=doc&file=S/About/Conference/Fl…>* This event has very limited seating and is invitation-only. If you want to attend, let Jim H know soonest! The notion is secure, DRY, peer-to-peer text objects handled as if they were software objects. *Term definitions* Our term definitions of record are here <http://www.commonaccord.org/index.php?action=doc&file=GH/KantaraInitiative/…> . We can define whatever terms we want, but we don't want to "chase our tails". Agency (here meaning legal agency, the ability to take responsibility) is different from being a hunk of, say, software; software isn't a thinking thing. We're in the business of helping services that want to be, say, IdPs and merchant services and healthcare services *also* be UMA services to create the legal agreements they need, and since they'll be UMA clause novices, we're providing starter UMA clauses for them. Note that an UMA authorization server operator is different from talking about a data processor or data controller. The the former term is an "UMA legal" term of art, and the latter are regulatory terms of art. Wherever we use the latter, we would have to refer to our source of the definition – ISO 29100 <https://www.iso.org/obp/ui/#!iso:std:45123:en> is what CIS refers to for consent receipts. The pairs we currently have are: - resource owner:Authorizing Party - requesting party:Requesting Party - authorization server:Authorization Server Operator - resource server:Resource Server Operator Where things break down: A use case: Alice (Individual) wants dentist's office (Legal Person) to get access to her calendar for the purpose of scheduling a root canal. The dentist's office receptionist (Individual acting on behalf of the Legal Person, as an employee or contractor) tries to access the resource, using a client (Client). Questions: Let's not overcook this. Think in terms (ha) of the next strawman iteration. Since no one expressed strong feelings about making any changes, we will leave the terms as they are till changes are forced on us. 1. Should we give a generic name to the clients, authorization servers, and such? Are they Non-Person Entities as a general category now? What would be the usefulness of this? *Don't add.* 2. We've called the receptionist in this use case a Requesting Party Agent to date. Is that right? What benefit does it confer? There is actually an UMA flow (or possibly several flow options) to which it correlates. *Eve suggests:* Keep for now and try to use it in practice to see if it works. 3. Does UMA want to trace duties to preserve the rights of the Individual? *No further discussion.* 4. Does Individual want to be Natural Person? *Don't change.* 5. Is the ability of the Individual to consent constrained in the circumstances of the transaction, e.g., by regulations? (Think in terms of term definitions for now. This is a much bigger question!) *Don't change anything.*. It seems we have nothing more to discuss on issue #240 unless problems arise. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Joint FHIR - SPM - HEART Meeting at HIMSS16 - Las Vegas Monday 2/29 2-5 PM
by Adrian Gropper 04 Feb '16

04 Feb '16

The leadership of the FHIR standards group has arranged a meeting that should, among other things, facilitate harmonization between the HEART and FHIR workgroups. The meeting will also be a great opportunity for a broader patient perspective than we typically get into standards work. We owe this early success to the Society for Participatory Medicine leadership of Peter Elias and ePatient Dave and the eager engagement of Grahame. Thank you! FHIR has booked a room on Monday 29th Feb 2016, 2-5 pm, at Embassy Suites hotel (http://www.lasvegasembassysuites.com/) There's space for 24 people and we should advertise this to our communities. Please send RSVP to grahame(a)healthintersections.com.au 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

Agenda for UMA legal telecon 2016-02-05
by Eve Maler 04 Feb '16

04 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-05 - Term definition work (see issue #240 <https://github.com/KantaraInitiative/wg-uma/issues/240>) – for reference, here are all the open #trust 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

Agenda for UMA telecon 2016-01-04
by Eve Maler 03 Feb '16

03 Feb '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-04 Date and Time - *Thu Feb 4,* 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 - (Note that a short ad hoc meeting to discuss issue #239 will be held just prior, on the same dial-in) - Roll call - Approve minutes of UMA telecon 2016-01-07 <http://internetidentityworkshop.com/> - Force-rank use cases in our UMA Roadmap for 2016 <http://kantarainitiative.org/confluence/display/uma/UMA+Roadmap+for+2016> page: #IoT, #APIsec, #fedauthz, #RSctrl, #ROctrl, #wideeco, #trust, #security - Appoint a small contingent to look at revising our charter <http://kantarainitiative.org/confluence/display/uma/Charter> - Dig into the top item on our use case pile - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Putting the new issue in context, including [legal]
by Eve Maler 02 Feb '16

02 Feb '16

In case the technical particulars of issue #239 might have made some folks' eyes glaze over, I wanted to paraphrase it in a couple of different ways to help us all analyze it. The ad hoc meeting this morning was very useful to dig into more details (and I'm sure there's more to come), but at this point we've been focusing most heavily on the tech side. We started thinking in terms of "risk" towards the end of the call, a more subjective and squishy task when we're talking about protocols. (There are a lot of sources on the 'net discussing "threat vs. vulnerability vs. risk"; here's one <http://simplicable.com/new/security-risk-vs-vulnerability-vs-threat>. The idea is that risk has to capture the business upside of doing X with good guys involved, along with the business downside of doing X with bad guys in the mix.) The attack in issue #239 <https://github.com/KantaraInitiative/wg-uma/issues/239>, put in more business-y terms, could be stated this way (Justin et al., please adjust if I've misrepresented too much): Alice has a resource R she wants to share with Bob, and she uses an UMA authorization server and resource server to do so. Before Bob gets as far as actually attempting access to that resource using his legitimate UMA client app C, attacker Eve starts the "UMA dance" using an UMA "attacker client" app AC that has the same identifier as Bob's app. Eve's app manages to "phish" Bob into providing the necessary claims to Alice's AS for some other apparent purpose (not for getting Alice's resource R), and the rest of the UMA flow unfolds in a way that lets Eve get resource R instead of Bob. In legal-y (model text-y) terms, we could observe that: - Alice the RO (Authorizing Party or AuthzP), the resource server operator (RSO), the authorization server operator (ASO), and possibly the Client Operator??, are all let down because resource R is ultimately exposed to Eve (the attacker) and not the intended RqP, Bob. This is really bad. - Also, the ASO has been tricked into collecting claims outside of the intended purpose of authorizing access to the AuthzP's resources. I think we have a model clause about how the ASO needs to be restrained about why to collect claims. - However, Bob (RqP) has exposed his claims to an ASO that he does have an authorization API token (AAT) with, and that ASO normally would hang onto his tokens for legitimate access to various resources. Not sure if that makes this a "breach" of his claims or not. - (There's maybe some other observations we could make here...) All in all, it's a great use case for the model text work. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Ad hoc WG meeting tomorrow at 8am PT to work on issue #239
by Eve Maler 02 Feb '16

02 Feb '16

This week's schedule is to meet tomorrow at 8-9am PT/10-11am CT/11am-noon ET/4-5pm UK/5-6pm CET at our usual number. (At that time, we'll discuss whether to also meet during the half-hour before our Thursday call.) Sorry for the last-minute notice... It seemed we would reach critical mass among a sufficiently techie crowd at this time. We'll figure out our schedule on a weekly basis for working on this issue. This call is now on our online calendar: http://kantarainitiative.org/confluence/display/uma/Calendar If you'd like an invite, let me know. The progressive agenda for this meeting series: - 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 - Analyze the proposed mitigations and see if there are any others we have missed - Assemble pros and cons for the mitigations and the forms in which they can be "packaged" to bring forward to the whole WG *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1