UMA telecon 2017-04-20

Owned by Eve Maler
Last updated: Apr 21, 2017

UMA telecon 2017-04-20

Date and Time

Agenda

  • Roll call

  • Approve minutes of UMA telecon 2017-03-09 

  • UMA V2.0 work:
    • All GitHub issues for V2.0/ dynamic swimlane
    • Core is up to 21 and RReg is up to 08 (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: 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)
        • #294: Consider a proof-of-possession option for the RPT core security (see Core Sec 6.2)
        • #295: When a requesting party needs to withdraw their access core (see Core Sec 3.11)
        • #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 (Generality of RReg spec?) and #296 (Out-of-the-box profiling for tight AS-RS coupling): candidate "grant" spec for discussion: oauth-uma-ticket rev 00
    • #298 (Reconsider whether ticket should be on all redirect-back AS responses): see Core Sec 3.6.3 -- didn't close this issue yet because only a relatively small subset of us discussed the recommendation, so let's review
    • #303 (Cleaning up the security considerations: JSON Usage): Possibly pass a quick eye over this one
    • New: #304 (Do we need the UMA error invalid_request?): Let's consider this
    • #297 (Add the authorization process flowchart or some other visual explanation): To be closed without action unless someone speaks up
  • Logistics/timing
  • AOB

Minutes

Roll call

Quorum was reached.

Approve minutes

Approve minutes of UMA telecon 2017-03-09: Deferred.

UMA V2.0 work

#293: Consensus on pushing only a single claim token being "hunky dory" (a good idea).

#298: The redirect-back paths look much cleaner now.

#290 (Generality of RReg spec?) and #296 (Out-of-the-box profiling for tight AS-RS coupling): We looked at the new oauth-uma-ticket rev 00 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.) 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