- WG-UMA - mailman.kantarainitiative.org

"Designing Incentive Schemes for Privacy-Sensitive Users"
by John Wunderlich 22 Mar '16

22 Mar '16

An FYI Warning: Math Ahead http://repository.cmu.edu/jpc/vol7/iss1/5/ 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

Notes from UMA legal telecon 2016-03-18
by Eve Maler 19 Mar '16

19 Mar '16

[John W, forgive me: I unilaterally changed how the "nonfunctional requirements" table headers read after the meeting. If we want to change them back, great... I was just confused reading them after a few hours had elapsed...] 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? Attending: Eve, Kathleen, John W, Sal, Ann (regrets from Adrian, Mark) *AI:* Eve, Jim: Revise our CmA model definitions with new consensus definitions. Eve's premise was that anything with an UMA technical artifact really has to be in scope, and a direct relationship with any service operator with an UMA-specific purpose for existing (namely the AS operator) seems plausible to be in scope. Would it be useful to write an explanatory document for reviewers about these relationships? Should we be naming the agreements at all? There will be multiple actual agreements, for example, at different phases, or for whatever reason. And (channeling Jim) there are literally different agreement/contract workflow phases such as offer, acceptance, etc., and different sides of the equation might be offering or whatever. And given that English is only our first target language and not our only one, perhaps it should be a principle of ours that we should name as few things as we can get away with, so as not to have "language skew". Since our ultimate deliverables are at the size of "clauses", we need not care (for purposes of discussing trust relationships) about the larger combinatorial things into which they're mixed. Jim has put together quite a few assembled agreements, contracts, offers, etc., and we might do the same with our clauses as exemplars, but in the main we expect they'll be non-normative. So we've saved the candidate names, but kept them non-normative. We have established to our satisfaction that there is complete separation between the legal and technical work of UMA by demonstrating that a technically conforming deployment of UMA services could be out of compliance with the data protection laws of some jurisdiction. Our "Russian example" is apt here: A Russian Grantor cannot legally allow a non-Russian "Requesting Party" access to their own data. The clauses need to set up the correct preconditions for a deployment of UMA that encourages a "race to the top" in a greater alignment of incentives among the parties and in behavior that is compliant to relevant nonfunctional requirements (such as regulations). John notes: "Makes me think that we need something like: Authorizing Server Operator - Regulating Body: Allowed-To-Release" Trust relationship Dependencies on existing nonfunctional requirements In scope for model text work? (Candidate names of agreements formed out of our official clauses) Technical artifact Dependencies on existing technical artifacts Discussion Resource Subject - Grantor (if they are different) n/a No n/a n/a n/a RSO - ASO n/a Yes Protection API client agreement OAuth client credentials for RS n/a Grantor - ASO n/a Yes Authorization services agreement n/a n/a This has no technical artifact in UMA, and therefore no exact or obvious moment of appearing "on stage" for our work. Does this have an impact on whether it is in scope based on the rationale above? We agreed there are definitely reasons to have UMA-specific clauses, looking at our draft ones. Grantor - RSO RSO - ASO Yes Resource protection agreement PAT OAuth client credentials for RS It's awkward to have a two-party agreement resting on a PAT. There are plenty of agreements where there are multiple Persons in one of the roles, but we're not so sure about true three-role agreements. Client Operator - ASO n/a Yes Authorization API client agreement OAuth client credentials for Client n/a We have not scrutinized the definition of Client Operator. Let's put a pin in that to be sure it's okay. "RqP" - Client Operator n/a No n/a n/a n/a We need to work on the term for "RqP". Let's put a pin in that. "RqP" - ASO Client Operator - ASO Yes Resource authorization agreement AAT OAuth client credentials for Client The same discussion about n-party agreements above applies here. Grantor - "RqP" Resource Subject - Grantor, RSO - ASO, Grantor - ASO, Grantor - RSO, Client Operator - ASO, "RqP" - Client Operator, "RqP" - ASO, Grantor - "RqP" Yes? Resource sharing agreement Resource access agreement Trust elevation mechanism and specifically claims subprotocol OAuth client credentials for RS, PAT, OAuth client credentials for Client, AAT Could be in the form of a consent receipt, sent to a notification endpoint. Is this trust relationship too "dependent" to be in scope, or does the calculus work? More discussion is needed. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 3

Implementation of UMA issues
by Justin Richer 18 Mar '16

18 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 16 Mar '16

16 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