Quorum was reached.
Our I-Ds have expired. Even though we (meaning Eve) didn't minute it very thoroughly, we did conclude (didn't we?) that we wanted to go the independent/individual submission route. We would need to resubmit the drafts and change the tag to Informational. Then we'd have to get in touch with the (edited) Independent Submissions Editor and provide a list of relevant information.
There are two formatting issues created in making the I-Ds – these are totally I-D artifacts:
In addition, we may want to consider absorbing a couple of GitHub issues that would make this turn into an UMA 2.0.1 because of our semantic versioning commitment:
An UMA 2.0.1 is still "UMA2". It's a patch release that fixes a couple of unimportant bugs. George and Thomas speak in favor. We had looked up whether Kantara has an errata process and it sort of may, but this should be better since most people, especially devs, have a strong expectation of what patch numbering means. We should publish any patch spec versions (on the KI site) in the same place as the original version, such that if you expected to get "UMA 2.0.0" but there is, say, an "UMA 2.0.2" available, you get that in the same location. An "UMA 2.1" would be in a different location because semantically that's significant.
Nancy notes that a use case where the AS is not the IdP is something she's running into now. Eve is finding that this is where deployments might typically choose interactive claims gathering, PCT usage, etc.
Justin sent this compendium of use cases for XYZ to the OAuth list.
OAuth2 had baked into it the concept of "grants", and that meant a lot of things got squished into grants. Extensibility is in XYZ, but it comes in different ways. Might this mean there won't be an explosion of specs over time, the way OAuth2 was susceptible to? Weirdly, client IDs aren't there, error messages on the front channel... They're not there because you don't need them.
We should be sure to capture, not just use cases that OAuth is struggling with, and use cases that UMA solved because OAuth couldn't do them on its own, and use cases that UMA is struggling with, but also use cases that people have pressed OAuth and UMA into service for "just fine" as far as they are concerned but they're not at all sure how XYZ would solve.
George would like to be able to define and name an extension with a clear set of functionality.
UMA-related use cases Eve would like us to write up:
She would be grateful for volunteers to help draft some of these for next week.
IETF 106 is in November in Singapore. Justin will be there in person. He's working on hopefully having them hold a BOF on XYZ there. Thomas advocates for a new WG.
Voting deferred. We do have a meeting next week.
As of 16 Jul 2019, quorum is 5 of 9. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike, Cigdem)