UMA telecon 2019-08-08

Date and Time

Thursdays 6am PT
- Screenshare and dial-in: https://global.gotomeeting.com/join/857787301
- See UMA calendar for additional details: http://kantara.atlassian.net/wiki/display/uma/Calendar

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

- Approve minutes of UMA telecon 2019-06-20, 2019-08-01

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.

The right spec link

Please keep linking to UMA Grant Recommendation. This will help search results point to the right file.

Attendees

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

Domenico
Peter
Thomas
Eve
Mike
Cigdem

Non-voting participants:

Adrian
George
Colin

Regrets:

Nancy

Browser not supported