- WG-UMA - mailman.kantarainitiative.org

Neato privacy policies
by Eve Maler 14 Mar '16

14 Mar '16

On today's call, I mentioned a cool privacy policy I ran across when I downloaded this app: http://buddhify.com/privacy-policy/ The app costs $4.99, and I carefully looked at the policy and decided I was very willing to pay money -- and they were making the tradeoff very worthwhile. They based the policy closely on this (both are CC-licensed -- hooray for DRY content!): https://automattic.com/privacy/ BTW, the app is awesome too. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

5 24

[legal] Naming trust relationships before we define them: please review and respond
by Eve Maler 14 Mar '16

14 Mar '16

In today's legal subgroup call, we spent some time discussing which trust relationships are in our purview to "define" with model clauses. Adrian proposed a name for one of them. It seems like a great idea to name the trust relationships we're responsible for, partly as a shorthand for ourselves but also definitely useful for our "customers". (I also wonder if there's a conundrum here -- or maybe it's an easily solved one -- in that UMA builds up some two-party relationships into complex three-party relationships. Do we care? We have previously said that our clauses would all be two-party, with preconditions, so maybe it's as simple as that.) In order to make progress prior to next week's call, can we enumerate and try to name the relationships in email? I made a partial list of them in the notes. Here's an attempt at a more complete one in rough order of UMA flow, with our new terminology as best as I can apply it, and also with some naming proposals/discussion. (Some are "offstage" wrt our work, meaning we're not responsible for these agreements.) - Resource Subject - Grantor if they are different - This is "offstage" - RSO - ASO - Technical artifact that represents it: issuance of the client ID by the AS - Name proposal ("brute force" :-): "Protection API client agreement"? - Grantor - ASO - This actually exists prior to bringing in any specific RS connections; it's the inherent reason for the service. - Name proposal: "Authorization services agreement"? - Grantor - RSO - Any agreement a user might have with an online service might be "offstage" until the connection with the AS comes into the picture, either because of the ecosystem at large (prior arrangement) or because there's a moment where the AS and RS get sewn together with a protection API token (dynamic in some fashion) - Adrian has proposed "resource registration agreement"; I think I favor "resource protection agreement", because it should cover not just the phase 1/resource registration but also phases 2 and 3/all the respecting-the-token stuff - Client Operator - ASO - Technical artifact that represents it: issuance of the client ID by the AS - Name proposal: "Authorization API client agreement"? - Note that the Client Operator is not Bob, but the Person that created the client software or runs the client service - "Requesting Party" (for now) - Client Operator - This is "offstage" - "Requesting Party" (for now) - RSO - This is "offstage" - "Requesting Party" (for now) - ASO - Any agreement a user might have with the AS as some other kind of online service might be "offstage" until the connection for the purpose of it being an AS comes into the picture, either because of the ecosystem at large (prior arrangement) or because there's a moment where the AS and RqP get sewn together with an authorization API token (dynamic in some fashion) - Name proposal: "resource authorization agreement" to be parallel with my proposal above, and in keeping with the API names - Grantor - "Requesting Party" (for now) - This is the end-to-end trust relationship UMA really exists to make happen! :-) - Perhaps fine-grained legal agreements here could be captured as reciprocal consent receipts? - Name proposal: "resource sharing agreement" or "resource access agreement" If we can get on the same page about this stuff, does it make sense to publish a short paper explaining it for external readers? It would be a great artifact, particularly as we're getting close to our "end of Q1" deadline to present external reviewers with something to review. Notice that throughout, there's a legal context at which we're operating, and a corresponding technical context that it seems useful to refer to *but probably only non-normatively*. How should we handle that? Should we put it in "Comments" in our model definitions? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 3

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

