- WG-UMA - mailman.kantarainitiative.org

UMA MVP for IoT
by Adrian Gropper 22 Dec '15

22 Dec '15

To help make UMA easier to understand and adopt, I'd like to propose a very simple IoT use-case. As background, check out the 1:23 video of McAffe pitching EveryKey. https://www.indiegogo.com/projects/everykey-your-only-key#/ What would this look like if all the locks, keys, and authorization servers were totally UMA standard and cost around $30? The use-case is pretty simple: - A door lock is a Non-Person Entity. It's the UMA Resource Server and, in addition to Resource Registration, it typically executes three commands: Register Key, Unlock Door, and De-register Key. The Resource Server Operator (RSO) is a home or office entity. - A key is an UMA Client, typically associated with a single person that might live in the home (Alice) or might visit occasionally (Bob). The key has two "buttons" labeled Register and De-Register. We make the assumption that all locks within a couple of feet unlock by proximity and that Register and De-Register add some kind of pairing dance such as a button and light on the lock and key. - Alice lives in the home and has an UMA Authorization Server. Alice's AS is generic and doesn't know anything specific to locks. Alice doesn't share her AS with her roommates. Alice is able to register her AS with the lock by authenticating with the RSO in-person. - Alice is now able to enable access by her friend Bob by sending to his smatphone an invitation email or text pointing to her unlock resource on the lock. Bob will use his Bluetooth key and his smartphone to register with Alice's AS and gain access. If Alice's AS happens to be nearby, this use-case might happen entirely over Bluetooth with no connection to the Internet. In this case, the status of the SSL certificates cannot be checked but everything should work. Other than the SSL certificates such as Let's Encrypt, this use-case leaks no private data to the cloud or to any external entities. The lock, the key, and Alice's AS are all assumed to be separate open source technologies. There are bilateral contracts between the operators of the lock (RSO), Alice as the AS operator (ASO), and Bob as responsible for the key (RqP). These contracts must all include a provision for Notice to the counter-party of the contract if the lock, AS, or key are lost or otherwise compromised. Ideally, each of the three technology actors (lock, key and AS) in this use-case could be a C.H.I.P. https://en.wikipedia.org/wiki/Next_Thing_Co. (It would be better if CHIP included a secure element, but that's a peripheral issue). Adrian <http://patientprivacyrights.org/donate-2/>

2 9

Reminder: UMA legal subgroup telecon 2015-12-18 (90 minutes; last meeting of 2015; please attend!)
by Eve Maler 17 Dec '15

17 Dec '15

*Please try and attend this one!* You will see candidate model clauses that need your review and input. Thank you! - *Fri Dec 18 8-9:30am PT (90 minutes)* - 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 - Review the first draft deliverable <http://www.commonaccord.org/index.php?action=doc&file=GHx/KantaraInitiative…> and its model clauses and definitions - How to take our work forward? Continue our subgroup meetings? - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

News from the Kantara board
by Eve Maler 16 Dec '15

16 Dec '15

https://kantarainitiative.org/an-announcement-from-the-kantara-board/ *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Action request: Review by Friday's UMA legal subgroup meeting
by Eve Maler 16 Dec '15

16 Dec '15

Jim Hazard and I have been working assiduously to prepare a *draft UMA legal deliverable* for you all. It's not very long, but it's got a lot of interesting "guts" (which you don't have to look at if you're squeamish :-). Particularly if you're a legal subgroup, *please* fix yourself a nice beverage, click over to this document <http://www.commonaccord.org/index.php?action=doc&file=GHx/KantaraInitiative…>, and settle in for about an hour's worth of *review and commenting* before our Friday meeting. Read the introductory section to understand what you're looking at and what to review for. If you're rusty on UMA particulars, you can look at the older Binding Obligations <http://docs.kantarainitiative.org/uma/draft-uma-trust.html> document and its links for context -- or feel free to *ping me with questions*. *Thank you very much* in advance for contributing to this important milestone! I'll send a formal agenda later today, but *please mark your calendar* for a 90-minute last-of-2015 legal subgroup call on Friday. Talk to you soon! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2015-12-17 (last of the year)
by Eve Maler 16 Dec '15

16 Dec '15

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-12-17 Date and Time - *Thu Dec 17,* 9-10am PT - 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 - Note: This is the last meeting of 2015 - Approve minutes of UMA telecon 2015-09-24 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-09-24> and UMA telecon 2015-11-05 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-11-05> - All-Member Ballot progress - Roadmap and charter refresh discussions: what topics are top-of-mind beyond what we listed last week? - UIG - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Comments on NIST Privacy-Enhanced ID Brokers due this week
by Andrew Hughes 14 Dec '15

