- WG-UMA - mailman.kantarainitiative.org

URGENT: replacement number for UMA legal call - TurboBridge giving me problems
by Eve Maler 26 Feb '16

26 Feb '16

Please switch to this instead: +1 (605) 562-3000 919-726# Sorry for the inconvenience! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Is it UMA, HEART, or X?
by Adrian Gropper 25 Feb '16

25 Feb '16

How does a Resource Server operator advertise that they offer policy-based OAuth client access? (If they just want to support clients that they register directly, they can simply claim OAuth2). Let's consider a connected lock vendor wants to make a claim that their lock works with "standard" OAuth authorization servers rather than asking all of the visitors to install yet another app on their smartphone. Let's also consider a hospital with a FHIR API that also wants to claim it works with "standard" OAuth2 authorization servers. What label would apply to these authorization servers that says to folks: "Your standard AS accepted here?" Is it UMA, HEART, or do we invent some other trademark? 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

Draft minutes of UMA telecon 2016-02-25
by Eve Maler 25 Feb '16

25 Feb '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-25 MinutesRoll call Quorum was reached. Approve minutes Minutes of UMA telecon 2016-02-18 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-18> approved. Report from legal meeting The legal subgroup is working on an interesting issue that tackles the subtleties behind "who is the RO" – not at the "T" level, where the UMA protocol has no doubt, but at the "B" and "L" levels, where there are layers of "is the one" and "is acting on behalf of the one". Kathleen notes that HL7 is right there with us working on the exact same issues. The goal is to define our terms clearly so that we can craft our model clauses around the operation of the protection API (the operator of the AS, the operator of the RS, and the authorizing party or whoever is acting on their behalf) accurately. Adrian is driving towards a particular goal of an AS that is operated by the RO themselves. Charter-bashing Let's take charter <https://docs.google.com/document/d/1cv7MLdpC1SMubREbZX7L8E4YUPCAzKPwOCFBky6…> review as homework for our meeting two weeks from now. Upcoming F2F opportunities You can find UMAnitarians at HIMSS and RSA. See Gluu's blog post <https://www.gluu.org/blog/gluus-rsa-conference-2016-events/> for some RSA opportunities. Who is definitely attending IIW? Eve, Mike, Adrian, Jin, Maciej, George. Who is possibly attending? John depending on his China gig situation, Andrew Hughes based on what we might work on, Ishan based on work schedule. Would there be interest in focusing on conformance testing as a discussion topic at IIW (again)? Adrian is interested, from a very specific perspective: having an AS reference implementation. Mike notes that there are several open-source implementations that could be reference implementations, and there are several use cases, so we don't seem to lack for them. Is a reference implementation the job of the WG(s)? John suggests something more like the W3C Validator. In fact, the budget request includes a hosted test harness that would (initially) test authorization servers. Sounds like working on what use cases to test would be a winner. Eve also suggests working on, and getting people up to speed on, our model text. Mike also suggests doing some "UMA marketing". Eve is up for that, but not for self-flagellation. [image: (smile)] What about the UMA/blockchain connection? This is a very good point. Thomas and Jim have been working on this area. Thomas has a slide deck <https://hardjono.mit.edu/sites/default/files/documents/CommonAccord_Provena…> on this. We have four UMA-related topics of interest we'd like to convene sessions about at IIW. Issue #239 spec review Should we totally replace the requesting party claims endpoint, or write the configuration data piece so as to invent a new "enhanced claims-gathering security endpoint" so that people could deploy UMA-with-lesser-security and UMA-with-tighter-security at the same time? We've modularized the extension so that we could work on the mitigation ASAP and for flexibility's sake in pacing our UMA V.next plans. We seem to have achieved that. The group has no appetite to invent a lesser-security endpoint for form's sake. *AI:* Maciej, Eve, Dom: Revise the spec and share with the list for more review before we publish more widely. #wideeco Deferred. Attendees As of 18 Feb 2016, quorum is 6 of 11. (François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Mike, Sarah) 1. Eve 2. Robert 3. Domenico 4. Maciej 5. Kathleen 6. Mike 7. Sal Non-voting participants: - Adrian - James - Ishan - John - Scott - George - Jin Regrets: - Andi - Sarah *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

APAC-friendly call cancelled
by Eve Maler 25 Feb '16

25 Feb '16

