UMA telecon 2014-10-16

Owned by Eve Maler
Last updated: Oct 16, 2014
4 min read

UMA telecon 2014-10-16

Date and Time

Agenda

  • Roll call
  • Minutes approval if quorum
    • Sample motion: Approve the minutes of the last quorate telecon and read into today's minutes all the notes from all intervening non-quorate telecons.
  • Interop testing status
  • Meeting schedule review
    • See last week's minutes for details
  • FT-impacting issues on V1.0 docket
    • 88/99: Eager permission registration
    • 92: trust elevation/"need_reauthentication"
    • 105: status parameter in resource reg
    • 94: start_at for permission validity
    • 84: UMA endpoint names vs. OAuth endpoint names
  • AOB

Minutes

Roll call

Quorum was reached.

Minutes approval if quorum

Deferred.

Interop testing status

Proceeding!

Meeting schedule review

Done.

FT-impacting issues on V1.0 docket: close in today's call if possible!

Is it in fact the case that there may be two RPTs floating around that may work, and do we care? Yes there may. Do we care? It seems not, as tokens might expire (or be revoked by the RO) at any moment.

Does it trouble us that the client might bring a "bad" RPT back to an AS over and over again, even if handed back a new one? What is the logical behavior for a client to implement? We're not sure. E.g., if a client handed in RPTa and got back RPTb, would it ever later hand in RPTa again, or would it switch to handing in RPTb in a "chain" to get RPTc etc.? We may not care. If this is purely in the realm of implementation, then it's best to be very loose with our prescriptions – it's not about interop.

So the wording choice we're considering is:

Once the authorization server issues the requested authorization data, it associates it with an RPT and responds to the client with an HTTP 200 status code and a response body containing that RPT. If the client didn't present an RPT in the request for authorization data, the authorization server creates a new RPT. If the client did present an RPT in the request, the authorization server returns the RPT with which it associated the authorization data, which may be either the RPT in the request or a new one. Note: It is entirely an implementation issue whether the returned RPT is the same one that appeared in the request or a new RPT, and it is also an implementation issue whether the AS chooses to invalidate or retain the validity of the original RPT in this case.

    • 92: trust elevation/"need_reauthentication"

This is a proposed new fourth option for the AS response types when the client asks to add authorization data to an RPT. Currently, the core spec doesn't have the need_reauthentication response option to hook response hints off of, the way we have the need_claims response option that we hook the claims-gathering profiling off of.  Mike notes that in his profile, the domain_auth_level and domain_auth_mode are old and have been changed, but he thinks that the required_acr_uri and authentication_uri properties may be globally useful enough to consider adding. Without providing the authentication URI, you'd have to assume that the UMA AS and the authentication server are the same. Otherwise you have you inform the client what your IdP (or OP) is. An acr is an authentication context descriptor ("authentication context class reference").

We have consensus to add the response option. What do we think of the name of it? Eve likes "need_(something)" for parallelism. Is "...reauthentication" okay? Unless we hear something better, perhaps it is.

AI: Eve and Thomas: Draft text.

Do we have consensus to add a property to pass along a hint about the required authentication context, and if so, what should it be called and should it be part of the core spec? Mike's rationale is to help the client not waste time collecting a type of authentication that wouldn't be sufficient. Andi has a concern that putting this in may be too constraining. What if you want to pass multiple properties in a more complex structure, e.g. LOAs and such? This could be done in a separate profile much as for the claims-gathering profile spec.

AI: Eve: Revise trust elevation profile issue to limit the scope down to just the acr_uri issue now. Make sure to mention that this could be plural (an array).

AI: Eve: Add Marcelo's "implicit OAuth scope" issue to GitHub.

Do we have consensus to add a property to pass along a hint about the authentication URI endpoint, and if so, what should it be called and should it be part of the core spec? Isn't this already covered by the fact that the AAT is a regular OAuth token, issued from the AS as an OAuth as through the endpoints advertised in the UMA config data for this purpose?


    • 105: status parameter in resource reg
    • 94: start_at for permission validity
    • 84: UMA endpoint names vs. OAuth endpoint names

Attendees

As of 2 Oct 2014, quorum is 8 of 14.

  1. Eve
  2. SteveO
  3. Domenico
  4. Andi
  5. Jin
  6. Maciej
  7. Mike
  8. Sal

Non-voting participants:

  • Zhanna
  • Adrian
  • Ryan
  • Marcelo

Next Meetings

We will hold all-hands meetings (calling the roll) through the fall and early winter as much as possible; voting participants please attend! You can subscribe to the UMA calendar (and ask the chair to send you an event invitation) to see the times in your local time zone. Keep in mind that when the clocks change, we experience "summertime skew"; our home time zone is Pacific so non-US meeting times may shift.

  • Thu Oct 23 9-10am PT
  • (Clocks change in Europe on Oct 26)
  • No meeting Thu Oct 30 because of IIW – we are holding an open UMA implementors' meeting on Oct 29 at IIW instead
  • (Clocks change in US and Canada Nov 2)
  • No meeting Nov 6 (Eve regrets)
  • Thu Nov 13 9-10am PT
  • Thu Nov 20 9-10am PT
  • No meeting Thu Nov 27 because of Thanksgiving holiday in the US
  • Thu Dec 4 9-10am PT (change from APAC-friendly time)
  • Thu Dec 11 9-10am PT
  • Thu Dec 18 9-10am PT: possible to approve V1.0 drafts for public review in January on this date?
  • No meeting Thu Dec 25 because of Christmas holiday
  • No meeting Thu Jan 1 because of New Year's Day holiday

Â