https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-15.html

Attending: Eve, Cigdem, George, James, Justin, Robert, Sarah, Domenico, Crina, Sal

Crina Cimpian is from Philips. She continues François’s former work. They’re using UMA in Philips Healthcare.

Thanks to all for a great call! We’ll be able to close quite a few issues and get <20 open ones, and have a Core rev 16 to look at, by Thursday. Most of the real live-wire issues will be about RReg by then.

Lots and lots of work, fairly invasive I'm afraid, almost all in service of what I hope are the final set math changes. No doubt we'll find some tweaks still to make, but let's the big decisions have been made. This takes into account the last ad hoc, the last telecon, and the GDoc we were working in.

Please pay special attention to the following sections, related to set math:

• The TOC (for overall cleaner flow)
• 1.3.2 Resource and Scope Interpretation
• 3.4 Resource Server Requests Permissions on Client's Behalf With Authorization Server
• 3.6.5 Authorization Assessment and Results Determination (note revised title)
• 3.6.6 Authorization Server Response to Client on Authorization Success (note the following "PCT" section was folded in)

Also enhanced/tidied up:

• 1.4 Protocol Flow Summary / 2.2 Configuration Document and Discovery Endpoint (former now discusses and points to latter, and latter has expanded title; we actually have one more endpoint than we usually talk about)
• 3.2 Resource Server Registers Resources for Protection (added a note about RReg timing since this comes up a lot)

For tomorrow, it will really really help if people review the new text ahead of time, and if possible can even send comments in email. I want to work from the GitHub issues and pick off as many of them as we can (I don't know of any outstanding issues that aren't in GitHub, so please submit any you know of). Specifically, I plan to close some easy issues; anyone keeping an eye on issues they care about will be responsible for reopening/yelling...

Sec 3.4: Has a typo: s/nn/an/

Sec 3.6.1: Instead of “If the client wants to manage a single RPT for this combination of requesting party, authorization server, resource server, and putative resource owner, it MAY include the RPT here. (Note: Since a resource's location might not publicly reveal its resource owner, a client might not be aware of the specific resource owner associated with an RPT.)” say this:

“Note: It is out of scope of this specification for a protected resource’s location to inform the client about the identity of its resource owner.”

Sec 3.6.5: Say what it’s an example of: “The following example illustrates authorization assessment where partial results are obtained:”

What happens if the client whiffs it and includes a previous RPT that is wrong for this AS or something? The AS could refuse to upgrade and just proceed with issuing the new RPT. Should we say anything at all about “reasons to decide”? We just need to make what is now ambiguous into a MAY. First, rearrange all of the results section paras to accommodate the following:

“The authorization server MAY choose to implement RPT upgrading. It is RECOMMENDED for the authorization server to document its practices regarding RPT upgrades and to act consistently with respect to RPT upgrades so as to enable clients to manage tokens efficiently.”

Then lay out the three cases, by adding “If the authorization server has implemented RPT upgrading… blah blah blah”

Sec 3.6.6: Keep the first example.

We have rough consensus on closing the set math issue (#266). From here on out, it’s reviewing new text for rhetorical improvement, and testing through implementation of the latest changes.

====

Sec 1.4: Mention that the endpoint is referenced in Step 6.

====

Sec 3.2: For the “Note: No specific timing of initial registration is mandated, but a typical choice is just before a resource owner needs to set policy conditions at the authorization server.”, should this go in the UIG instead? Should we call out to the UIG at this point? Yes.

====

Issue #281: https://github.com/KantaraInitiative/wg-uma/issues/281 See resolution and implement.

====

Issue #275: https://github.com/KantaraInitiative/wg-uma/issues/275 See resolution and implement.

====

Sec 9.4.1: Need to change the second listing of rpt to pct, and add upgraded.

====

Sec 3.6.7 and Sec 4 and Sec 9.4: Our new grant defines its own new error codes. Are these UMA errors, or OAuth errors? The latter, and also, invalid_scope is one that OAuth already has, so we need to define the special way in which it’s used rather than saying it’s new. And Sec 4 needs to be refactored.

AI: Justin: Please help Eve structure Sec 9.4.1 correctly.

Let’s actually add a Sec 9.4.2 discussing the error responses.

====

Issue #273: https://github.com/KantaraInitiative/wg-uma/issues/274

Let’s just keep the (ugly) URN. The “ticket” is in there because the ticket-passing pattern is a defining feature.

====

Issue #273: https://github.com/KantaraInitiative/wg-uma/issues/279 See resolution and implement.