UMA telecon 2015-01-08

Owned by Eve Maler
Last updated: Jan 08, 2015
3 min read

UMA telecon 2015-01-08

Date and Time

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. (smile)

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)

  1. Eve
  2. Sal
  3. Thomas
  4. Domenico
  5. Andi
  6. Ishan (new – welcome! UnboundID product manager)
  7. Mike
  8. Jin
  9. Maciej

Non-voting participants:

  • George
  • Adrian
  • Ann
  • Zhanna

Invited guest:

  • Hannes