UMA telecon 2014-09-03

Owned by Eve Maler
Last updated: Sep 03, 2014

UMA telecon 2014-09-03

Date and Time

Agenda

  • Interop planning
  • Open issues: see latest email discussions
    • Issues 88 and 99: decide disposition today if possible
  • AOB

Minutes

Issues 88 and 99

Let's discuss these issues today, but "sleep on" any rough consensus, to give the Europe-friendly crew a chance to weigh in next week as well.

Eager vs. lazy permission ticket issuance:

  • keep long flow, switch to short flow, let RS choose which flow to use, other?

Long flow:

  1. C attempts access at RS with no RPT
  2. RS fails with as_uri
  3. C gets RPT at AS
  4. C attempts access at RS with RPT
  5. RS gets permission ticket at AS
  6. RS fails with as_uri and permission ticket
  7. C brings ticket to AS to seek authorization data...

Short flow:

  1. C attempts access at RS with no RPT
  2. RS gets permission ticket at AS (skips to the equivalent of #5 above, skipping #2, #3, and #4)
  3. RS fails with as_uri and permission ticket (the equivalent of #6 above)
  4. C brings ticket to AS to seek RPT and authorization data... (not the equivalent of #7 above – needs a combined endpoint)

Gil asks: What is the point of the extra steps? Eve observes that the semantic of the plain RS 401 is something like "This resource is UMA-protected; here's a little help (but not 100% help) to get you possibly qualified to access it." In the past, we've sometimes had a combined RPT issuance and authorization request endpoint, but then separated them again, which seems to have necessitated those extra three steps! Here's a somewhat refreshed version of the analysis of the first two options:

Option 1: keep current "long flow"
Pros: doesn't ask RS and AS to perform work until C has done some work; backwards compatible (= identical) with V0.9 behavior
Cons: more multi-party HTTP interactions just to get access the first time
Notes: The con is perhaps mitigated by RPT issuance being done less often than other flows

Option 2: switch to "short flow" and combine two endpoints
Pros: shortens the number of HTTP interactions that lead to access; gives opportunity to simplify the protection API
Cons: backwards incompatible with V0.9 behavior and requires invasive changes to the API; C can abandon request after RS and AS performed work
Notes: The RS will want to rate-limit bad-actor Cs if a C seems to be abusing the ticket-getting privilege 

Do we have a principle of pushing work out to the edges? E.g., OpenID Connect doesn't have server-side logout because Google didn't want to handle that sort of tracking. Then again, the RS is going to have to do that work anyway, assuming the C is legitimate.

We're not even sure Option 3 (let the RS freely choose which flow to use) is even an option anymore, and we can't decide what to do until we have a proposal on the table about a combined endpoint. So what would it look like? Maybe this? (config data-type definition)

authorization_request_endpoint: The endpoint URI at which the client asks to have authorization data granted to it, and to have an RPT issued as necessary for associating the authorization data with it. Usage of this endpoint is defined in Section 3.4.x. A valid AAT MUST accompany requests to this protected endpoint.

Note that the authorization data endpoint already involves optionally issuing a (refreshed) RPT anyway: "If the authorization server chooses to invalidate the original RPT in response to the [authorization data] request and to issue a new one to be associated with the resulting authorization data, it MUST provide that refreshed RPT in the body." So we were already overloading the second of the two endpoints anyway.

Pros: lets the RS assess context, trust relationships, etc. (could do it once but refuse a second time on seeing the same C) and still requires simple deterministic behavior from the C: if no ticket, get RPT and retry; backwards compatible with V0.9 behavior
Cons: introduces optionality into the spec

Rough consensus: We think Option 1 is starting to "leave the table" and be less viable: it has little inherent rationale, vs. Option 2's efficiency rationale, and the current state of affairs doesn't fully avoid endpoint-overloading anyway. However, we can't force a full conclusion until we come up with a proposal for a replacement singular authorization data endpoint that accounts for the other outstanding 88/99 issues as well.

Single-RS vs. multi-RS RPT:

  • spec is clear on single-RS but not on ticket-based lazy RS binding mechanism
  • keep current text, add text explaining mechanism, add option for host ID-based eager RS binding mechanism, switch to eager mechanism only, other?

Is there any reason at all to even consider a multi-RS RPT? We think it violates general principles of audience restrictions. Then again, Gil posits a collection of RS's that have a tight trust relationship or are somehow "composite". We can imagine an "abstract service" that technically crosses RS boundaries, and also can imagine both eager ("RS audience ID") and lazy (coordinated ticket generation practices) methods of multi-RS association. However, remember that the AS has to be kept away from any such complexity because it may be run by a different company than the RS's! So we agreed it's best not to get into this hypothetical.

Maciej's implementation does the lazy binding by default, but also implements an extension that does the eager binding. Marcelo's implementation doesn't shed too much light on this question. 

Some very rough feedback is to add text explaining the lazy binding mechanism to the text. We will continue discussing. Mike suggests simplifying where possible.

RPT expires_at:

  • keep, remove, make optional with default, other?
  • clarify semantics of RPT identifier and associated permissions when RPT gets "refreshed"?

Attendees

  • Eve
  • Zhanna
  • Marcelo
  • Mike
  • Gil

Next Meetings

  • Focus meeting Thu Sep 11 9-10am PT (time chart)
  • No meeting Thu Sep 18 9-10am PT (time chart) - Eve, Mike regrets
  • All-hands meeting Thu Sep 25 9-10am PT (time chart) 

Â