UMA telecon 2014-09-25

Owned by Eve Maler
Last updated: Sep 25, 2014

UMA telecon 2014-09-25

Date and Time

Agenda

  • Roll call
  • Upcoming schedule
    • All-hands meetings through 2014 to get solid consensus on issue resolutions
    • Interop planning meeting next Monday
    • No telecon Oct 30 due to IIW (and open implementors' meeting Oct 29)
    • Upcoming opportunities to get together with other UMAnitarians F2F
  • News from MIT RESTful healthcare workshop last week
  • RSA conference submission status
  • Resolution on proposals for issues 88 and 99
  • Choose next issues to focus on: which may be backwards-incompatible? do those first!
  • AOB

Minutes

Roll call

Quorum was not reached.

Upcoming schedule

  • All-hands meetings through 2014 to get solid consensus on issue resolutions
  • Interop planning meeting next Monday
  • No telecon Oct 30 due to IIW (and open implementors' meeting Oct 29)
  • Upcoming opportunities to get together with other UMAnitarians F2F

All duly noted.

News from MIT RESTful healthcare workshop last week

Eve shared news from this workshop hosted by MIT. Debbie Bucci and Eve are offering to co-chair this new profiling group at OpenID Foundation. More to come. The proposed name of the group is HEAlth Relationship Trust, or HEART.

RSA conference submission status

Joni is helping Sal put in a submission for an UMA IoT authorization session that will have a Raspberry Pi demo.

Eve's company is helping her and Maciej put in a talk on "Kill the Password? Kill Impersonation! The UMA Delegation Advantage".

Maybe we want to have another UMArtinis or UMArgaritas cocktail hour (and training workshop at the same time?) during RSA. (smile) Let's talk to Joni about a Kantara-hosted event that week.

Resolution on proposals for issues 88 and 99

We discussed Eve's proposal. She has proposed one particular choice for AS behavior, but there are other choices:

  • Eve's proposal: AS always hands back the RPT provided, and always issues new RPT if one wasn't provided.
  • Alternatives:
    • The AS always hands out a new RPT when given an RPT in the request.
    • The AS has a choice about handing back the same RPT or a new RPT when given an RPT in the request.

George notes that in OAuth-land, if consent is given after retrying a scope not initially given, then that state is kept on the back end and re-associated with a token later on a retry. This is "RPT-like" in that the AS is keeping entitlement state, so to speak, on the back end. This helps the user experience, and seems to argue for enriching the RPT if possible. If we pick one way now, Eve's theory is that we should pick a way that's friendly to users; in the future, when we get more best-practice experience, perhaps we can broaden the options. George notes that UMA manages the challenge with a permission ticket as the "error" that lets the user (the RqP operating the client) retry the request. In fact, whether the AS has a new or old RPT is just a matter of a persistent or refreshed correlation handle for its back-end state, so the rationale for choosing the RPT "refreshment" is not about UX but about an implementation choice. Is there, in fact, a reason to choose one implementation flavor vs. another? The client has to deal with what they're handed back either way, so maybe we stay out of the decision.

We discussed how the RS also has a choice in registering permissions. For example, it could choose to register a "parsimonious" scope when there's no RPT in the request and a "generous" scope when there's an RPT in the request. This too is an implementation choice.

Are there auditability implications of handing out a new RPT? This is totally an implementation choice.

We got consensus on the proposal, with the change that the AS has the choice to change the RPT string that was in the request or keep it. We still need to discuss whether the previous RPT (if a new one is issued) is invalidated or not. Is this also an implementation choice? When you get into multiple servers and multiple users, it's easiest to just invalidate the existing token! Statelessness may be your friend in all those circumstances. And the audience (of an OIDC token) might be specific to one client. Maciej would like to be sure to discuss this further in light of the existing spec text.

AI: Eve: Send revised eager permission registration proposal to the list.

AI: Eve: Send updated prioritized list of V0.9 issues to the list.

Eve brought up the idea to change terminology in order to diminish the impact of the "three tokens": should the RPT be "access token", and should we make the AAT pronounceable?

Choose next issues to focus on: which may be backwards-incompatible? do those first!

AOB

Attendees

  1. Eve
  2. Jin
  3. Keith
  4. Maciej
  5. Yuriy
  6. Mike

Non-voting participants:

  • Ann
  • Marcelo
  • George
  • Adrian
  • Zhanna

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.

  • APAC-friendly Wed Oct 1 4-5pm PT/ Thu Oct 2 8-9am JPN / Thu Oct 2 9-10am AUS
  • Thu Oct 9 9-10am PT
  • Thu Oct 16 9-10am PT
  • Thu Oct 23 9-10am PT
  • No meeting Thu Oct 30 because of IIW – we are holding an open UMA implementors' meeting on Oct 29 at IIW instead
  • APAC-friendly Wed Nov 5 4-5pm PT/ Thu Nov 6 8-9am JPN / Thu Nov 6 9-10am AUS
  • Thu Nov 13 9-10am PT
  • Thu Nov 20 9-10am PT
  • No meeting Thu Nov 27 because of Thanksgiving holiday in the US
  • APAC-friendly Wed Dec 3 4-5pm PT/ Thu Dec 4 8-9am JPN / Thu Dec 4 9-10am AUS
  • Thu Dec 11 9-10am PT
  • Thu Dec 18 9-10am PT
  • No meeting Thu Dec 25 because of Christmas holiday
  • No meeting Thu Jan 1 because of New Year's Day holiday