- WG-UMA - mailman.kantarainitiative.org

Notes from UMA telecon 2016-09-29
by Eve Maler 03 Oct '16

03 Oct '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-29 MinutesRoll call Quorum was not reached. Approve minutes Approve minutes of UMA telecon 2016-09-22 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-22> : Deferred. Work on UMA.next issues We're wondering about the "authorization process" language in the new PCT definition. Instead of the three phases, we think a flowchart showing all of the AS responses to the client's request at the token endpoint (need_info and so on), and what the client has to do after that. E.g., if the client gets success and can then successfully access the resource, that's not "phase 3" but rather a successful singular termination of an "authorization process" and we should talk about it in that language. That's way more precise than just vaguely talking about "authorization process" without stating when such a thing starts and ends. The definition also needs to expand mentions of AS and so on, as we don't use the abbreviations in the spec. *AI:* Domenico and Eve: D to create a beautiful flow chart according to the current draft spec for slideware purposes and E to create an ASCII version for spec purposes. The current definition: "A correlation handle that represents a set of claims and interactions between the AS and the RqP/client pair during one authorization process to be used during future authorization processes. This MAY represent claims gathered interactively or pushed from the client. This MAY also represent any interactions the AS has with the RqP during this process, including any gathering of consent or authorization in any meaningful way. In short, this represents the sum total of the authorization process that a client went through to get its RPT (or even just trying to get its RPT). It’s intended to be used when this client gets a new RPT for this RqP at this AS, whether or not for the same resource or resource set and possibly for different policies or resource owners alltogether." A potential way to change it: "A correlation handle that represents a set of claims and interactions between the authorization server and the requesting party/client pair during one authorization process to be used during future authorization processes. This represents a set of claims and/or interactions; the authorization server MAY have gathered the claims interactively or the client MAY have pushed them, and an end-user requesting party MAY have provided consent or authorization in some fashion to the authorization server for persisting this information across authorization processes." Eve suggests moving the following text to Sec 1.3.2, where the conceptual explanation of the AAT used to be and where the conceptual explanation of the PCT kind of goes now: "The PCT represents the sum total of the authorization process that a client and its requesting part went through to obtain its RPT (or even just trying to get its RPT). It is intended to be used when this client obtain a new RPT for this requesting party at this authorization server, whether or not for the same resource set and possibly for different policies or resource owners." Looking at the name of the UMA grant, why "uma-ticket"? Is it because we have a "ticket pattern"? Okay. The PCT text in Sec 3.5.1 has us a bit confounded: "In circumstances where the authorization server returned an PCT previously when returning an RPT, the client MAY include the PCT. The PCT MAY have been obtained for a different resource at this AS, but since the PCT likely represents claims from the RqP it MUST be associated with the current RqP to the best of the client's abilities to determine this." Let's unpack this. In the OAuth-based AAT solution, authentication would have been required, and the client would known for a certainty whether it was the same RqP. Now, it doesn't know for sure. Plus, if it's requesting access to a different resource, the policies and therefore trust elevation requirements could be different; hence, whatever package of claims and/or interactions might be different. The client can't know a priori. But the PCT is meant to be associated with "the same RqP" as far as the client is concerned, regardless of whatever trust elevation is required on the AS side, and regardless of whatever the AS requires, don't all clients pretty much require some kind of authentication for their own purposes? So couldn't any client do correlation of PCTs with their own users with 100% certainty? *AI:* Eve: Get Justin's input on our analysis and questions. In Sec 3.5.2, the first appearance of set math is hinted at: "The authorization server evaluates the policies in light of claims gathered from the client. These claims MAY be pushed directly by the client using the claim_tokens parameter, MAY be gathered interactively at the interactive claims gathering endpoint, and MAY be *represnted* by the persisted claims token (PCT) present by the client in the pct *paramter*. The authorization server MAY combine claims from these sources in any manner it chooses, though a simple union of all claims is reasonable." (Note and fix typos.) James had proposed set math as follows: (ASDefaultClientScopes UNION ClientRequestScopes UNION PermissionTicketScopes) SUPER_SET_OR_EQUAL_TO PermissionTicketScopes The questions for the spec are: - What does the RS have to do at API publication time, if anything? - There *will* be scopes published, whether in informal fashion or, say, Swagger (machine-readable) - Nothing much more to say about this, probably (we have some editorial notes on it) - What does the client have to do at scope registration time, if anything? - It's never required for a client to register for scopes, but it could; this would limit what's possible for it to handle (we have some editorial notes on it) - *What does the RS have to do at permission ticket registration time?* - In UMA1, we've said it must register at least what the client attempted to access, but Justin has proposed letting it register any number of scopes, more/less/other - This remains to be fully discussed, though we started it at CIS - *Can the client request scopes from the RS (in addition to just attempting access)?* (added after the call: see George's comments from 2016-08-04 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-08-04> about efficiency of client communications for smart clients) - What does the client have to do at RPT request time? - *How does the client request scopes from the AS, and what can it ask for (e.g., what interaction does it have if it wants multiple resource sets)?* - In UMA1, the client couldn't ask for anything explicitly, but Justin's MPD exploration has made it possible (though not required) for the client to request scopes and we've agreed to make this possible - What does the AS have to do at RPT issuance time? - In UMA1, we've said the AS can issue a partial set of scopes if policy is only partially satisfied – are we still okay with that? We haven't discussed it - There are circumstances where only full matching will do (say, enterprise), and others where partial satisfaction would be good (consumer) Spec instructions: - See above! Attendees As of 31 Aug 2016, quorum is 6 of 10. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Sarah) 1. Domenico 2. Sal 3. Nagesh 4. Robert 5. Eve Non-voting participants: - Andrew - Scott F - Kathleen - James Regrets: - Mike - John W - Andi *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