Eve (sent from my iPhone, possibly with Siri's "help": +1-425-345-6756)

1 1

Agenda for UMA telecon 2016-02-25
by Eve Maler 24 Feb '16

24 Feb '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-25 Date and Time - *Thu Feb 25,* 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-02-18 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-18> - Reports from sync and legal meetings - Charter-bashing <https://docs.google.com/document/d/1cv7MLdpC1SMubREbZX7L8E4YUPCAzKPwOCFBky6…> - HIMSS, RSA, and the Non-Profits on the Loose event - IIW planning - CIS/legal/interop? - Review #239 spec and doc; next steps - #wideeco analysis and potential solution collection - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Reminder: APAC-friendly sync 2016-02-25 [see note below]
by Eve Maler 23 Feb '16

23 Feb '16

*[NOTE:* I may possibly be delayed in joining the call by an appointment that could run long. If you plan to join the call and are not yet part of our "UMA Chat" Skype group, please send me your Skype handle to be added so that I can keep you apprised in real time. If you're not on Skype at all, let me know that.*]* - *Thu Feb 25* 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 24 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

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

22 Feb '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes 2016-02-19 - *Distinguishing resource subjects from resource owners:* Can we develop a cohesive system whereby "resource subjects" without legal capacity can have "authorized agents" acting on their behalf as "resource owners" as required in order to forge "resource registration agreements" for the purpose of UMA's phase 1 particulars? Do the use cases/design patterns provide any insights or challenges here? - See email thread <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/pn5KRXJt2…> Attending: Eve, Andrew Hughes, Paul L, John, Ann, Adrian, Jon, Kathleen, Sal Is it valuable to solve for a model where an agent can be working on behalf of resource owner vs. a resource owner? The protean nature of the word "agent/agency" is troubling. Is there a good substitute word? If not, do we have to define *Agent for all of our terms in an UMA context? We did already have Requesting Party Agent. Perhaps, at best, we should define it operationally but stay away from legal subtleties. We've said that resource owner = Authorizing Party. Does that work, or is it not equivalent? There are terminology questions and there are UMA architecture questions. Should we just wave away problems by making them equivalent? - *1yo case:* What if the "resource owner" (let's say they're the "subject" of the data residing in the RS) is a one-year-old kid and their mom has to manage the resources by logging in to the RS? The child is not competent to contract, even if they're old enough to sign their name. *Guardian* is a good name for the latter. - *12yo case:* What if the "resource owner" (let's say they're the "subject" of the data residing in the RS) is a 12-year-old kid and they're old enough to manage the resources by logging in to the RS themselves? The child is not competent to contract, even if they're old enough to manage resources online. How to architect the system and name the parties? - *Intermittently competent adult case:* This is another tough one. - *Competent adult case:* What if the "resource owner" (let's say again that they're the "subject" of the data residing in the RS) is actually competent to contract, but wants to have someone else manage resources for them online? There's a paper resource owner, but an online "executor" of resource management. What's a good term? - *Digital death case:* After the "resource owner"... Adrian's concern is what happens in phase 1. These use cases have different properties in that phase. Eventually (soon), we will be in a position to work on what's supposed to happen when RS's want to take an action in response to an access request that is in contradiction to the permissions contained in an RPT (requesting party token). First, we need to understand exactly "who" configured the AS to By the way, all the same patterns could apply whether or not the resources contain PII or not. What if the resource owner created digital media that they want to sell? Is there a reason to distinguish in our terminology at all? What if a resource contains PII "in bulk" for many individuals (in directories or databases or other repositories)? This was the point of Adrian's example. Eve's point was, rather, that individuals might want to be protecting resources that don't contain PII. Okay, now we're on the same page! There are use cases for UMA that span "Alice" and "enterprise". Let's try to conclude this decision-making process by next week, and then move on to the decisions about RS actions in contradiction. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

8 25

Draft minutes of UMA telecon 2016-02-18
by Eve Maler 20 Feb '16

20 Feb '16

Great meeting, all! http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-18 MinutesRoll call Quorum was reached. Approve minutes Minutes of UMA telecon 2016-01-07 <http://internetidentityworkshop.com/> approved. Issue #239 - *Proposal:* Regardless of other decisions, develop a non-normative analysis of the attack and mitigations; revise as appropriate depending on other decisions taken (Sarah has this AI already) Proposal accepted. - *Proposal:* Develop an extension specification, Enhanced Claims-Gathering Security Extension, to require cycling of the permission ticket when using the claims-gathering extension Sal and Eve just discussed in email whether a stronger authentication mitigation would work. Session fixation happens after victim authentication, so it wouldn't help. Robert mentioned to Eve offline that Wikipedia has some comments on session fixation that might be useful. Eve believes that since the permission ticket gets passed in UMA JSON messages, the countermeasures there may not apply, but we could look (for purposes of the non-normative analysis if ultimately nothing else). - *For discussion:* Consider also handling issue #167 in this extension if it has a security rationale If the AS uses the flexibility to give a new endpoint, then there's the danger of giving an attacker new information outside of the discovery document that it didn't have before, which is a degradation of security. If the AS doesn't avail itself of the flexibility, then it doesn't seem to add anything. In any case, we're not thinking of a security rationale for adding this feature to the extension. In any case, it sounds like taking up #167 as part of the extension work doesn't meet our "#security use case bucket" goals, so we'll defer that till such time as we take up "#simplify use case bucket" work. *Consensus:* We want to write and publish the extension specification. - *For discussion* (thanks Andi for these two new bullets!): Consider updating the UMA Core spec in some way to point non-normatively to the extension spec, and/or mention it from the UIG - *For discussion* (possibly at a later juncture): Consider if/when/how to fold the extension into a future UMA version (likely to be captured as a GitHub issue) The WG itself can self-approve a technical specification, and the LC can approve that group output. (Are these "WG Reports"? Eve will check with the LC.) In other words, this could remain at a level sort of equivalent to an IETF I-D and not progress to an "RFC" level before it eventually gets absorbed into a later version of the UMA Core spec. We do want to recommend that everyone using the claims-gathering endpoint use this approach, but it all depends on the timing of any new UMA "V.next" version. We basically need to defer the decision about its "track" until we execute on the rest of our roadmap. *AI:* Eve, Domenico, Maciej: Write the extension spec. Can we publish these by next Thursday? Let's give the old college try. We want to publish and publicize the draft docs at the same time. Wide ecosystem challenges Eve presented a set of high-level statements that describe the dual nature of the challenges. Eve/James and Maciej will share some material on the challenges. John observes that it's an ouroboros – a snake eating its own tail (or as Eve likes to call it, the bubble under the wallpaper that you can move but you can't remove). Some discussion arose about different solutions, e.g.: - UMA-protected user claims endpoint ("UserInfo") - Agreed-on central authority (e.g. hospital) serving as a claims endpoint/AS (?) – akin to the question that has arisen over the last decade-plus about "who's the IdP" The group agreed to collect all the potential solutions "without fear or favor" and then analyzes how well they solve the challenges. Attendees As of 16 Feb 2016, quorum is 6 of 10. (François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Mike) 1. Eve 2. Kathleen 3. François 4. Domenico 5. Sal 6. Mike 7. Maciej Non-voting participants: - John W - Sarah - Adrian - George - Scott - Mark - *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

3 10

Human-readable summary of Issue 239 and the current proposed solution
by Sarah Squire 20 Feb '16

20 Feb '16

Hi all, I took an action item last week to summarize issue 239 in a human readable format. Here it is: Alice wants to share a photo with Bob, and only Bob. Eve would like to see the photo, but she is not allowed. Alice stores the photo on her resource server and protects it with her authorization server. She sets a policy stating that only Bob should have access to the photo. In order to get Bob access to the photo, three steps are completed: 1. Bob begins his transaction by requesting the photo 2. Bob identifies himself within the context of his transaction 3. The authorization server grants access to the photo within the context of his transaction Eve would like to access the photo as well. She completes the following steps: 1. Eve begins the transaction by requesting the photo 2. Rather than identifying herself, Eve phishes Bob and convinces him to identify himself within the context of her transaction 3. The authorization server grants access to the photo within the context of her transaction Because Eve’s attack involves a successful phishing event, this scenario is not considered a vulnerability in the classic sense. The attacker must know the victim and successfully trick him. As such, the UMA working group is proposing that no normative changes be made to the core specification at this time. We propose a security enhancement extension to be used optionally in contexts where a higher level of security is appropriate. The extension we propose would disallow access to Eve by making each step in the process a different transaction so that when Bob identifies himself, it then becomes his transaction and Eve has no way to recover the context in which access was granted. We feel that this is an elegant solution that is easy to implement and in fact makes the software Bob has to use (also known as the Client) simpler than it would otherwise be since it no longer has to remember the transaction context from beginning to end. Sarah Squire Engage Identity http://engageidentity.com

3 2

Human-readable summary of Issue 239 and the current proposed solution
by Sarah Squire 19 Feb '16

19 Feb '16

Hi all, I took an action item last week to summarize issue 239 in a human readable format. I've included it below. It sounds like there is also a need for a general analysis of the proposed solution and why we chose it. I can write that up too. For now, here's a very high-level description of what's going on: Alice wants to share a photo with Bob, and only Bob. Eve would like to see the photo, but she is not allowed. Alice stores the photo on her resource server and protects it with her authorization server. She sets a policy stating that only Bob should have access to the photo. In order to get Bob access to the photo, three steps are completed: 1. Bob begins his transaction by requesting the photo 2. Bob identifies himself within the context of his transaction 3. The authorization server grants access to the photo within the context of his transaction Eve would like to access the photo as well. She completes the following steps: 1. Eve begins the transaction by requesting the photo 2. Rather than identifying herself, Eve phishes Bob and convinces him to identify himself within the context of her transaction 3. The authorization server grants access to the photo within the context of her transaction Because Eve’s attack involves a successful phishing event, this scenario is not considered a vulnerability in the classic sense. The attacker must know the victim and successfully trick him. As such, the UMA working group is proposing that no normative changes be made to the core specification at this time. We propose a security enhancement extension to be used optionally in contexts where a higher level of security is appropriate. The extension we propose would disallow access to Eve by making each step in the process a different transaction so that when Bob identifies himself, it then becomes his transaction and Eve has no way to recover the context in which access was granted. We feel that this is an elegant solution that is easy to implement and in fact makes the software Bob has to use (also known as the Client) simpler than it would otherwise be since it no longer has to remember the transaction context from beginning to end. Sarah Squire Engage Identity http://engageidentity.com

1 0