14 Dec '15

Hello all - I'm assembling comments/feedback on the attached NIST whitepaper for Privacy-Enhanced ID Brokers. NIST is starting a project in the National Cybersecurity Center of Excellence and seeks input on this white paper, which will form the basis of the projects. Kantara will be submitting comments. Please reply to me if you wish to contribute & if you have comments, please use the attached template to send them to me. Deadline to NIST is DECEMBER 18 Deadline to me is Wednesday December 16 please. thanks andrew. *Andrew Hughes *CISM CISSP Independent Consultant *In Turn Information Management Consulting* o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000(a)gmail.com ca.linkedin.com/pub/andrew-hughes/a/58/682/ *Identity Management | IT Governance | Information Security *

1 0

Limitation of [ Legal ] Liability
by Adrian Gropper 13 Dec '15

13 Dec '15

I'm trying to understand the essence of an UMA Legal framework by picking a very simple but real-life use case and premise. Premise: The resource server operator (RSO) installs UMA because it limits their liability due to clients interactions. In other words, they are transferring some risk to an authorization server operator (ASO), otherwise they would just implement OAuth. For simplicity, presume: - a single resource: https://uma.rso.com/adrian/weight/readonly - terms of use: the data is only to be accessed by anyone, including rso, via the resource above - clients will present a valid SSL certificate and a token verifiable at the authorization server - this contract between RS and RO expires after one year or upon notice by either party Under these circumstances, the RSO has transferred most of the liability for interacting with a particular client to the ASO. This, I believe is the UMA Legal MVP. In a real-world use-case, the RSO may not be allowed to duck this much liability. For example, the RSO might be required by law to notify the RO that a particular Client / RqP is on an industry watchlist. In this case, the Client / RqP is providing attributes to both the AS and the RS. The RSO bears somewhat greater liability unless it can warn the RO via UMA the same way it might warn the RO via OAuth. Can the ASO bear the responsibility of warning the RO or must the RS warn the RO directly? As far as I can tell, this is the essence of UMA legal. Everything else is just an elaboration on one of the four bullet points above. This, incidentally, is the use-case I'm discussing with the US Office for Civil Rights. 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/

4 6

Notes from UMA legal subgroup telecon 2015-12-11
by Eve Maler 11 Dec '15

11 Dec '15

