UMA telecon 2015-01-08

Date and Time

Thu Jan 8 9-10am PT
- Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines), room code 178-2540#
- Screen sharing: http://join.me/findthomas
- UMA calendar listing all future meetings: http://kantara.atlassian.net/wiki/display/uma/Calendar

Agenda

Roll call
Minutes approval
- Sample motion: Approve the minutes of UMA telecon 2015-01-05.
IETF submission of eventual Kantara Recommendations?
Interop progress
V1.0 rollout
UMA Implementer's Guide
Field public review comments
Security and privacy considerations
AOB

Minutes

Roll call

Quorum was reached.

Minutes approval

MOTION: Approve the minutes of UMA telecon 2015-01-05. APPROVED by unanimous consent.

IETF submission of eventual Kantara Recommendations?

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.

Interop progress

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.

V1.0 rollout

What sorts of activities would be potentially valuable?

Hold a webinar: sponsorship opportunities (and companies can also do their own)
Press release from Kantara with quotes from some companies, e.g. Gluu, ForgeRock, UnboundID, Cloud Identity, Patient Privacy Rights...
Interop events – or instead, offer to do a live multi-implementation demo at a Kantara event at RSA or something?
Video: introduction to UMA
IDESG plenary: NSTIC standards adoption policy activity with UMA presentations
IIW (early April)
HIMSS (mid-April)
EIC (early May)
IRM Summit (May)

The overall themes should be:

It's real and stable
It's adopted by multiple products
It's valuable in solving real-world problems (selective trust elevation, privacy, distributed access control, user empowerment...)
It's complementary to the rest of the modern identity ecosystem (the "Venn", OIDC)

UIG

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.

Public review timeframe comments

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.

Attendees

As of 6 Jan 2015, quorum is 7 of 12. (Dom, Sal, Mark, Thomas, Andrew, Robert, Maciej, Eve, Mike, Jin, Yuriy, Ishan)

Eve
Sal
Thomas
Domenico
Andi
Ishan (new – welcome! UnboundID product manager)
Mike
Jin
Maciej

Non-voting participants:

George
Adrian
Ann
Zhanna

Invited guest:

Hannes

Browser not supported