UMA telecon 2014-07-31

Owned by Eve Maler
Last updated: Jul 31, 2014
4 min read

UMA telecon 2014-07-31

Date and Time

Agenda

  • Roll call
  • Minutes approval
    • Potential motion: Approve minutes of UMA telecon 2014-06-26 and read into today's minutes all intervening ad hoc meeting notes.
  • Review 2014 timeline and next week's meeting schedule
    • Public review status and disposition of any comments to date
    • APAC-friendly time next week = late in the day on Wed for most others
  • Interop planning and discussion as required (Maciej, Mark)
  • Discuss open technical issues (each issue proposer)
    • Audit ID: issue 63
    • Others?
  • Review open AIs
  • AOB

Minutes

Roll call

  • Was quorum reached? YES.

Minutes approval

  • Potential motion: Approve minutes of UMA telecon 2014-06-26 and read into today's minutes all intervening ad hoc meeting notes.

MOTION: Approve minutes of UMA telecon 2014-06-26 and read into today's minutes all intervening ad hoc meeting notes. APPROVED by unanimous consent.

Review 2014 timeline and next week's meeting schedule

  • Public review status and disposition of any comments to date
  • APAC-friendly time next week = late in the day on Wed for most others

We'll remind Kantara subscribers and "the world" weekly as long as the public review is ongoing. No comments yet, so nothing to dispose of.

The process post-public review:

  1. We dispose of any comments, formally.
  2. We remand the draft to the LC for a vote on KI Draft Recommendation.
  3. Assuming that passes, it goes to full KI membership ballot for 15+ days.
  4. Assuming that passes, the three V0.9 specs would become KI Recommendations.
  5. Then we work on V1.0 versions, applying any changes we might have stacked up in WG discussions.

Interop planning and discussion as required (Maciej, Mark)

FT-rs-no-rpt: Mark suggests that we need an exactly parallel FT-rs-invalid-rpt test, in the same "access" section.

AI: Eve: Create a FT-rs-invalid-rpt test.

This brings up George's question about why we're forcing the client to get an empty RPT with no authorization data associated with it, and then go back to get a permission ticket separately. In his recent IoT analysis, he assumed that the client is able to turn around and provide the (new, empty) RPT and also an email address claim, but he "hand-waved" around whether it was also providing a permission ticket. His concern about doing the loop twice is that he'd have to redirect the user to the AS twice – once for the AAT, and once for the RPT. So this isn't really about RPT issuance, which can be silent, but about AAT issuance, similarly to the early days of profiling OpenID 2.0 with OAuth and trying to avoid two user redirection episodes. Mark sees this opportunity as an optimization flow, in the case when you know a lot about the RS in question. It's worth sorting through, because the AS needs to know the relevant policies and the relevant RS in order to add authorization data – but maybe it can know these things proactively. Is this just a matter of the RS "eagerly" registering a permission ticket?

If Alice sends Bob a URL to use to get to her calendar service, Bob approaches her service with no RPT. The WWW-Authenticate header will give Bob's client the AS location, and so we already know we need to introduce Bob to the AS at that location. An AAT is required to get an RPT, which currently starts empty. George observes that while he expected the RPT to be a tuple of the RqP/C/RS/AS, there's no place where we require the C to supply the host ID (identifying the RS) to bind the RPT to that RS. George was assuming that in Section 3.4.1 he should pass the host ID, but it doesn't say that. The C isn't even presenting a permission ticket – because we broke out the process of getting the token and trying to put anything in it! We think we want to actively prevent a token from having applicability to multiple RS's for a variety of security and privacy reasons.

For the usability question, does it make sense to add a response_type that indicates that an RPT is desired? Only if the RPT isn't limited to a single RS. Or, perhaps, if the RS were super-eager to register a permission ticket and did it at the first access attempt.

Yuriy adds that the client in Gluu's implementation can manage one RPT for all RS's, or one per, or whatever. They have a clear separation around the AAT being for authorization for the C to access the AS, and RPT being for authorization for the C to access the RS.

AI: Eve: Add new issue regarding the "nexus" of issues around RPT issuance, authorization data association with it, RqP redirection actions, and any ambiguity, inefficiency, and un-usability involved in the current flow.

AI: Eve and others: Respond to Mark's FT email.

AI: Mark and Maciej: Send protapi FT comments to the list(s).

AI: Eve: Add need_claims issue highlighted by the FT review.

Discuss open technical issues (each issue proposer)

  • Audit ID: issue 63
  • Others?

Looking at Zhanna's discussion document: Because of potential name clashes, it's a good idea to distinguish UMA participants from entities in the larger environment, e.g., OpenID Connect entities. She is planning to identify some key events which we should consider auditing. Data protection is also a consideration.

The two participants who would be most interested in auditing are the AS and RS, according to this analysis. The table in the discussion document identifies potential events of interest.

Eve notes that choices about revocation depend heavily on the semantics of the environment, and she wonders if that should go in the core spec or in an overlay or even in third-party profiles. And the universe of auditable events may be scoped down for each use case.

Attendees

As of 24 Jul 2014 (pre-meeting), quorum is 7 of 13.

  1. Eve
  2. Mark
  3. Keith
  4. SteveO
  5. Abhi
  6. Domenico
  7. Jin
  8. Mike

Non-voting participants:

  • Casey
  • Katie
  • Zhanna
  • Adrian
  • George
  • Ann
  • Yuriy Z

Regrets:

  • Ryan
  • Maciej
  • Sal

Next Meetings

  • Focus meeting Wed Aug 6 4-5pm PT/ Thu Aug 7 8-9am JPN / Thu Aug 7 9-10am AUS (time chart)
  • Focus meeting Thu Aug 14 9-10am PT (time chart)
  • Focus meeting Thu Aug 21 9-10am PT (time chart)
  • All-hands meeting Thu Aug 28 9-10am PT (time chart)