- WG-UMA - mailman.kantarainitiative.org

UMA diagrams and flowchart
by Domenico Catalano 06 Oct '16

06 Oct '16

1 0

Editors' draft 03 is up
by Eve Maler 06 Oct '16

06 Oct '16

Draft 03 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-03.html>. We're starting to make enough invasive changes that reading it through more comprehensively is a good idea, but here are the difference sets <https://github.com/KantaraInitiative/wg-uma/commits/mpd-edits> to pay close attention to: - First wave of edits <https://github.com/KantaraInitiative/wg-uma/commit/c7982502dc87557509dc5b21…> after last Thursday - Ignore the trivial stuff and hunt for lines 288, 392, 418, 1196 (edited more just below), 1307 (a bit) - In future, I'll try and isolate that extra-space stuff into a separate commit - Second wave of edits <https://github.com/KantaraInitiative/wg-uma/commit/9316db4f5202d163e11aa1f0…> after last Thursday - Implemented <https://github.com/KantaraInitiative/wg-uma/commit/2521674d9f186f6b5676d29c…> issue #251 - Quick cleanup of permission ticket language Domenico has done some nice flowchart-y graphics around the notion of "authorization process", "authorization interface", and the new token landscape we can look at together tomorrow. Let's see if we can get quorum, cement decisions around this direction, and settle on set math decisions (what flexibility does the RS have? what are the parameters within which the client works? how does this all work when it's possible to register multiple resource sets when getting a permission ticket?) tomorrow. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

Agenda for UMA telecon 2016-10-06
by Eve Maler 05 Oct '16

05 Oct '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-10-06 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> - IIW - UMA 101 session leader - Video premier(s) - Work on UMA.next issues - Core is up to 03 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-03.html> - RSR is up to 00 <https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-00.html> - See email <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/t3VvdkCvf…> for list and description of the latest changes and discussion agenda - Review Domenico's diagrams - FB page <https://www.facebook.com/UserManagedAccess/> care and feeding ideas - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Reminder: UMA APAC sync tomorrow
by Eve Maler 04 Oct '16

04 Oct '16

*Purpose:* Synchronizing on current work with APAC-based participants and gathering their input. *RSVPs* from those in the APAC region (sent directly to me) will be much appreciated! - Sample times: Seattle Tue Oct 4 4pm / Sydney Wed Oct 5 10am / Wellington Wed Oct 5 noon - Skype: +99051000000481 - US toll: +1-805-309-2350 - Sydney: +61.2.8014.4647 - Additional international numbers: https://www.turbobridge.com/international.html <https://www.google.com/url?q=https%3A%2F%2Fwww.turbobridge.com%2Finternatio…> - Web: https://panel.turbobridge.com/webcall/ <https://www.google.com/url?q=https%3A%2F%2Fpanel.turbobridge.com%2Fwebcall%…> - Code: 178-2540# - Screenshare: http://join.me/findthomas <https://www.google.com/url?q=http%3A%2F%2Fjoin.me%2Ffindthomas&sa=D&ust=147…> (DO NOT USE join.me <https://www.google.com/url?q=http%3A%2F%2Fjoin.me&sa=D&ust=1475556106312000…> dial-in number) - See the calendar entry for more details: http://kantarainitiative.org/confluence/display/uma/Calendar *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

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