*Attending:* Steve, Andrew H, Ann, Adrian, Jim, Eve, Mark, Dazza *Agenda:* - Interest in a bit longer session this and/or next week? - Review of the list of draft deliverables to be produced - Review of Jim's candidate text and structures - Status of our budget proposal - How to take our work forward? - AOB *Proposed shape of draft deliverables:* - Model clauses for the various UMA role functions, both at a granular level and in the context of some templated agreements (think up-front "terms of service" in many cases) - Supported by all the necessary term definitions - As a sub-use case of this, templated "consent receipts" for a variety of cases when the party expecting some other party to function in an UMA role is themselves in an UMA Authorizing Party or UMA Requesting Party role - For example, instances where the Authorizing Party has created a policy for delating a right of access to a Requesting Party (there are others...) *Some technical considerations:* - A round-trip CmA format<->JSON mapping - A lightweight mechanism for technical integrity, so that the web location where an entire agreement gets saved off to contains within its URL a hash of the agreement itself *Notes:* *Logistics:* Andrew H can't stay long this week or next. Jim can stay 30min longer next week. Let's target that for next week. Mark and Adrian send regrets for next week. *Draft deliverables:* Andrew asks: Would "terms of service" include human-role demands on service-role functions? This would be VRMish thinking. Yes. It's ultimately all-way. This is important in the work he's doing. Adrian points to the PrivacyLens <http://www.privacylens.org> work that displays what part of the service you would lose if you turn off consent as a good idea. Mark discusses the "notice requirement" as part of the workflow of notice-consent. Andrew (Jim?) notes that redlining standard model clause text through CmA could be one way of showing what wouldn't apply if the user doesn't agree. Eve would like to put this topic aside because it's orthogonal, even if a good idea. *Technical considerations:* We have a lot of choices (depending on budget futures) for what sorts of comfortable LX (lawyer experience) we want to give for editing model clauses and agreements. What CmA's interface is doing right now is just a simply coded Markdown+HTML editing environment. Does it want to be a Markdown environment? A Word-to-Markdown environment? An HTML form environment? We could also be creating official JSON and even XML mappings. There's a question about whether we're supposed to also provide the actual UX for human ROs and RqPs. Eve is doubtful about our work being able to satisfy all the millions of needed presentations of the text for notice-consent workflows. Think web apps, mobile apps, IoT devices... But isn't this integrity problem -- that is, how to ensure that the text has been sourced from the approved place -- covered by the hash technique (used by Consent Receipts, we think)? We seem to have consensus that providing an LX solution (or multiple ones, as we determine later) is sufficient, as long as its technical layer includes a textual integrity solution so that broader UX solutions can leverage it in their notice-consent workflows. We started to look at "Test0 <http://www.commonaccord.org/index.php?action=edit&file=/GHx/KantaraInitiati…>", which has a few sample model clauses, and all the UMA definitions, embedded in an "access federation" agreement for all parties to which could be added all the larger (e.g. identity federation) agreement clauses and definitions. An older version that has all of the older binding obligations is "UMA/2013/2 <http://www.commonaccord.org/index.php?action=doc&file=GHx/KantaraInitiative…> ". This direction is starting to look good; however, Andrew would like to see more of an if/then structure. Dazza suggests looking at MITRE's trust framework and its Order of Precedence (text <https://github.com/mitreid-connect/trust-framework/blob/master/TrustFramewo…> and CmA <http://www.commonaccord.org/index.php?action=doc&file=GH/FutureCommerce/Sta…>). Andrew has a couple of government levels and then private-sector levels. It wouldn't be a good idea to "force" anyone trying to use our legal stacks/templates use too much of our non-UMA elements, since only the UMA stuff is really de novo. There's a lot of history and cruft out there. But since the whole CmA approach doesn't have to disturb the model clauses when reusing them in multiple contexts, we can eventually show multiple exemplars for different use cases -- e.g., for an HIE of One use case, a corporate federated authorization use case, up-front terms of service use cases, and various consent receipt use cases. And pretty much every legal document defines terms, so having a terms section would be pretty normal in most circumstances. *Our budget proposal, the legal subgroup, and 2016* We'll likely find out about our budget proposal in mid-January or so. The UMA WG would be responsible for oversight over spending that money, and this subgroup would be the specific natural place for it if we continue. Eve will propose a 2016 subgroup mission statement and timeline for next week, and get everyone's sense on that call. Andrew and Mark are supportive so far. *Actions for next week* *AI:* Jim and Eve: Revise the clause text, and create 2-3 exemplars leveraging the clauses, for consideration. *AI:* Eve: Speak to additional legal eagles and ask for their especial participation next week. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

GOTV efforts: assignments going out tomorrow
by Eve Maler 11 Dec '15

11 Dec '15

Tomorrow I will be approaching people who volunteered for the V1.0 effort (Sal, Colin, Mike, and Andi, along with myself) with assignments, and would love to have one or two more people volunteer in addition. The requirement would be for you to send short personal emails to 4-6 people and ask them to respond to the ballot with a Yes. In a handful of cases, I don't have any contact information at all for the Kantara member, so if you like to do a bit of sleuthing, or know a lot of the Kantara members, that would be a good reason to volunteer too. Thanks in advance, *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

The shape of UMA legal draft deliverables
by Eve Maler 10 Dec '15

10 Dec '15

Jim and I have been meeting frequently (Andrew and I a bit less so) and working on some homework to show y'all. Here is a description of the deliverables we're working on, which we'll be asking you to review -- and Andrew with his "business owner" hat on to review in more depth come January, if it passes muster in the group: - Model clauses for the various UMA role functions, both at a granular level and in the context of some templated agreements (think up-front "terms of service" in many cases) - Supported by all the necessary term definitions - As a sub-use case of this, templated "consent receipts" for a variety of cases when the party expecting some other party to function in an UMA role is themselves in an UMA Authorizing Party or UMA Requesting Party role - For example, instances where the Authorizing Party has created a policy for delating a right of access to a Requesting Party (there are others...) Some technical considerations of the CommonAccord (CmA) mechanism -- which we know our "first customer", Andrew, can't directly consume but will have to translate into something like MSFT Word for actual consumption -- that we would like to work on (but likely won't have ready immediately) include: - A round-trip CmA format<->JSON mapping - A lightweight mechanism for technical integrity, so that the web location where an entire agreement gets saved off to contains within its URL a hash of the agreement itself *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0