- WG-UMA - mailman.kantarainitiative.org

Oauth2 to UMA material
by Arlene Mordeno 28 Mar '16

28 Mar '16

Hello, Would anyone have any material on how an enterprise can transition from using Oauth into UMA, say a year from now? I am looking for infrastructure considerations when doing an enterprise IAM strategy. Thanks, Arlene

3 3

Notes from UMA legal telecon 2016-03-25
by Eve Maler 26 Mar '16

26 Mar '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2016-03-25 - Review current set of model definitions - Choose first trust relationship to work on for model clauses - Identify any model definition areas that need work given our choice - Decide/confirm our plan for first round of external review Attending: Eve, Paul, Kathleen, Adrian, Jon N, Ann, Jim We reviewed our model text <http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative…> with model definitions <http://www.commonaccord.org/index.php?action=doc&file=GH/KantaraInitiative/…>, with recent changes. What's the deal with the "D word" – delegation? If we qualify "delegation of *what*", then we can observe that there are several types, and we can map them to different trust relationships we have identified: - Resource Subject - Grantor (not in scope): This enables a "resource owner" to find someone else to actively manage resource access for them at an AS. - Grantor - ASO: This enables an always-on AS to be available to execute the wishes (policy conditions) of the Grantor. - RqP - Client Operator (not in scope; also not previously discussed as a model definition...) - Grantor - RqP Discussion about Grantor - RqP: Adrian doesn't think this is an appropriate use of the word "delegation". Eve believes "that train has sailed". [image: (smile)] See, e.g., the NZ POC <http://kantarainitiative.org/confluence/display/uma/Case+Study%3A+Users+Man…> . Regarding Adrian likes the distinction of "If you have a privacy policy, then there's an Operator involved; if you don't have a privacy policy, then you own it/wrote it." (It's personal to you and there's a 1:1 relationship between you and the software/service.) We have a new party with responsibilities now in scope! It's the Client Operator. Also, we're likely going to have to change references in the bodies of various model clauses from the Grantor to the Resource Subject, since the duty will be owed to the Resource Subject instead in a lot of cases. Which trust relationship should we dig into first? For reasons of our #RSctrl/#ROctrl use case <http://kantarainitiative.org/confluence/display/uma/UMA+Roadmap+for+2016> tension, and because it's the most "upstream" (no dependencies) trust relationship, let's start from RSO - ASO (see the clauses that start ASO... here <http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative…> and the clause that starts with RSO here <http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative…> – however, these are old and almost certainly don't reflect our latest discussion). There's a use case that could help us interestingly when we get to working on Resource Subject- and Grantor-involved model clauses, but will need to take into account some out-of-band machinations because it engages precisely the Resource Subject - Grantor relationship: a "digital death" use case. Alice (as her own Grantor) shares some digital data resources with Bob. She wants to arrange for her lawyer to become her Grantor when she dies, so that Bob can continue to get access to those resources. In practice, because of what are known (really) as "time-to-live" strategies around credentials, tokens, and permissions inside tokens, the access that Bob enjoys to those resources is certain to get cut off at some point after Alice dies. Using a combination of business, legal, and (non-UMA – including digital contract) technical approaches, Alice's lawyer can replace Alice as the owner of those resources and ensure through the AS that Bob's access can continue or be restarted. *AI:* Jim and Eve: Extract the two-party reworkings of the old model clauses for at least RSO - ASO and prepare for group review next week. *AI:* Everyone: Think about and approach candidate external reviewers by next week. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

3 2

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

25 Mar '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes 2016-03-25 - Review current set of model definitions - Choose first trust relationship to work on for model clauses - Identify any model definition areas that need work given our choice - Decide/confirm our plan for first round of external review *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 2

Draft minutes of UMA telecon 2016-03-24
by Eve Maler 25 Mar '16

25 Mar '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-03-24 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2016-03-17 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-03-17>: APPROVED. Issue 239 materials We agreed to remove "as the sole means of trust elevation" because SHOULD is the operative instruction regardless. Discussion of the new security considerations: We're not allowing both endpoints because it's a big mess to have to deal with "old" clients along with "new" clients. You'd have to flag clients in some fashion. So this section is something of a rationale for the endpoint swap. Eve suggested a slight wording change to give it this flavor. *MOTION:* Moved by Sarah. Seconded by Sal: Approve the "UMA Claims-Gathering Extension for Enhanced Security" specification, as to be amended, as a draft Technical Specification. APPROVED by unanimous consent. *AI:* Maciej and Eve (with Oliver): Publish the new extension spec. What to do with "progressing" this spec? Let's let it lie for now, and think about changes in "batch" with other 2016 roadmap work on the other specs. What sort of publicity should we do around this? Mention on wiki, on FB, etc. Talk about it at an UMA Update session at IIW? *AI:* Eve: Create an issue for the next minor rev of UMA (if there is one) to point back to the extension spec in some fashion and either deprecate it or absorb it, whatever is appropriate. Wide ecosystem We reviewed some previously discussed topics about wide ecosystem challenges. What value does the AAT bring? Based on current implementation and usage, it seems valuable for at least narrow and medium ecosystems, but in Justin's experimental work for wide ecosystem purposes he has done away with it entirely. Does a wide ecosystem actually require removing it if it turns out to be valuable for others? Sal points out that some IoT use cases also bring in special circumstances such as disconnection from the network. *AI:* Eve: Send wide ecosystem doc and graphics. Attendees As of 20 Feb 2016, quorum is 7 of 12. (François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Mike, Sarah, Ran) 1. Domenico 2. Kathleen 3. Sal 4. Thomas 5. Maciej 6. Eve 7. Mike 8. Sarah Non-voting participants: - Adrian - Justin - Arlene - Jin - John *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

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