UMA telecon 2015-01-05
Date and Time (UMA calendar)
- Mon Jan 5: special quorate meeting 9:30-11am PT
- Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines), room code 178-2540#
- Screen sharing: http://join.me/findthomas
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.
Attendees
As of 4 Dec 2014, quorum is 6 of 11. (Dom, Sal, Mark, Thomas, Andrew, Robert, Maciej, Eve, Mike, Jin, Yuriy)
- Eve
- Domenico
- Andi
- Thomas
- Robert
- Maciej
- Mike
Non-voting participants:
- George
- Adrian
- Oscar
- Zhanna
Next Meetings
- Thursday, Jan 8: regular 1hr telecon (no ad hoc pre-meeting)?