Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Current »

UMA telecon 2015-01-05

Date and Time (UMA calendar)

Agenda

  • Roll call
  • Minutes approval if quorum
    • Sample motion: Approve the minutes of UMA telecon 2014-12-18 and read into today's minutes the notes of ad hoc WG meetings held since 2014-12-11.
  • Consider approving the V1.0 candidate specification drafts for 45-day public review pursuant to Section 5 of the KI operating procedures
    • Core rev 11f (possibly with amendments)
    • RSR rev 04c (possibly with amendments)
  • Consider contributing the specification drafts as IETF I-Ds
  • Interop testing status and meeting schedule review
    • Change back to Thursday one-hour schedule?
    • Add back APAC-friendly meeting times?
    • What pace for interop discussions?
    • Meet Thursday January 8?
    • Status of interop feature tests and test suite?
  • Next opportunities for F2F?
  • AOB

Minutes

Roll call

Quorum was reached.

Minutes approval if quorum

MOTION: Approve the minutes of UMA telecon 2014-12-18 and read into today's minutes the notes of ad hoc WG meetings held since 2014-12-11. APPROVED by unanimous consent.

Issues to work on today

Not 10

*Not 120 - just implement

*Not 121 - just accept true/false

*122 - implement and yank the SAML mentions

*123 - URI does mean URNs as well as URLs - can we consider this editorial to a first approximation, and then use the review period to reflect on the further consequences? George wants to ensure that URNs can be used for things like grant types

*124 - we discussed it - 

There’s some sentiment to remove the list Roland doesn’t like, because the “true audience” for the spec doesn’t find it all that helpful.

Can we just be more explicit about the stuff the entities have to do vs. the stuff they don’t have to do? PATs, AATs, etc., the stuff that’s currently in the Sec 5 intro: repeat it?

Would it be interesting to mention the other rationale for having these profiles, namely, not tight coupling but binding to alternate transports? Perhaps only if we don’t spend a lot of pixels on it?

We seem to have consensus on the newly proposed text with the list missing, but with the required behavior and the additional rationale emphasized.

Domenico’s new question about the recommendation to use OIDC in the case of the protection API: Does it make sense? Since client authentication only comes into play when first acquiring the tokens, it still applies; it still enables proving that the UMA-RS-as-OAuth-client is who it says it is (at the point of PAT issuance). It’s true that the ID token doesn’t get leveraged at the protection API, however. No change.

MOTION: Thomas moves and Mike seconds: Publish Core rev 11f as amended with our instructions on issues 120 through 124 and RSR rev 04c as Core rev 11 and RSR rev 04 for a 45-day Kantara Public Review and contribute as IETF I-Ds. APPROVED by unanimous consent. YAY!

 

Attendees

As of 4 Dec 2014, quorum is 6 of 11. (Dom, Sal, Mark, Thomas, Andrew, Robert, Maciej, Eve, Mike, Jin, Yuriy)

  1. Eve
  2. Domenico
  3. Andi
  4. Thomas
  5. Robert
  6. Maciej
  7. Mike

Non-voting participants:

  • George
  • Adrian
  • Oscar
  • Zhanna

Next Meetings

  • Thursday, Jan 8: regular 1hr telecon (no ad hoc pre-meeting)?

 

 

  • No labels