- WG-UMA - mailman.kantarainitiative.org

Implementation of UMA issues
by Justin Richer 19 Mar '16

19 Mar '16

Hi everyone, There are a bunch of issues open on the UMA spec that are currently awaiting assignment to some future revision of the specification as they’d break backwards compatibility in a not-fun fashion. Instead of simply letting these languish here awaiting their time in the spotlight, we decided to go ahead and implement them all together using MITREid Connect (an UMA 1.0.1 implementation) as a base. Changes include: - Removal of the RPT endpoint, in favor of using the token endpoint and a new grant type (#153) - Removal of the AAT (#154) - Removal of extraneous bits of the resource set registration URL pattern (#155) - Alignment of the discovery document with OIDC discovery (#157) - Removal of “version” field in discovery document, instead document is published under new .well-known URL pattern (#159) - Change use of “scopes” name in responses to something more explicit (#158) - Ability of client to specify scopes in token request (#165) - Addition of the claims-gathering URL to the need_info response, removal of “redirect_user” as redundant in this case (#167) - Simplification of the “need_info” response structure, removal of extraneous object layers (#237) - Rotation of ticket values on all requests to token endpoint or claims endpoint to mitigate session fixation and related attacks (#239, #205) As noted above, these are all filed as issues with the UMA working group and all have been well documented to date. We built what we thought would be the best solution to each of these issues in turn. We’ve implemented all of these changes in a branch in our server that we’re putting under the title “multiparty”, as in “multiparty delegation protocol”. Since this isn’t compliant with UMA (in some cases by design), these changes are not in our master branch nor in our release stream at this time. But the code is still publicly available: https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/tree/m… We’ve also implemented a very, very simple client and a very, very simple protected resource using the same changes above, as well as all the “best practice” recommended changes in 1.0.1 that should probably become requirements in future versions (such as returning the ticket in a header from the resource): https://github.com/jricher/multiparty-resource https://github.com/jricher/multiparty-client You can run all three of these components together on a localhost Tomcat instance to try them out. Speaking from my own personal experience developing both this new code set and the original UMA spec, I can say that I prefer this new version hands down. The code is drastically simplified in a number of places, information flow is much cleaner overall, and there’s less guesswork expected of components at each step. The nature of some of these changes (like removal of the AAT) make this new protocol immediately more applicable to a wide ecosystem use case as well. — Justin

1 0

Agenda for UMA legal telecon 2016-03-18
by Eve Maler 17 Mar '16

17 Mar '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes 2016-03-18 - External review and reviewers of our work at the Q1 mark - Action items for the model definition editors regarding last week's consensus definitions - In-scope and out-of-scope trust relationships and their names (see this thread <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/ia6qmjk92…> and below) - Disentangling meanings of "delegation" – do we need a group norm about terminology? - How do we square the "Requesting Party"/Grantee/Potential Grantee circle? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Notes from UMA telecon 2016-03-17
by Eve Maler 17 Mar '16

17 Mar '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-03-17 Minutes(Unofficial ad hoc meeting notes prior to call) Attending: Eve, Sarah, Justin, Adrian, Maciej, Domenico, Andi, George, Sal Justin suggests shortening the abstract and introduction by removing the first sentence. Justin suggests adding 'NOT RECOMMENDED' to the RFC2119 boilerplate that we use. In fact, we should add an editorial issue about this so that we update the other docs eventually, too! We discussed future-proofing this extension so that it applies, as well, to (e.g.) any UMA V1.0.x or UMA V1.x that might be susceptible to the same attack. We still need normative references to V1.0 and V1.0.1 because of the section references into specific sections of the text, and because the attack is known to appear in those versions, but we want to broaden the normative language in the spec to refer to "...and any other similar versions of the UMA specification to which this attack applies, and in Sec 1.2, say something like "An UMA authorization server that would have implemented a requesting party claims endpoint susceptible to this attack... " To make the extension spec more helpful, we want to have subsections inside the main Sec 2: Introduction, explaining who should be using this enhancement and why; Attack Sequence, a shortened version of what's in the non-normative doc; and Mitigation, the normative part of the spec. Maciej noted that "use this endpoint exclusively for interacting with the end-user requesting party to gather claims". Justin thought that breaking out each bullet as a full sentence with a single instruction: "The AS MUST do this..." "The AS MUST do that..." etc. would be good. Specifically, we're thinking that talking about something like "replacing any use of the original claims endpoint with the enhanced claims endpoint would help, vs. "exclusively" language. Let's also change this: "Effectively, when this extension is in effect, the requirement stated in Section 3.2.2 of UMA1.0.1 as "Permission tickets MUST NOT be single-use" is nullfied" to this: "Effectively, this extension supersedes the requirements stated in Section 3.2.2 of [UMA101] <file:///Users/eve/Documents/wg-uma/draft-uma-claims-sec-ext-v1_0.html#UMA101> as "Permission tickets MUST NOT be single-use" and Section 3.6.3 as "The same permission ticket value that the client provided in the request."" *Discussion of the new mitigation idea:* Eve's idea is that by combining trust elevation mechanisms (through policy conditions that require their combination – recalling that policy is OOB wrt UMA) in significant order, thereby "binding" Bob across those mechanisms/endpoints, trust in the legitimate RqP can be correctly elevated and the attacker can be tossed. Roll call Quorum was reached. (Huge showing today!) Approve minutes Approve minutes of UMA telecon 2016-03-10 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-03-10>: NO OBJECTIONS!!! Issue 239 materials *Report out and final conclusions if all goes well:* We walked through the ad hoc discussion above. We discussed whether we should name the "parallel endpoint" some sort of "forever and all" name that will last through the next big UMA version overhaul, whenever that might be. Currently we've suggested security_enhanced_claims_endpoint. Let's indeed put this out on the list to think about it, with conclusions by next week. John likes secure_random_value_claims_endpoint. Let's continue discussing. We forgot to record that we want to delete "This extension does not change any original requirements of UMA if used without these enhancements." Justin recommends adding "unguessable" to "securely random"; agreed. In that case, we should consider doing this in the original spec too, as an editorial change vs. "The permission ticket is a short-lived correlation handle generated by the authorization server that is intended to be opaque to resource servers and clients. The authorization server therefore MUST ensure that the ticket is securely random, much as it would for authorization codes and access tokens. Within these constraints, however, the authorization server MAY format the ticket however it chooses, for example either as a random string that references data held on the server or by including data within the ticket itself."; let's add this as an issue. Finally: typo: s/ot permissions/of permissions/ Justin points out that order wouldn't be significant because if Bob is strongly bound initially, then Eve has no chance already. But it's not a particularly interesting mitigation from his perspective unless it's the combination of, say, "I'm 'Bob' to some strength (authentication_context) plus 'I'm a doctor' (specific claim requirements) and 'this client has no knowledge of/ability to/trustworthiness to provide my doctor claim ( redirect_user is required)". E.g.: Bob gets his authentication through a hospital, but Alice has a carveout against his access to her information. Her policy is: If is_doctor and is_not 'Bob', then the logic would want to grab the current identity in a convenient way. John notes: "We call Alice’s carveout a “Lockbox” in Ontario. She can lock access to her records to some or all people or groups (barring ‘break the glass’)." Eve discovered that there are two implementations so far, Gluu and FR, that do use the AAT ("session") for meeting policy conditions, so that's at least a data point for discussing this mitigation. This particular combination hasn't been deployed, however. So what should be done about this mitigation? It falls into a gray area. It's not something that belongs in a normative spec. It's not for us to "accept" or "reject". We need to qualify who is susceptible to the attack by adding the word "solely", and ensuring that readers of the spec understand that even if they mitigate the attack in any other way, it's "tricksy". We will simply refer them to the background document for "background information on this attack, the provided mitigation, and other discussion.", and then provide discussion of this additional mitigation idea for those who wish to pursue it. We're not going to spend lots of energy writing a full description of the "combined trust elevation mitigation" in that background doc. We should also add something to the UIG pointing to the new spec and doc, so people won't miss them. *AI:* Eve and Maciej: Revise the extension spec for final consideration next week. *AI:* Eve: Revise the background doc for next week. *AI:* (somebody, can it please not be Eve? [image: (smile)] ): Add a mention of the attack and mitigation to the UIG. "Why UMA?" AI report and discussion Domenico ran through his analysis of business audiences and ways to make the case. Eve described new discussions in the UMA Dev group around appealing to the developer audience, and invited UMA WGers to contribute. New concrete case studies are extremely welcome, along with statements from individuals and organizations involved in them in their own words; these are the most powerful. Attendees As of 18 Feb 2016, quorum is 6 of 11. (François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Mike, Sarah) 1. Domenico 2. Sal 3. Andi 4. Kathleen 5. Sal 6. Robert 7. Maciej 8. Eve 9. Mike 10. Sarah Non-voting participants: - Justin - Adrian - George - Ishan - Scott - John *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

FYI from Usable Privacy at CMU
by John Wunderlich 17 Mar '16

17 Mar '16

<—cut from list posting The Usable Privacy Policy project has just released a new website that features over 20,000 policy annotations collected for nearly 200 website privacy policies. This is just the beginning of an effort, where we hope to further scale this process with machine learning and natural processing technologies. The website is at: explore.usableprivacy.org. You may also be interested in the joint CMU-Fordham press release< http://www.cs.cmu.edu/news/new-website-sheds-light-privacy-policy-shortcomi…> about the site or a recent article in Consumerist< https://consumerist.com/2016/03/11/researchers-launch-tool-to-help-show-you… >. Moving forward, we plan to issue a small number of updates each year (perhaps 2 or 3) about our progress and opportunities for members of different communities to use our results and/or also contribute to our effort. If you would like to be removed from this mailing list, please follow the instructions at: https://lists.andrew.cmu.edu/mailman/listinfo/usable-policies —-> Sincerely, John Wunderlich @PrivacyCDN Call: +1 (647) 669-4749 eMail: john(a)wunderlich.ca -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

1 0

Please review the revised security extension spec...
by Eve Maler 17 Mar '16

17 Mar '16

...for the ad hoc call to start at the top of the hour: http://htmlpreview.github.io/?https://github.com/KantaraInitiative/wg-uma/b… *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

First IoT Project Builder
by John Wunderlich 17 Mar '16

17 Mar '16

UMA on Raspberry Pi? Cool idea, but trying to sign up for this leads to data tracking hell. Can’t ‘register’ even though whitelisted in Ghostery and turn off uBlock origin. Who knows what kinda crap is going on in the backend. But if you’re curious, consider yourself warned: http://www.cayenne-mydevices.com/ Sincerely, John Wunderlich @PrivacyCDN Call: +1 (647) 669-4749 eMail: john(a)wunderlich.ca -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

5 18

Agenda for UMA telecon 2016-03-17 (still in "summertime skew")
by Eve Maler 17 Mar '16

17 Mar '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-03-17 Date and Time - *Thu Mar 17,* 9-10am PT (*N.B.:* North America has changed to Daylight Savings Time; *THIS WEEK AND NEXT ARE ABNORMAL*) - 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-03-10 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-03-10> - Issue 239 materials: report out and final conclusions if all goes well - "Why UMA?" AI report and discussion - Wide ecosystem: time to push this forward? - Charter-bashing <https://docs.google.com/document/d/1cv7MLdpC1SMubREbZX7L8E4YUPCAzKPwOCFBky6…> (if anyone has done any homework...) - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Final ad hoc call to discuss issue #239 and make recommendations is scheduled for Thursday
by Eve Maler 16 Mar '16

16 Mar '16

We'll meet during the hour just before our regular WG call on Thursday. (Remember summertime skew! If you want a calendar invitation and didn't yet receive one, let me know and I'll add you.) Goals: Decide what to recommend on the new mitigation idea, review latest changes (still to be made) on the extension spec, and review the non-normative doc. It would be awesome to get a suitable quorum on the WG call to review the recommendations and get consensus, so we can "go public" properly with all this stuff right away. Thanks! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

Fwd: Sedona 8th Annual Int’l Programme on CB Discovery, 7-8 June 2016 – Now Accepting Applications for Invitations
by John Wunderlich 15 Mar '16

15 Mar '16

May be of interest Sincerely, John Wunderlich @PrivacyCDN Call: +1 (647) 669-4749 eMail: john(a)wunderlich.ca ---------- Forwarded message ---------- From: The Sedona Conference <igg(a)sedonaconference.org> Date: 15 March 2016 at 10:47 Subject: Sedona 8th Annual Int’l Programme on CB Discovery, 7-8 June 2016 – Now Accepting Applications for Invitations To: John Wunderlich <john(a)wunderlich.ca> [image: Logo] [image: Facebook] <https://thesedonaconference.org/sites/sedona.civicactions.net/modules/civic…> [image: Twitter] <https://thesedonaconference.org/sites/sedona.civicactions.net/modules/civic…> [image: LinkedIn] <https://thesedonaconference.org/sites/sedona.civicactions.net/modules/civic…> The 8th Annual Sedona Conference International Programme on Cross-Border Discovery and Data Protection Laws 7-8 June 2016 Berlin, Germany [image: Apply Now] <https://sedona.civicactions.net/sites/sedona.civicactions.net/modules/civic…> ------------------------------ NOW ACCEPTING APPLICATIONS! The Sedona Conference is returning to Europe for its 8th Annual International Programme on Cross-Border Discovery & Data Protection Laws, to be held at the Hotel Adlon Kempinski in Berlin, Germany on 7-8 June. Programme Topics Include: - Key Changes to the EU-U.S. Cross-Border Discovery Framework: A practical look at the effects the new European legislation will have on EU-U.S.cross-border transfers in the context of litigation, government investigations, and internal investigations - Safe Harbor After the European Court of Justice (ECJ) Ruling: How did we get here and where are we going? A look back at the developments that brought us to the invalidation of the original Safe Harbor adequacy decision, what changed, and what to expect from the new EU-U.S. Privacy Shield - The Microsoft Ireland Case: Implications for the way the U.S. addresses data protection and the potential effects on cross-border discovery - The Application of Technologies in Data Protection: A dialogue on how technology can support data protection compliance For the Programme agenda and a list of faculty members, along with biographies, please click here to visit the Programme webpage <https://sedona.civicactions.net/sites/sedona.civicactions.net/modules/civic…> . The Programme is by invitation only to ensure a proper balance of participants, and participation is limited to ensure we have an intimate environment for meaningful dialogue. Please click here <https://sedona.civicactions.net/sites/sedona.civicactions.net/modules/civic…> to apply for an invitation to the Programme. We have secured a highly favorable group rate of EUR 240 per night on a limited block of Deluxe Rooms at the Hotel Adlon Kempinski for the evenings of 6-8 June 2016. The group rate also is available for the four days preceding (2-5 June) and the three days following the Programme (9-11 June), but completely subject to room availability because there is no room block for these nights. Complete hotel reservation information will be provided with your Programme registration confirmation email. Accordingly, you should submit an application for the Programme as soon as possible, so we can consider your application and extend an invitation to you to participate in the Programme in a timely fashion. A meet-and-greet reception will be held at the hotel the evening before the Programme begins, Monday, 6 June, from 18:00 to 20:00. Working Group 6 (WG6) members - please note that our traditional half-day WG6 members-only meeting will be held on Thursday, 9 June, from 8:30 – 13:00 (location TBA). 301 East Bethany Home Road, Suite C-297, Phoenix, AZ 85012 Phone 602-258-4910 Email info(a)sedonaconference.org Copyright 2016 The Sedona Conference You are currently signed up to receive newsletters. To unsubscribe click here <https://sedona.civicactions.net/index.php?q=civicrm/mailing/optout&reset=1&…> If you would like to resubscribe to receive emails from The Sedona Conference click resubscribe <e-3433-2398873-ca323f776eb82fd6@thesedonaconference.org?subject=I%20would%20like%20to%20resubscribe%20to%20TSC%20emails&I%20would%20like%20to%20resubscribe%20to%20TSC%20emails> -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

1 0

Neato privacy policies
by Eve Maler 14 Mar '16

14 Mar '16

On today's call, I mentioned a cool privacy policy I ran across when I downloaded this app: http://buddhify.com/privacy-policy/ The app costs $4.99, and I carefully looked at the policy and decided I was very willing to pay money -- and they were making the tradeoff very worthwhile. They based the policy closely on this (both are CC-licensed -- hooray for DRY content!): https://automattic.com/privacy/ BTW, the app is awesome too. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

5 24