UMA telecon 2019-08-08

Owned by Eve Maler
Last updated: Aug 08, 2019

UMA telecon 2019-08-08

Date and Time

Agenda

  • Roll call
  • Approve minutes of UMA telecon 2019-06-20, 2019-08-01
  • Decision on UMA2 IETF I-Ds
  • UMA2/XYZ use case work
  • Nominations for chair and vice-chair
  • FAQ revision
  • The right spec link
  • AOB

Minutes

Roll call

Quorum was reached.

Approve minutes

MOTION: Approve minutes of UMA telecon 2019-06-20, 2019-08-01. APPROVED by acclamation.

Decision on UMA2 IETF I-Ds

  • The UMAGrant spec and FedAuthz I-Ds expire on August 17 if we don't take action
  • We can:
    1. Let the specs expire and do nothing else beyond telling the OAuth WG chairs that we rescind our previous proposal (already done), or:
    2. Decide to do an independent submission and go for an informational RFC instead, presumably in the Security Area
  • We were leaning towards #2, but we're still open at the moment. Please review the notes of UMA telecon 2019-06-20 to prepare to discuss this (it also links to older notes...)

There's a third option Eve forgot to list: Do what we did before, and submit I-Ds that are "empty shells" of the specs that point to the real specs and just keep refreshing them. (Here were UMA Core and RSR.) What we did with UMA1 was not keep refreshing them, because we started work on UMA2.

We discussed the pros and cons listed in UMA telecon 2015-10-15. If we're up front about wanting the spec to serve as an "archive", then they would presumably want to avoid breaking changes. Thomas related some past experience around cryptographic cipher standardization in the informational RFC process.

Option 3 pros:

  • We are in control of the entire process.
  • The IETF drafts themselves contain little that goes out of date.

Cons:

  • We have to keep taking action every six months.
  • The drafts don't themselves contain any technical substance of value.
  • The "marketing" value is perhaps minimal since there's no IETF "blessing" involved by anyone else.

What is the process of independent submission? Here is information. RFC 4846 covers the process. This explains why we want this to be informational.

UMA2/XYZ use case work

  • See last week's notes for a description of what's requested.
  • Use GitHub? The wiki? GDocs?

Point of order: The XYZ work is not UMA! Current profiles and extensions that apply to UMA2 are very welcome to be submitted to the UMA WG for standardization. We know of several of them.

Let's use GitHub and markdown for our XYZ use cases. Adrian has an idea for a use case but isn't sure about how to apply the template; we can discuss his use case on the list. These use cases could include things UMA2 solves now (e.g., all the things mentioned in the introductions to the two specs), and also things UMA2 doesn't solve now.

Nominations for chair and vice-chair

  • You can see the leadership team list here.

Reminder about this. Nominations are still open.

FAQ revision

  • Our FAQ is extremely old and out of date

Do we even need this document? Or should we revise it? Take a look and weigh in.

Attendees

As of 16 Jul 2019, quorum is 5 of 9. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike, Cigdem)

  1. Domenico
  2. Peter
  3. Thomas
  4. Eve
  5. Mike
  6. Cigdem

Non-voting participants:

  • Adrian
  • George
  • Colin

Regrets:

  • Nancy