11 Mar '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes 2016-03-11 - Do these terms work for us as model definitions? - Resource Subject: Person to whom a digital data resource relates - Grantor: Person who manages access to a resource, either as its Resource Subject or that Person's behalf - Grantee: Person seeking access to a resource - How to address the subject/grantor split in the tough use cases - Tackling model clauses for RO/RSO - Does the brute force method help? - How can we address #RSctrl and #ROctrl needs – can we actually enumerate the exceptions? Attending: Eve, Kathleen, Scott, Adrian, John W, Jim, Mary, Andrew, Thomas, Mark, Maciej (As an aside, the fact that we're using Thomas's paid join.me account and had trouble reusing it because multiple people on the call have the app is an interesting "property rights" use case that is relevant to our problem! There's the potential for misuse of the paid account and the company often stomps on simultaneous use.) Under consideration: Resource Subject: The Person to whom a digital data resource relates Grantor: The Person who manages access to a digital data resource, either as its Resource Subject or on that Person's behalf Grantee: The Person seeking access to a resource Is Grantee too "final" (vs. Requesting Party) given that they haven't yet been given access/had trust elevated? Maybe we need to split the RqP language similarly into two, to capture the states of "authorization not granted" and "authorization granted". To take an extreme example, there could be a policy condition that Bob the RqP gets access to some resource only on even-number hours of the clock. In this case, the AS can manage the token time-to-live characteristics very dynamically, the RS can check all the token authorization data frequently, etc. – but Bob will go from being a "potential Grantee" to being an "actual Grantee" really frequently. So the former phase or state is the more persistent, and the latter is the more transient. Trust elevation and degradation in Bob can be quite dynamic. (Also note that the same is true for the client app Bob uses.) Note that any trust relationship between the (requesting party bundle of concepts) and the Resource Server Operator is entirely invisible to UMA. According to our scoping of our work, it should likely be invisible to us too. ?? But the (requesting party bundle of concepts) and the Authorization Server Operator does have a trust relationship once the authorization API token is issued, so we need to take care of that set of obligations. - RSO - ASO (client ID) - RO (Subj/Grantor?) - RSO - ASO (PAT) - C - ASO (client ID) - RqP (trust elev/degr?: Grantee) - C - ASO (AAT) - RqP (trust elev/degr?: Grantee) - RSO = no UMA relationship ??? The "Adrian clause <https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html#give-access>" in the UMA Core spec is intended to reassure RSO's that they are free to elevate trust in the "requesting side" (that is, both the RqP and C) themselves. Note that the phrasing in the spec only allows further tightening; a clause a bit lower down makes clear that the intention is not for the RSO to enable *loosening* of access, although it's impossible in technical terms to prevent this. This is why we are working on how far we can take our model clauses to give RSOs the appropriate (and not *inappropriate*) flexibility to manage liability. Eve suggests a group norm: Let's talk about "notice" and "consent" as consent life cycle words, and "notification" as what happens apart from that life cycle, so heads don't explode. We agree on these model definitions for now: Resource Subject: The Person to whom a digital data resource relates Grantor: The Person who manages access to a digital data resource, either as its Resource Subject or on that Person's behalf We have discovered an important "phase split" in considering "Grantee", and can't really use it outright as a wholesale replacement for Requesting Party. For the world of devices, client apps, and so on, should we introduce "Agent"/"Entity"/something? Eve is wary of Agent from our legal discussions, but Kathleen could submit ideas to the list. Eve reviewed her "brute force version <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/ld7QQPycj…>" of the "RO-RSO" trust relationship. Note that the last bullet is the only one that represents a break-glass scenario; the party seeking access never established a trust relationship with the ASO, never got into the position of being a RqP/Grantee/etc., and is unknown (at least as far as UMA is concerned) to the RO. Adrian has introduced the term "resource registration agreement". Is this a good name for the overall agreement representing this trust relationship? ("Resource protection agreement"?) How do we square the circle of having two "three-party" trust relationships? How should we name each of the trust relationships? Let's try and bat this around on the list before the next meeting. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Who is interested in one final ad hoc call on issue #239 deliverables before next Thursday?
by Eve Maler 11 Mar '16

11 Mar '16

