Quorum was reached.
MOTION: Approve the minutes of UMA telecon 2015-01-05. APPROVED by unanimous consent.
Eve can seek advice from experts on this. We've been submitting drafts as IETF I-Ds, and have contemplated submitting "independent submissions". Would we need a whole UMA working group? No; if we wanted IETF to take up the work actively, then one option is for the OAuth group to take up new work items if they're so inclined. However, if we consider our work to be complete, would we even want that? Does Nat have input? What is the latest status of Kantara's governance model?
AI: Eve: Seek advice on IETF submission options and pros/cons.
The feature tests have to be updated for V1.0, and the plan is for Roland to significantly redesign the FTs. This needs to be done ASAP.
Mike asks: Should we conceive of this as interop, or certification of conformance in the OpenID Connect sense? If everyone "tests against Roland", isn't that in practical terms what we're doing? Stating it as true conformance may be too strong, but at the very least we do need to vet Roland's interpretation of the spec, so that whatever his interpretation is, it can't stray too far. Also, Eve doubts that "testing against Roland" is, in UMA's case, going to be sufficient for some loosely coupled ecosystems, if only because there are three distinct entities, not just two, and there are more pairwise interaction that are distinct.
Eve has to get on the stick and do her funding proposal action! Sal has graciously offered some in-kind resources.
We really want to use this public review period to do some testing.
What sorts of activities would be potentially valuable?
The overall themes should be:
AI: Mike: Write the section on "Organizations as Resource Owners and Requesting Parties".
AI: Maciej: Write as many sections for the UIG as he can.
AI: Andi: Write the section on "Handling Ignored Parameters" and share with Zhanna for comment.
Zhanna has asked: In https://docs.kantarainitiative.org/uma/draft-uma-core.html#rfc.section.3.3.2, 1. should https://docs.kantarainitiative.org/uma/profiles/uma-token-bearer-1.0 be a resolvable url (because it is not) or is it just a string? 2. does the “author” name and email address belong to the body of the spec? Is it still valid to have just one author? In general, would this bullet list be better placed in Appendix
We used the SAML style of profile, which is not used in OIDC, so we think this is okay. If people have questions, please ask on the list.
For the implementor’s guide discussion, can we consider the topic of generating AAT. Per https://docs.kantarainitiative.org/uma/draft-uma-core.html#rfc.section.1.3.2 "An AAT binds a requesting party, a client being used by that party, and an authorization server “. I suggest to give recommendations how the "a client being used by that party” can be identified.
We'll follow up on this in email.
As of 6 Jan 2015, quorum is 7 of 12. (Dom, Sal, Mark, Thomas, Andrew, Robert, Maciej, Eve, Mike, Jin, Yuriy, Ishan)
Non-voting participants:
Invited guest: