April 2017 - WG-UMA - mailman.kantarainitiative.org

Pre-session ad hoc on Wed 9am PT/5pm UK; big decisions on Thursday
by Eve Maler 25 Apr '17

25 Apr '17

Andi, Cigdem, and I are going to meet tomorrow, Wednesday, at 9am PT/5pm UK to review the refactored specs. You are very welcome indeed to join us, but you *MUST* let me know ahead of time (i.e. *NOW*); right now we're just planning to meet on Skype. On Thursday, we need to make a key decision on the refactoring direction, remaining open issues, and our timeline. So far the response has been positive on the grant spec; we need to be just as certain about the federated authorization spec (which is currently in an inconsistent state, but I'll send out a link before Thursday's call). *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2017-04-20
by Eve Maler 21 Apr '17

21 Apr '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-04-20 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2017-03-09 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-03-09>: Deferred. UMA V2.0 work *#293 <https://github.com/KantaraInitiative/wg-uma/issues/293>*: Consensus on pushing only a single claim token being "hunky dory" (a good idea). *#298 <https://github.com/KantaraInitiative/wg-uma/issues/298>*: The redirect-back paths look much cleaner now. *#290 <https://github.com/KantaraInitiative/wg-uma/issues/290>* (Generality of RReg spec?) and *#296 <https://github.com/KantaraInitiative/wg-uma/issues/296>* (Out-of-the-box profiling for tight AS-RS coupling): We looked at the new oauth-uma-ticket rev 00 <https://docs.kantarainitiative.org/uma/ed/oauth-uma-ticket-2.0-00.html> experimental spec. General support for this approach, though we don't have a federated authorization spec yet. Can we sync the high-level flow diagram more with OAuth's abstract protocol flow diagram? Andi says: "I like this effort to re-architect the way the specs are laid out, Eve. Happy to help if I can (dm me later if so and we can discuss)." Cigdem says: "I think if we want to provide a comparison to OAuth - comparison via "abstract protocol flows" maybe more appropriate. In this case (C) Authorization grant: includes ticket, claims collection, RqP interaction etc. for UMA, After that we can have the more detailed flow diagram." So we could have two diagrams, where the first indicates explicitly the mapping to OAuth's letters A through F. Why do we still have registration_endpoint metadata? Sort of historical (because our group wrote the first dynamic client registration spec)? Should we consider dropping it? People could just use the OIDC spec, or the draft OAuth metadata spec, to declare their registration endpoint. Eve will make an issue to consider this. (DONE <https://github.com/KantaraInitiative/wg-uma/issues/305>.) Ishan points to the OIDC wording: "Additional Client Metadata parameters MAY also be used. Some are defined by other specifications, such as OpenID Connect Session Management 1.0 [OpenID.Session]" Since we've never had an "UMA grant" per se before, should we overtly label this as UMA2? Seems to make sense since UMA1 is out there (and we have semantic versioning!). Eve has done so, sort of, but will make it more obvious. "Permission" has been defined, but is there actually any reason to do so? It doesn't seem like it. In the spec swimlane, the redirect and redirect-back, there should probably be two arrows/steps, since there are two whole sections for this. This is only a "sample high-level flow" in that there are pushed claims followed by interactive claims gathering followed by success. The client approaching the resource first, with the whole ticket flow etc., is not optional. The swimlane should use very short phrases with a list following, a la 6749's style. Sec 1.3.2's claims collection discussion should clarify that while claims collection is probably not really optional, claims don't strictly have to be collected through UMA messaging; it could be done out of band (don't use that phrase?). In the section on Endpoints, the last paragraph may be out of place. *AI:* Eve: Propose an ad hoc early next week for at least her, Andi, and Cigdem (others welcome) to work on the refactored specs. Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Sal 3. Andi 4. Eve Non-voting participants: - Ishan - John - Crina Regrets: - Justin - Maciej - Mike *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

UMA Legal: meeting tomorrow 8am PT to discuss deliverable #2 topics
by Eve Maler 20 Apr '17

20 Apr '17

<eom/> *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft UMA grant spec for your perusal
by Eve Maler 20 Apr '17

20 Apr '17

https://docs.kantarainitiative.org/uma/ed/oauth-uma-ticket-2.0-00.html I *might* get time to do at least a partial federated authorization spec tomorrow early morning -- we'll see. Please weigh in here if you manage to get time to skim it before the call. (In the course of working on this spec, I ruthlessly chopped out lots of duplicative text, partly because one purpose was to get things more readable and partly because the spec was getting short enough that the main sections were ending up next to each other in most cases, with little need to do cross-references to make sense of the three-party "dance" through links. But I think quite a few of the edits could be back-ported to the existing specs, if we ultimately don't like the refactoring idea. I'm keeping track of a few key editorial things I want to do regardless even of this back-porting notion.) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2017-04-20
by Eve Maler 19 Apr '17

19 Apr '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-04-20 Date and Time - *Thursdays, 9-10am PT* - Screenshare and dial-in: http://join.me/findthomas - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2017-03-09 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-03-09> - UMA V2.0 work: - All GitHub issues for V2.0 <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…>/ dynamic swimlane <http://www.websequencediagrams.com/files/render?link=Pu0sP0Oe2kjKc2WgdKZd> - Core is up to 21 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html> and RReg is up to 08 <http://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-08.html> (back to editors' drafts) - Most issues were proactively closed because we had good consensus on substantive issue discussions and/or the issues were editorial - What was done (you've had this list since Monday): - #293 <https://github.com/KantaraInitiative/wg-uma/issues/293>: Check/fix all examples for missing required (and optional) fields; other editorial (the not-quite-editorial change to "flatten" the pushing of claim tokens so that a client pushes one claim token at a time; see Core Sec 3.6.1 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html#uma-grant-ty…> ) - #294 <https://github.com/KantaraInitiative/wg-uma/issues/294>: Consider a proof-of-possession option for the RPT core security (see Core Sec 6.2 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html#rfc.section.…> ) - #295 <https://github.com/KantaraInitiative/wg-uma/issues/295>: When a requesting party needs to withdraw their access core (see Core Sec 3.11 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html#token-revoca…> ) - #302 <https://github.com/KantaraInitiative/wg-uma/issues/302>: Typo in RReg source regarding the stylesheet editorial rsrc-reg (trivial; RReg didn't change substantively) - Your turn to yell (*before* the call) if you're not happy with this - *#290 <https://github.com/KantaraInitiative/wg-uma/issues/290>* (Generality of RReg spec?) and *#296 <https://github.com/KantaraInitiative/wg-uma/issues/296>* (Out-of-the-box profiling for tight AS-RS coupling): Should have a concrete proposal for discussion - *#298 <https://github.com/KantaraInitiative/wg-uma/issues/298>* (Reconsider whether ticket should be on all redirect-back AS responses): a "flattened" claim token in native form-urlencoded format was implemented in Core Sec 3.6.3 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html#redirect-back> -- didn't close this issue yet because only a relatively small subset of us discussed the recommendation, so let's review - *#303 <https://github.com/KantaraInitiative/wg-uma/issues/303>* (Cleaning up the security considerations: JSON Usage): Possibly pass a quick eye over this one - *New:* *#304 <https://github.com/KantaraInitiative/wg-uma/issues/304>* (Do we need the UMA error invalid_request?): Let's consider this - *#297 <https://github.com/KantaraInitiative/wg-uma/issues/297>* (Add the authorization process flowchart or some other visual explanation): To be closed without action unless someone speaks up - Logistics/timing - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

New editor's drafts: Core rev 21 and RReg rev 08
by Eve Maler 17 Apr '17

17 Apr '17

https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-08.html http://www.websequencediagrams.com/files/render?link=Pu0sP0Oe2kjKc2WgdKZd In these drafts you will find the following issue implementations (mostly closed): #293 <https://github.com/KantaraInitiative/wg-uma/issues/293>: Check/fix all examples for missing required (and optional) fields; other editorial (the not-quite-editorial change to "flatten" the pushing of claim tokens so that a client pushes one claim token at a time; see Core Sec 3.6.1 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html#uma-grant-ty…> ) #294 <https://github.com/KantaraInitiative/wg-uma/issues/294>: Consider a proof-of-possession option for the RPT core security (see Core Sec 6.2 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html#rfc.section.…> ) #295 <https://github.com/KantaraInitiative/wg-uma/issues/295>: When a requesting party needs to withdraw their access core (see Core Sec 3.11 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html#token-revoca…> ) #298 <https://github.com/KantaraInitiative/wg-uma/issues/298>: Reconsider whether ticket should be on all redirect-back AS responses core (see Core Sec 3.6.3 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html#redirect-back>) -- didn't close this issue yet because only a relatively small subset of us discussed the recommendation #302 <https://github.com/KantaraInitiative/wg-uma/issues/302>: Typo in RReg source regarding the stylesheet editorial rsrc-reg (trivial; RReg didn't change substantively) Please do check over the new text and examples, and the swimlane summary, and see what you think. Also please note that there are still a couple of issues that could use your opinion! *Existing:* #303 <https://github.com/KantaraInitiative/wg-uma/issues/303>: Cleaning up the security considerations: JSON Usage and OIDC for client authentication *New:* #304 <https://github.com/KantaraInitiative/wg-uma/issues/304>: Do we need the UMA error invalid_request? I'm going to turn my full attention to the spec refactoring proposal now... *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Issue #295: Token revocation not that simple?
by Eve Maler 17 Apr '17

17 Apr '17

https://github.com/KantaraInitiative/wg-uma/issues/295 This was our token revocation discussion. It seemed so simple on our call on Thursday: Just define a new token type hint keyword, say "pct". But reading RFC 7009, I'm not sure that's quite the end of it. Token revocation requires <https://tools.ietf.org/html/rfc7009#section-2> authenticating the identity of the resource owner at the authorization endpoint a la OAuth Sec 3.1 <https://tools.ietf.org/html/rfc6749#section-3.1>. Of course, by analogy, that would be using the claims interaction endpoint for us, but we allow a lot more flexibility in our authorization process, e.g. pushing claims etc. And this isn't just because it's an asynchronous grant. So I think we need to do a bit more "surgery". I can't think of any reason why the client shouldn't be able to go ahead and ask to revoke any RPT it has, even if the RqP isn't around. Is that legit? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 2

Issue #293: Not-that-editorial: example of pushed claims needs to be form-urlencoded
by Eve Maler 17 Apr '17

17 Apr '17

https://github.com/KantaraInitiative/wg-uma/issues/293 Hi folks-- Please take a look at the latest comment in this issue, which highlights what started as an editorial issue but discovered a (potentially minor) decision point around how the client pushes claims to the AS's token endpoint. Because we've gone from UMA1's custom RPT endpoint which takes JSON payloads to UMA2's regular OAuth token endpoint which takes form-urlencoded payloads, our carried-over spec text talking about a JSON-formatted claim_tokens structure -- combined with an old example -- needed an update. *The proposal:* An update that changes the actual structure of claim pushing slightly, so that: - It's a truly native and streamlined form-urlencoded format. - The client pushes a single claim token (say, one ID token) and can't push a bunch of them. The theory is that we'd normally think it odd to send a set of ID tokens or SAML assertions or whatever anyway, so the old design that had an array was probably overdesigned. I'm going to try this out in the latest editor's draft unless somebody tells me they were already using the multiples feature... *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Full discussion on issue #298: Reconsider whether ticket should be on all redirect-back AS responses
by Eve Maler 15 Apr '17

15 Apr '17

https://github.com/KantaraInitiative/wg-uma/issues/298 Since a subset of the WG (Just, Robert, and me) kept going for about 30 minutes after Thursday's call ended, I said I'd pull out this part of the notes to highlight it for everyone and ensure you have a real chance to think about it. This was a really fascinating discussion. Our conclusion was that the redirect-back from the claims interaction endpoint, rather than try to duplicate the token (was RPT) endpoint status messages as it had kind of been doing, should sync up *directly* with what OAuth does instead. The basic thing it needs to achieve (as far as the client actually cares) is "yes, continue, everything went fine" or "something went wrong". If you *don't* agree, shout now! (I'm going to try and implement this in the next editors' draft so you can see what you think...) ==== *#298* <https://github.com/KantaraInitiative/wg-uma/issues/298>* (Reconsider whether ticket should be on all redirect-back AS responses):* We have errors that are identical on redirect-back (RqP/claims interaction endpoint) and the token request (client/token endpoint). On which errors should the AS produce a (rotated) ticket, and on which ones should the authorization process end? *(The formal meeting ended and we kept going ad hoc.)* *Redirect-back:* Thinking of how the client is going to respond ("What's my motivation?"), can we consolidate claims_submitted and request_submitted? We don't have enough experience to know if the difference is truly significant. In a way, all these options boil down to "continue" (or "don't continue")! Do we need authorization_state at all? Flipping the logic entirely, we could just pass an error if the client should just stop. Since our claims interaction endpoint is the moral equivalent of the authorization endpoint, only for RqPs, it's way better for our OAuth alignment goal to sync with the authorization endpoint's error response <https://tools.ietf.org/html/rfc6749#section-4.1.2.1>. Our proposal: Require the AS to use an error response according to Sec 4.1.2.1 as defined in OAuth (by reference). *Token request:* Obviously, if the client gets a token successfully, it got a token and that ends the process. A "need info" means it needs to (has the opportunity to) continue the process in the next call to the token endpoint. Thus, same-process context is needed. A broken request message means the process ends. If the request is submitted and the client has nothing to do but it's all about the AS and RO doing something, the discussion in the issue is about how a ticket needs to be issued in order to correlate a (possibly much) later "polling" attempt by the client. Of course, the client could ignore and start a new authorization process. Eve's argument about reusing invalid_grant for the "non-structural" error of not_authorized, which doesn't hand out a ticket, stopping the authorization process, is that reusing an existing OAuth error for something it doesn't truly mean is weird. Justin feels that since clients don't care and wouldn't change their behavior either way, why not reuse invalid_grant? Robert and Cigdem say that the only reason to have both is to provide extra information why it was a no. Robert: "If the information is not going to be used, it's not data. It's wasted." Of course, error_description could be used. - invalid_grant: no; state that a definitive failure, vs. a deliberate continuance of the process, uses this error (a change) - invalid_scope: no - request_submitted: yes (a change) - need_info: - not_authorized: remove (a change) *AI:* Eve: Send separate note to the WG proposing this and asking for feedback. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

UMA Legal: Will we have critical mass if we meet on Friday at 8am PT?
by Eve Maler 14 Apr '17

14 Apr '17

Hi all-- Tim has a draft of deliverable #2 for us to look at; we met today about it. But I know it's Good Friday, and many people may be taking off. Who is available to meet? Please let me know and I'll make a decision by tomorrow (Thursday) noon my time. Thanks. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 2