3 9

Re: [WG-UMA] Consider the naming of entities and concepts (#256)
by Mike Schwartz 01 Oct '16

01 Oct '16

>>> confusion around an UMA client vs. an OAuth client... I find the term "UMA Client" particularly confusing, because the RS is also an OAuth2 client when it obtains a PAT. >>> * trust elevation vs. claims gathering (interactive exclusively?) To me, trust elevation implies increased level of assurance about the identity (i.e. just the subject identifier). While additional claims can increase your trust, and perhaps each claim can carry it's own assurance, I think seperating identity from claims would be more clear.

2 1

APAC sync time is now in our calendar
by Eve Maler 01 Oct '16

01 Oct '16

Hi folks-- I've put an APAC sync time in our calendar, starting next week and continuing every four weeks for at least the rest of the year. Let's see how this goes. Sample time equivalents: - Seattle / Sydney / Wellington - Tue Oct 4 4pm / Wed Oct 5 10am / Wed Oct 5 noon - Tue Nov 1 4pm / Wed Oct 5 10am / Wed Oct 5 noon - Tue Nov 29 4pm / Wed Oct 5 *11am* / Wed Oct 5 *1pm* If anyone *in the region* wants me to add them to the event invitation, let me know. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

UMA legal: Let's meet IF we've got new use cases to look at
by Eve Maler 30 Sep '16

30 Sep '16

Being a bit mentally burned out from so many (good!) WG and DG calls this week, I'm going to put Scott D somewhat on the spot, and for that I apologize. :-p If we happen to have some new legal use cases to look at from his action item, like the ones we analyzed last week, great -- let's get together. If not, let's use the time for other homework. I'll keep an eye out, and give people a 10-minute warning on Skype if we'll be meeting. If you're not on Skype, let me know your favorite synchronous way to be warned. Thanks, *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 1

Agenda for UMA telecon 2016-09-29
by Eve Maler 28 Sep '16

28 Sep '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-29 Date and Time - *Thursdays,* 9-10am PT - Skype: +99051000000481 / US +1-805-309-2350 / international lines <https://www.turbobridge.com/join.html> / web calling interface <https://panel.turbobridge.com/webcall/> / code 1782540 - Screen sharing: http://join.me/findthomas - NOTE: do not use the join.me dial-in line - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2016-09-22 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-22> - UMA video and IIW - Work on UMA.next issues - Core is up to 02 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-02.html> - RSR is up to 00 <https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-00.html> - Persisted claims token and other changes – see this difference set <http://See this difference set> - Work on set math – see this email thread <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/wv3A4WiL4…> - Getting consensus on all the latest changes and queuing up the next bunch of work - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

New 02 rev of UMA Core
by Eve Maler 27 Sep '16

27 Sep '16

Justin's latest edits are incorporated.* https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-02.html Please review for "persisted claims token (PCT)", rotated permission ticket, and other related language. On Thursday we'll dig in to UMA grant design and set math. I'd like us to think about how how complete we can make this before IIW. *Maciej struggled with the spreadsheet and I struggled with XMLmind, and we both have been losing so far. :-) Therefore, what you'll see here has errors where proper RFC references should be, and I decided not to bother updating the publication date just to have a whole bunch of other pointless changes (spaces in empty elements) show up at the same time. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

MPD Rewrites
by Justin Richer 24 Sep '16

24 Sep '16

As requested on the last call, I’ve taken an axe to the UMA specification and incorporated text and concepts from the MPD proposal sets. The new spec text (still rough in many spots) is available here: https://github.com/jricher/wg-uma/commits/mpd-rewrite <https://github.com/jricher/wg-uma/commits/mpd-rewrite> Specifically, this difference set: https://github.com/jricher/wg-uma/commit/ae82fe797229827e0cd3dfc2264268ea36… <https://github.com/jricher/wg-uma/commit/ae82fe797229827e0cd3dfc2264268ea36…> I added language on PCT’s (based on the model I outlined in the other thread), I changed the “scopes” parameter to “permission_scopes” as in the MPD implementation, I changed the interaction and examples to use the token endpoint for the RPT request, I moved the discovery document to .well-known/uma2-configuration and fixed a couple parameters, and I incorporated the rotating ticket mechanism from the security extension we wrote this spring. Sorry it’s all in one commit, but I found it easier on my end to just plow through the whole spec. — Justin

2 1

Notes from UMA legal telecon 2016-09-23
by Eve Maler 23 Sep '16

23 Sep '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2016-09-23 - Working session on User-Managed Access (UMA) in Contractual and Regulatory Contexts <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHK…> - Today's meeting is at 10am PT/1pm ET/6pm UK/7pm CET - Same bat channel Attending: Eve, Ann, Scott D, John W, Mary Eve's slides that show four "BLT use cases" are here <http://www.slideshare.net/ForgeRock/usermanaged-access-why-and-how-access-c…>. In UC3 (Alice oversees 12-year-old Susie's online usage), there are different kinds of harm that we're trying to protect against. Some are about inbound data sharing, some are outbound data sharing, some have other natures. Also, the diagram doesn't show that Susie is expected to be able to use her UMA client in turn as a downstream UMA RS. In some contexts/jurisdictions, there are rights that Susie would have that need to be protected as well. The "age of majority" subtleties hinge on various ages, and it can be a combination of a legal and a contractual status. We've imagined that it would be a technical status (PAT revocation) that would reify the status change that would allow "timing in" of legal capacity. Though the primer probably wouldn't go here, and our UC diagrams are static, we could theoretically write UMA profiles that specify "state changes" such as PAT revocations and such that are legal capacity-dependent, perhaps in some complex workflow relationship with the type of the digital resource being protected. This could even enable "smart regulation". The Past Is a Foreign Country <https://www.amazon.com/Past-Foreign-Country-Revisited-ebook/dp/B00IO0E2FM/r…> – can we overcome our biases about how we've done things previously? We suspect that this challenge is actually operational, rather than heavily theoretical. Once an AS knows the age of a resource owner, and an RS can share well-known semantics about a resource set type with the AS, then policy conditions can connect the dots about jurisdictional constraints on sharing information about, say, pregnancy test results once the resource owner is "of age". Thinking modestly once again [image: (smile)], we do have to prepare for the technical layer to fail gracefully in a privacy-protective fashion as the other layers vary. The technical layer (modulo our question about a client turning around and becoming a downstream RS?) stays the same no matter what happens at the other layers around it. The legal capacity picture around it is *really interesting:* - When you're young, you time-in to legal capacity - When you're old, you time-out of it - At some times in life, you might intermittently go into and out of it - Drunk or otherwise impaired (meds/drugs, distracted, tired) - Coerced (gun to your head) - Dementia but functioning - In Ontario law, there is a notion of "assumed implied consent" that lets someone take over for you if you're bleeding out on the ER table – a kind of break-glass right How can we model this? Is it all down to revocation of the PAT? UMA doesn't have a notion of multiple resource owners, which presents a bit of a challenge. John shared this blog post <http://blog.priv.gc.ca/index.php/2016/09/22/how-fit-is-your-gadget-putting-…> about privacy and fitness devices. We had been thinking in terms of Ts & Cs that are relatively static for the (mostly) pairwise relationships between parties. Where could "smart contracts" introduce dynamism/configurability? The obvious place this had come in was in trust elevation, which is a Grantor/Grantee relationship. Where else could it apply? See our "trust relationship" discussions in the April notes (start here <http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note…> and work back). Counterintuitively, injecting more democracy into previous feudal systems has the effect of creating more dynamic stability. That's what we're talking about here. (Not to put too fine a point on it. [image: (smile)] ) *AI:* Scott D: Take Eve's slides containing four use cases and "translate the technical stability into a persuadable view of stability and value in other regimes" for use in the primer. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA legal telecon 2016-09-23 (today) -- two hours later than usual
by Eve Maler 23 Sep '16

