- WG-UMA - mailman.kantarainitiative.org

[legal] GDPR action plan under way, meaning GDPR interpretation
by Eve Maler 17 Feb '16

17 Feb '16

https://iapp.org/news/a/article-29-working-party-lays-out-gdpr-action-plan/ *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 3

Agenda for UMA telecon 2016-02-18
by Eve Maler 17 Feb '16

17 Feb '16

Lots of interesting stuff to discuss and decide tomorrow. Please try and join. http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-18 Date and Time - *Thu Feb 18,* 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/> - Review the recommendations for issue #239 and decide and execute on next actions - 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: Develop an extension specification, Enhanced Claims-Gathering Security Extension, to require cycling of the permission ticket when using the claims-gathering extension - For discussion: Consider also handling issue #167 in this extension if it has a security rationale - 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) - For meta-discussion: What to do right now, as soon as we decide all this? - Kicking off #wideeco discussion: inputs from Eve/James and others - Making plans for IIW - Thoughts on tasks we can accomplish there: CIS-flavored, legal-flavored, and interop-flavored efforts? - Who will definitely be there? Whose plans are contingent on the WG's plans? - Charter-bashing <https://docs.google.com/document/d/1cv7MLdpC1SMubREbZX7L8E4YUPCAzKPwOCFBky6…> (thanks Adrian for kicking this off!) - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

AI: Adrian: Write up ROI form concerns wrt to UMA phase 1 implications for the group's consideration. [Legal]
by Adrian Gropper 16 Feb '16

16 Feb '16

- Definitions: *Resource Registration Agreement* - A contract between the Resource Server Operator and the resource subject or authorized agent of the resource subject that defines a resource pertaining to the resource subject, including available and supported scopes, and delegates some control over that resource to an Authorization Server. The Resource Registration Agreement establishes Phase 1 of the UMA Protocol at a time when neither the Client nor the Requesting Party are known to either the RS / RSO or the AS / ASO. As such, this is equivalent to a typical healthcare ROI form if the ROI form were to *specify an agent for the subject instead of the client* for for the purpose of authorized access to the resource. *Authorization Server Endpoint* - The URI and associated .well_known endpoints of a standards-based authorization server acting as the agent of the resource subject during UMA Phase 2. Under this Resource Registration Agreement, the RSO agrees to consider a token signed by the AS as presented by the RqP / Client. The RS may either accept the token or it can notify the AS that the token was not accepted or modified in scope. *Resource Subject Signature and Date* - The individual who's PII is accessed via the resource. This individual could be any age and should not need to be able to read or write or use technology. *Authorized Agent Name, Signature and Date* - The individual that the RSO recognizes as an authorized agent of the resource subject in cases where the resource subject is unable to sign for herself. The basis of this recognition is completely out of band from UMA. - Is this UMA? In my subject-centered vision of UMA, the RS has no visibility into whether the Resource Subject or the Authorized Agent or anyone else is in control of the Authorization Server Endpoint. In Phase 2 or 3 of UMA, the RS can choose to take attributes of the Client and RqP into consideration along with the Token issues by the AS or the RS can accept the token as is. If the RS changes the intent of the token, either more or fewer privileges, then the RS must notify the AS of the change. It may be that my subject-centered vision of UMA is not actually UMA. I don't know. If it's not, then we should try to give it a name because all I'm talking about is the subject's right to specify an agent by executing a Resource Registration Agreement - period. 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/

3 4

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