We have a normative spec (which I'd like to rev for consideration based on our conversation at the tail end of yesterday's call), a non-normative doc, and a new idea for a mitigation (which may or may not pan out but needs substantive discussion). All this could use a solid hour of time, which is tough to get on a regular call. Noting that next week we are *in summertime skew already* (North America springs forward while others don't yet), would one of these times work? - Monday 9am PT for 60 minutes - Tuesday 9am PT for 60-90 minutes - Thursday 8am PT for 60 minutes (that is, the hour before our WG call) Please respond privately to me ASAP, and I'll send put out a winning calendar entry with personalized invitations to those who can make it. Thanks! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

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

10 Mar '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes Date and Time - *Fridays,* 8-9am 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 2016-03-11 - Do these terms work for us as model definitions? - Resource Subject: Person to whom a digital data resource relates - Grantor: Person who manages access to a resource, either as its Resource Subject or that Person's behalf - Grantee: Person seeking access to a resource - How to address the subject/grantor split in the tough use cases - Tackling model clauses for RO/RSO - Does the brute force method help? - How can we address #RSctrl and #ROctrl needs – can we actually enumerate the exceptions? Attending: ... *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

[legal] The brute-force method of specifying what a RO wants (when it comes to a RS/RSO)
by Eve Maler 10 Mar '16

10 Mar '16

Mark L and I were IMing a couple of weeks back, discussing some of the things that could constitute "consent instructions" in UMA. I ended up typing out what I thought of as what Alice (y'know, the resource owner or her proxy/guardian/agent :-) wants some RS operator "X" to do on her behalf in "plain English": - Form an agreement with me and my AS operator "Y" to put some set of resources managed by me under the protection of that AS - I might or might not have had a choice about which AS I use, or which AS operators this RS operator will work with. But once we make this agreement, any of my resources that get registered for central protection do have to be under "Y"'s protection for realsies -- and I'm going to be telling "Y" how to protect the resources so they know what to put in the token that the RS eventually gets. - Within normal UMA operations, in the general case, have the RS do what the token from "Y" says to do when a client seeks access -- that is, give access when it says to and deny access when it says to, on the basis of what the client was attempting to do - Within normal UMA operations, in *limited* circumstances (tbd to be enumerated by us if possible, with model clause support????), enable the RS to deviate -- that is, to give access when the RPT says to deny access and to deny access when the RPT says to give access - Possibly requiring the RS to send a notification message somewhere (tbd????) - Outside normal UMA operations, in *limited* circumstances (tbd to be enumerated by us if possible, with model clause support????), enable the RS to give access on request - Possibly requiring the RS to send a notification message somewhere (tbd????) This is pretty much what I as a human being would expect UMA to "mean" wrt a RSO, giving them just enough of an "out" in case they have to live up to laws in their jurisdiction etc. Is this helpful in the spirit of having both Creative Commons human-readable and lawyer-readable text? :-) Should I keep going and write a brute-force list for what the RO/ASO relationship should "mean" and so on? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Summertime skew is coming
by Eve Maler 10 Mar '16

10 Mar '16

There is a roughly two-week period starting -- if my calculations are correct -- next week, when North America and other parts of the world experience what I refer to as "summertime skew" (as in "There ain't no cure for the...") because we all start/end daylight saving time on different dates. This group treats North America as canonical because, well, it's where I live. :-) So please doublecheck the Kantara UMA WG calendar <http://kantarainitiative.org/confluence/display/uma/Calendar>, and/or be sure you have calendar invites for our WG/legal calls showing on your own personal calendar, and/or get onto the UMA Chat on Skype, and/or browse timeanddate.com, and/or do whatever else is necessary not to miss a call during this weird period if you like joining the calls and not missing them by that much <https://www.youtube.com/watch?v=oPwrodxghrw>. If you have questions, please let me know. Thanks! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

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

10 Mar '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-03-10 MinutesDiscussion of Kantara's new organizational structure Is this new structure of any concern? It seems not; it's a mark of Kantara's growth and maturity. APAC-friendly meeting series Eve will reach out to those likely most affected if the series is changed to see if those people would mind if she offers ad hoc syncs instead. Roll call Quorum was not reached. Approve minutes Approve minutes of UMA telecon 2016-02-25 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-25>: APPROVED Updates from recent meetings and events *IAPP Canada:* John W was approached by an IAPP Canada organizer about doing a technical presentation, and he reached out to Andrew Hughes to help put together a panel on UMA, so as to inject more interesting technicality into the proceedings. John and Eve will sync on getting some good UMA slide fodder. 40% of the IAPP is made up of lawyers, so they'll have to go for the right level. We're looking at leveraging this into another opportunity at IAPP/CSA's "Privacy. Security. Risk." event in September. Yesterday's APAC-friendly meeting had a big focus on IAPP Canada preparations. *RSA:* Eve and Josh Alexander presented, and Eve got to spend a few minutes on UMA in the talk. She has been hearing repeatedly that UMA has been coming up in "third-party" conversations she isn't in. [image: (smile)] She has die-cut stickers to give UMAnitarians, and they got snapped up at RSA. She also had interesting side conversations about health, energy, other use cases for UMA (relevant tweet <https://twitter.com/IdentityHutch/status/705827488388100098>). *HIMSS:* Not a lot of UMA-related news. Justin gave an overview to the Argonaut and FHIR project folks, and it came up in conversation a few times. Adrian observes that they don't know of any pilots. François notes that he doesn't know of pilots either. Delegation is the key unique use case, where patients can delegate access. *Btc Expo:* Adrian heard some interesting avenues there. Andi has been hearing blockchain/UMA opportunities. *CIS:* Andi notes that there is a distributed ledger/blockchain track, and a privacy track as well. Everyone please register and book hotel rooms ASAP! (And don't forget to sign up for IIW <http://eventbrite.com/e/internet-identity-workshop-xxii-22-2016a-tickets-19…> .) Why UMA? Eve has asked Domenico (our UX and graphics editor!) to put together some material for our wiki to highlight the "Why?" of UMA for businesses as an important audience. He will share his research on the list. Eve would like to ask everyone to contribute new "collateral" to this area. The impetus was Robert asking Eve for use cases, and our finding that our Case Studies page doesn't suffice. Mike asks that we present Enterprise UMA more prominently as this is an easier sell than privacy. Therefore, Mike should contribute content. What about Pedro's use case? *AI:* Eve: Approach Pedro at Red Hat about their use case. A barrier is lack of libraries, including RS support. In fact, this has just come up on the UMA Dev list, and this is the exact purpose of the UMA Dev WG, right down to putting the emphasis on the RS. Eve also likes how Nat had published an easy Hello, World OIDC client app on his blog to show everyone how small and easy it could be. There are lots of great ways other than (boring?) slideware to document and persuade about UMA: - Pumpkin security theater - John is big on putting together an interactive whiteboard why-and-how presentation - A music video <https://drive.google.com/open?id=0B7aQF7z4Xp_yQVcxLUdiZzlLUVk> (this one is about privacy generally, from RSAC) - Other ideas <http://opencreds.org/> for presentation Issue 239 The main issue in the extension spec <http://htmlpreview.github.io/?https://github.com/KantaraInitiative/wg-uma/b…> is whether it can coexist with the main spec or whether it "stomps on" the main spec. This likely affects the extension spec title, several instances of language, and the configuration data design – it should probably invent a new endpoint that exists alongside the original endpoint. Coexistence would dictate changing our previous consensus about seeing little reason to deploy the "unenhanced" claims-gathering mechanism. Reasons for coexistence would be backwards compatibility with the existing UMA spec(s), and we still could make arguments for someone having a specialized environment that does claims-gathering and doesn't really need the enhancement. Note that the old endpoint would be marked for eventual deprecation and disabling. An important question is whether it's even possible to not support the old endpoint. George argues for it to be possible for an AS not to support the "old" endpoint on security grounds. And in fact, this could be very clean because you just don't support the "claims-gathering method" as offered by regular UMA. And now there's a draft non-normative companion doc <http://kantarainitiative.org/confluence/display/uma/Understanding+the+Sessi…>. Eve's thinking is that all vulnerabilities found in protocols such as this should come with docs like this as a kind of FAQ. *AI:* Eve: Ask the WG about one more ad hoc meeting early next week to see about finalizing decisions on spec text so we can close out the issue next week and publish. Attendees As of 18 Feb 2016, quorum is 6 of 11. (François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Mike, Sarah) 1. François 2. Domenico 3. Andi 4. Robert 5. Maciej 6. Eve 7. Mike Non-voting participants: - Adrian - John W - Justin - Gil - Arlene - George Regrets: - Sarah - Thomas *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Why UMA for Business
by Domenico Catalano 10 Mar '16

10 Mar '16

Hi all, I've researched a little bit about "Why Business needs UMA”. In attach a draft presentation, where I've gathered some ideas extracted and elaborated from the following resources: Customer Data: designing for transparency and trust <https://hbr.org/2015/05/customer-data-designing-for-transparency-and-trust> Social Physics and the data driven society <http://sites.nationalacademies.org/cs/groups/pgasite/documents/webpage/pga_…> New deal on Data <http://civics.com/NewDealOnData/> Extreme Trust <http://www.extremetrustbook.com/excerpt.html> The logic flow of the presentation is as follow (Know Why, Know How, Then What :-) WHY (Business Driver) Explosion of Digital technologies produces a vast quantities of data. Consumers appreciate data sharing if it can lead to products and services that make their life easer… Example (Nest, Medtronic, UBER) How social network can Make us smarter (Social Physics research by Pentland helps us to understand how idea flow from person to person through the mechanism of social learning and ends up shaping the norms, productivity and create output for companies, cities and societies). Business needs to use personal data to create best services and products, or for creating new stream of revenue. CHALLENGES Risk of Abuse increases tension and reduces the trust between consumers and companies. HOW Towards an Extreme Trust as competitive advantage New Deal on Data: approach that build trust Examples (Facebook beacon, Metadistretti e-monitor) WHAT User Managed Access: Business Value Proposition Template Target personas (template) Use Case (template) I hope it help for future extensions. Thanks. Domenico

2 1

Reviewing our issue #239 materials and considering a new mitigation idea
by Eve Maler 09 Mar '16

09 Mar '16

Maciej has prepared a new version of the extension spec, and it's now on GitHub <http://htmlpreview.github.io/?https://github.com/KantaraInitiative/wg-uma/b…>. And thanks to input from Sarah, I've put together a companion non-normative document on the UMA wiki <http://kantarainitiative.org/confluence/display/uma/Understanding+the+Sessi…> . In writing the final part of the companion document, I started thinking about a potential new mitigation idea when it came to describing why strong authentication *after* claims-gathering wouldn't work: I suddenly wasn't sure that strong auth doesn't work in all circumstances. *N.B.:* With this inquiry, note that my goal isn't to delay getting the word out about this whole thing! It's simply to consider any mitigation that might be reasonable, and discard it expeditiously if it doesn't fit. So I'm hoping we can examine it in our call and: a) reject it as unsuitable, b) reject it as technically suitable but failing some other criterion, or c) accept it as an alternate or additional mitigation. So here goes. Given the following: - The cycle of trust elevation (need_info) is repeatable, according to AS needs. (Which gives an interestingly flexible mechanism.) - Only trust elevation that uses the requesting party claims endpoint is susceptible to session fixation. ...I started wondering whether it *might* be viable to suggest the following as a mitigation: - The policy conditions include both some claim(s) being supplied and, *afterward*, Bob being able to authenticate, to some level of strength, as Bob. (That is, there is a certain authentication_context and identity required, whether explicitly in an error_details hint, or implicitly. Currently we only have an in-band way to indicate authentication hints, not the required identity.) Notice that a precondition for the attack is that Eve and Bob each have their own AATs, even though their clients have identical client IDs; this gives a hook for transaction context differentiation. The theory is that, if Eve were to initiate the session, phish Bob to gather his credentials, and then take over again after he's done, Eve would fail the second policy condition because she can't authenticate as Bob -- unless she also stole his credentials, and that's a different attack entirely. And if Bob started the session legitimately, then of course Eve missed her chance to phish him and he can pass the strong-auth trust elevation test himself. Recall that elevating trust through authentication_context is basically like refreshing/strengthening the AAT. If anyone wants to squeeze identity out of an AAT, it's best to use OIDC vs. plain OAuth for it. My investigations showed that using an AAT for trust elevation is not unknown -- in fact, it's known to both Gluu and ForgeRock, in cases where you expect the AS to serve as the IdP for the requesting party as well as the resource owner. I suspect there may be privacy considerations to doing this in other topologies that should be carefully examined -- such as, could a requesting party's "AAT identity" compromise him somehow if it is used as part of trust elevation in addition to "claims-based RqP identity" at the AS? I thought this was incontrovertibly true once, but I haven't been able to re-prove it to myself... That's probably enough/too much food for thought for now, from me. I know others will want to jump into the thread before the meeting with more. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0