UMA telecon 2014-02-13

Owned by Eve Maler
Last updated: Feb 13, 2014
3 min read

UMA telecon 2014-02-13

Date and Time

Agenda

  • RSAC (Feb 27) telecon: hold? cancel?
    • RSAC drinks one evening: who's around?
  • Action item and other upcoming event/activity review
  • Webinar planning
    • Mar 20, 8-9am PT (time chart) – this is in the "summertime skew" period
  • Core draft 09d/e review
    • Implementor's target?
    • Do a WG ballot (and an all-member ballot after)?
    • Any other issues worth discussing on GitHub?
  • Other interop planning news
  • AOB

Minutes

RSAC plans

Let's hold our regular Feb 27 meeting. Very few UMAnitarians are attending RSAC. Maybe Eve and Roland will simply get together for drinks on the Wednesday evening if one one else is around. (smile)

Action items

Wikipedia: Eve provided draft edits of the Wikipedia entry to Rainer, and he edited the real English version. Sal has requested Nat's help to create a Japanese version. Mark offered to translate to a Dutch version.

Webinar planning

It's currently on the calendar for March 20 at 8-9am PT. Adrian is interested to help with webinar planning.

AI: Eve: Schedule ad hoc meeting to plan webinar with Joni, Adrian, Gluu, and interested others.

Spec review

Core: The changes to Sec 3.4.1 seem okay. The changes to Sec 3.4.2 are breaking, in that they require the AS to return the RPT in the body in the case of success. Should we remove the body of the success response? This gets into the whole huge question of RPT validity periods/TTL, which we're thinking more and more that we should avoid. A key question asked in issue #88 was: "Did we mean to suggest that an old RPT and all of its authorization data needs to be revoked when the client makes this request?" Maciej describes how different AS developers might choose either to keep the RPT the same when authorization data is added to it, or to increment/change the actual RPT (its identifier). Thomas describes how this is a classic Kerberos problem, in that the Kerberos server would want to see any update of an RPT have a different handle so that it doesn't confuse the RS.

The MTI "bearer" RPT profile requires the RS to introspect the token regardless, so maybe this matters less in this case. But Thomas points out that an RS in a commercial setting is going to want to log everything carefully, including the exact RPTs they've been handed. If the RPT handle changes every time to reflect new "authorization data states", then: 1) the RS has no point caching anything about RPTs and 2) an RPT could more easily be bound to obligations among the parties and be used in multi-party auditing etc. without "latency skew" issues (e.g., authz data getting added only after some access is denied etc.).

Let's remove the JSON "rpt" body from the success response in Sec 3.4.2 for now, but keep the 201 Created.

In Sec 3.5, we've removed some MUSTs around how claim profiles need to handle redirects and how the ticket state is passed. Is this okay? Sounds like it.

Claim profiles spec: Should we publish it? Yes, let's clean it up slightly and publish and send to IETF just to get it into the record.

AI: Domenico: Find a suitable full-fledged OpenID Connect ID token example to put in the first profile.

AI: Thomas and Eve: Fix the claim profiles spec references and remove the RPT body in core 3.4.2, and publish to IETF as rev 09. Change the trscavo reference and fix obvious blanks in the claim profiles spec and publish to IETF.

AI: Eve: Add GitHub issue re claims conveyance endpoint and its potentially general applicability to multiple profiles.

Attendees

  • Eve
  • Mark
  • SteveO
  • Adrian
  • Domenico
  • Thomas
  • Maciej
  • Jin
  • Sal

Regrets:

  • Roland

Next Meetings

  • Focus meeting Thu Feb 13 8:30-10am PT (time chart)
  • Focus meeting Thu Feb 20 8:30-10am PT (time chart)
  • All-hands meeting Thu Feb 27 8:30-10am PT (time chart) - Mark, Adrian regrets