16 Feb '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-11 MinutesRoll call Quorum was not reached. Approve minutes Deferred. OTTO WG OTTO stands for "Open Trust Taxonomy for OAuth2". This proposal <http://ox.gluu.org/doku.php?id=otto:proposal> captures the work that is now rapidly progressing. It's a generic way for defining a registry of services, no matter what metadata might be used for the services (SAML, OAuth, other). Are any other "trust bundle" sources using dynamic methods of updating? A number of federations in the education space are straining to scale. The OTTO proposal uses json-ld, which has some interesting properties, such as canonicalization and XML Signature-like signing. Justin notes that the JOSE group explicitly avoided canonicalization because it comes with so many pitfalls. The proposal includes some UMA RS-to-AS onboarding examples. Mike is calling for people to participating in the WG <http://kantarainitiative.org/confluence/display/OTTO/Home>, which meets on Wednesdays 8am PT/10am CT/11am ET/4pm UK/5pm CET. What about other systems, such as NIEF and GTRI? Are they actually comparable in terms of functionality? Unclear. Adrian mentions some past work with similar efforts that had some disappointing and privacy-invasive results. Consent receipts and UMA There's interest in the "shoebox endpoint" in the context of UMA. Sarah speaks in favor; she's been working on the id-events space of late. John mentions a shoebox is a kind of KeyPass or 1Password or similar user space solution. A clearly defined technical specification for consent receipts enables organizations with customer obligations around consent management to build their own tools appropriately. Adrian speaks in favor of the shoebox endpoint, but philosophically he sees it as a *notice* endpoint, not necessarily (just?) a repository of *consent*. This is related to agency law; you can't have a viable business structure around UMA unless you have a notice capability. Adrian: "At some point we are going to have to do privacy engineering around UMA." – this is not really separable from the #wideeco use case, in the sense of blinding/credential brokerage/privacy-preserving identity mechanisms. Regarding "notice and consent", John notes that the consent receipt reflects the result of a transaction. In different jurisdictions (US vs. EU), privacy is contractual vs. human rights-based. Prioritization For the whole WG (for now): 1. #security 2. #wideeco 3. #shoebox (the technical side) 4. #IoT For the legal subgroup (for now): 1. #trust generally (which is just developing model clauses etc.) 2. #RSctrl and #ROctrl and #shoebox (the legal side) Charter *AI:* Adrian: Take a look at the current UMA WG charter and recommend any wording changes. Andi to help as he sees fit. Issue #239 discussion and review Eve presented the attack and the proposal briefly. The threat is applicable only to some methods of trust elevation (not to step-up authentication, nor to pushed claims, only to interactively gathered claims at the claims-gathering endpoint), and is not applicable to any known or imminently planned UMA deployments (e.g., Gluu's current deployments use step-up authentication only). The subgroup looked at quite a few potential mitigations and rejected most. The one it recommends for now involves adding entropy to the permission ticket so that an attacker RqP can't steal away a victim RqP's already trust-elevated right to access an RO's protected resource. Any mitigation would be backwards-incompatible. We have recommended packaging the proposed mitigation in an extension spec so that only those needing it can deploy it alongside core UMA in an identifiable way. When the time is right, we can choose to slot it into core UMA, or by then, we might have designed a wholly new UMA V.next design. Mike, Kathleen, and Adrian speak in support. Andi has some concerns that he will send in email. Mike suggests, if we go this route, putting an erratum note of some kind in the base spec. Kathleen notes that getting a mitigation out sooner is better because otherwise people just assume protocols like UMA are safe and there could be a backlash. Would incorporating the proposed mitigation into the core spec mean we'd make a V1.1 or something? Nominally no, because we have adopted semantic versioning. *AI:* Sarah: Draft a "friendly doc" describing the exploit and the proposed mitigation(s). *AI:* Eve: Send Sarah the source WSD for the attack. Let's try and get a full set of voting participants to attend soon so we can have a full discussion and decision. 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. Kathleen 3. Mike 4. Maciej 5. Andi 6. Domenico Non-voting participants: - Sarah - Justin - John W - Adrian - George - James - Ishan - Jin *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 2

Proto IoT Use Case - Replacing the condo front door key-fob
by Adrian Gropper 15 Feb '16

15 Feb '16

Here's a use-case to consider for UMA and IoT: Replacing the condo front door key-fob by assuming everyone who might need a fob has a smartphone. Most condos use a key-fob to secure doors that don't have a doorman. The gray fob on your keychain is expensive and inconvenient when it needs to be passed around to guests or causes phone calls to neighbors when an authorized visitor does not have the fob. Now assume that a smartphone as UMA Client replaces the fobs and that the door lock is connected to the Internet as an UMA Resource Server controlled by the condo management as RSO. This use-case highlights at least two issues around UMA and IoT. First, it seems unreasonable to consider this a narrow or medium ecosystem use-case. The condo apartment owner would not be pleased to have as many UMA Authorization Servers to deal with as she has situations of controlled access to a shared resource. Second, the nature of the UMA solution may need to be sensitive to proximity and redundancy so that a RqP with a (wireless) LAN connection can access the lock even if the WAN is inaccessible. Where is the condo apartment owner's AS located? Isn't it in the apartment with both LAN and WAN connections? This works for Thing resources within radio range but could benefit from a synchronization mechanism that allows the RO's AS to be more or less replicated in the cloud. 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 1

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