- WG-UMA - mailman.kantarainitiative.org

What should the parallel requesting party claims endpoint in the extension spec be called in the config data?
by Eve Maler 24 Mar '16

24 Mar '16

Recall that we're likely to supplant the original endpoint (called requesting_party_claims_endpoint) with the enhanced-security one at the first opportunity, i.e. when we "open up" UMA Core for backwards-incompatible changes. Should we pick a name that's just descriptive for now like security_enhanced_claims_endpoint (what's in the current draft) and align to the original name when we open up the spec? Should we pick a wholly new name now and switch to that for "backwards compatibility" with what people are likely to be using in their implementations? If the latter, what should that name be? Please see today's meeting notes <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-03-17> for some suggestions and discussion. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 2

Fwd: Diagram
by Maciej Machulak 24 Mar '16

24 Mar '16

---------- Forwarded message --------- From: Maciej Machulak <maciej.machulak(a)gmail.com> Date: Thu, 18 Feb 2016 18:55 Subject: Diagram To: Eve Maler <eve(a)xmlgrrl.com> [image: Inline images 1] -- Maciej Machulak email: maciej.machulak(a)gmail.com mobile: +44 7999 606 767 (UK) mobile: +48 602 45 31 66 (PL) -- Maciej Machulak (sent from mobile)

1 0

Please review the extension spec and non-normative doc before tomorrow's WG call
by Eve Maler 24 Mar '16

24 Mar '16

Hi folks-- Please review the current review drafts (these are also linked in our agenda <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-03-24> ): - Spec <http://htmlpreview.github.io/?https://github.com/KantaraInitiative/wg-uma/b…> - Doc <http://kantarainitiative.org/confluence/display/uma/Understanding+the+Sessi…> We know there are a few editorial tweaks that need to be made to the spec, so please make sure to review substantive stuff. We'll be looking to do a WG vote on whether this represents a draft Technical Specification (official WG output, not just an editors' draft) that we can publish on docs.ki.org. Thanks! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

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