23 Sep '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… Date and Time - *Fridays* - Voice: Skype: +99051000000481 / US +1-805-309-2350 / international lines <https://www.turbobridge.com/join.html> / web interface <https://panel.turbobridge.com/webcall/>, code 178-2540# - Screen sharing: http://join.me/findthomas – NOTE: do not use the join.me dial-in line - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar 2016-09-23 - Working session on User-Managed Access (UMA) in Contractual and Regulatory Contexts <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHK…> - Today's meeting is at 10am PT/1pm ET/6pm UK/7pm CET - Same bat channel *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

Draft minutes of UMA telecon 2016-09-22
by Eve Maler 22 Sep '16

22 Sep '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-22 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2016-09-01 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-01> , 2016-09-09 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-09>: APPROVED by acclamation. Persisted claims token discussion Justin has essayed an implementation <https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/commit…>. MatchAllClaimsOnAnyPolicy can pass in a PCT, and takes a union of the claims that are in the ticket and the (optional) PCT. PCT creation is straightforward (though not quite working yet because of a particular upstream library limitation). This basically tests what has to change, and the delta is relatively minimal (after having yanked out AATs and switched to using the OAuth endpoints vs. the RPT endpoint). The AAT required a requesting party to authorize usage of the authorization API, which came bundled with the ability to optimize future trust elevation processes. No local AS account was required, though this might be a common way to do things. It used OAuth, and thus the RqP was required to act as an OAuth resource owner – which is too identification/authentication focused. We are now considering breaking apart the abilities to: 1. Elevate trust in the requesting party in a variety of ways (not just, say, requiring uniquely identifying authentication, as most OAuth-based account management implementation requires) – which has been a goal of UMA all along with its concept of CBAC 2. Optimize future such processes 3. Enable authorization for such optimization Since there's "no OAuth to lean on" in talking about Bob's authorization for his client's interactions with the AS authorization interface now, what would it mean if the client were to be able to push claims before he could authorize that? This could have happened in OAuth too, e.g. through implicit flows, and employment contracts that okayed SAML assertion flows and the like. Now, we're sort of acknowledging that authorization has always been in the realm of heuristics, but we'll have to be more explicit than we had been previously that deployers need to ensure they're presenting RqPs with the right authorization choices at the right time. The AAT was required and early-bound, and went out of its way to use OAuth's front channel; now it's optional and later-bound, with more options as to timing and UX, and goes out of its way to use OAuth's back channel. We can perhaps get more specific in our instructions for the "UMA grant" (the client-AS interface) vs. the "authorization interface" (everything else). Also, when the RqP isn't an end-user but rather operating a client autonomously, we've found a more elegant way to accommodate both "legal persons" and "natural persons", as the former don't go around authenticating. Domenico's new graphic <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/ZvcYx3ilO…> captures these concepts nicely. Spec instructions: - Justin to propose PCT text by end of week. Attendees As of 31 Aug 2016, quorum is 6 of 10. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Sarah) 1. Domenico 2. Sal 3. Nagesh 4. Andi 5. Robert 6. Eve 7. Mike 8. Sarah Non-voting participants: - John W - Andrew - Scott F - James - Jin - Justin - Arlene - Ishan - *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0