March 2016 - WG-UMA - mailman.kantarainitiative.org

Economics of Privacy
by Mark Lizar - OCG 24 Mar '16

24 Mar '16

Another good paper out this month. http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2580411 Alessandro Acquisti <http://papers.ssrn.com/sol3/cf_dev/AbsByAuth.cfm?per_id=57339> Carnegie Mellon University - Heinz College Curtis R. Taylor <http://papers.ssrn.com/sol3/cf_dev/AbsByAuth.cfm?per_id=156635> Duke University - Department of Economics Liad Wagman <http://papers.ssrn.com/sol3/cf_dev/AbsByAuth.cfm?per_id=1596912> Illinois Institute of Technology - Stuart School of Business, IIT March 8, 2016 Mark

2 2

Wide ecosystem analyses and solution proposals
by Adrian Gropper 23 Mar '16

23 Mar '16

I suggest UMA approach #wideeco in order: (1) Delegation > (2) Notification > (3) Authorization My reasoning is that #wideeco is primarily a multiple portals problem. This can only be solved by delegating the UX to a single-point-of-contact regardless of the nature of the resource and resource server. The ability to delegate any RS to the same AS means that there should be no barrier to the choice of AS and no limitation on the capability of that AS to provide a good user experience for the notification and authorization tasks to follow the RS-AS linkage. I consider Notification to be next in importance and also essential to user-managed access. In many real-world cases where I have limited control over how a resource is used, I still expect notification of how the resource is used. Notification also provides a potentially valuable service to the RS from a security and trust perspective even if no authorization interaction is expected. UMA's notification capability needs to be broadly applicable for all sorts of relationships with services and Things in the #wideeco. Finally, we get to authorization. Here, I expect support for localized interactions with mobile clients and resources that may not be able to reach the Internet and support for all sorts of identity providers for Bob and Bob's verified attributes. I also expect that my authorization and delegation policies will be opaque to the RS so that I can have a consistent UX across all kinds of resources and situations. 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

Privacy defining photos
by John Wunderlich 23 Mar '16

23 Mar '16

>From today’s CSM Passcode: Photo series: What does privacy mean to you? <http://csmonitor.us8.list-manage1.com/track/click?u=b06a12b90ba88b6eeea5d7d…> At the South by Southwest Interactive festival, Monitor photographer Ann Hermes asked that question. Her photo series shows that the people's attitudes toward privacy are deeply personal. Here's what she found out: "Privacy means fairness. How do we allow people to be treated appropriately in terms of their digital lives, as well as their offline lives. How do we ensure that they have access and control to their information?" *– FTC Commissioner Julie Brill* "Privacy is the ability to have safe spaces to associate with others and to share controversial ideas and to explore controversial ideas – without fear of the tyranny of the majority or the elites to prevent you from doing so." *– Kevin Bankston, New America’s Open Technology Institute* “As someone who comes from a background that isn’t necessarily the mainstream – my parents were immigrants, I’m South Asian, I’m gay – there’s all these things we have to think about our identities and what we reveal to the world. We all construct ourselves in different ways and privacy is a big part of that." *– G.S. Hans, Center for Democracy & Technology* "I think the principle is bigger than the threat for me - my stuff is not that secret, but I just don’t want it to be everywhere." *– Ville Ailio, consultant* *See the entire photo series here.* <http://csmonitor.us8.list-manage.com/track/click?u=b06a12b90ba88b6eeea5d7d9…> // Ann Hermes <http://csmonitor.us8.list-manage.com/track/click?u=b06a12b90ba88b6eeea5d7d9…> 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

The Death of Privacy? | TVO.org
by John Wunderlich 23 Mar '16

23 Mar '16

Worth watching The Death of Privacy? http://tvo.org/video/programs/the-agenda-with-steve-paikin/the-death-of-pri… -- 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

Agenda for UMA telecon 2016-03-24
by Eve Maler 22 Mar '16

22 Mar '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-03-24 Date and Time - *Thu Mar 24,* 9-10am PT (*N.B.:* SUMMERTIME SKEW IS OVER) - 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-17 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-03-17> - Final review of security extension spec (latest as of 2016-03-22 <http://htmlpreview.github.io/?https://github.com/KantaraInitiative/wg-uma/b…>) and non-normative doc <http://kantarainitiative.org/confluence/display/uma/Understanding+the+Sessi…> related to issue 239 - Wide ecosystem analyses and solution proposals - Roadmap checkin - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

"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