Attending: Eve, Cigdem, Mike, Domenico, Kathleen, James, Robert, Justin, Thomas, Adrian, George, Sarah

Regrets: Sal

NOTE: Thanks to our lucky mishap with the overbooked dial-in line in the middle of the call today, and thanks to Thomas's continued support, we've beta-tested the join.me/findthomas method of calling in, and we'll be switching to that method starting next week.

Core rev 14 is up. Some notable edits:

• Some text appearing in Sec 1.4.2 in an attempt to close #264, Authentication-related error details. It's not a code example with error_details asking for ACR claims or anything, but it does briefly explain a couple of anticipated more-common design patterns for claims collection flows.

Fix “redirecting party redirection” typo; should be “requesting party redirection”. Mike likes the new wording; Justin would like a chance to review. Certainly. :-)

AI: Eve would like to add WSDs to the UIG.

• Some text has been added to Sec 3.6.5 (Authorization Assessment), at George's suggestion, to discuss the AS's responsibility to be aware of and manage freshness/staleness of information such as claims.

We have a bug in the example in this section. We think that the link scope on rsid_1 should probably be print; doublecheck.

The new text should also apply to the previous RPT because it’s also persistently stored. Or is it? Yes it is, because the AS manages those permissions itself.

• The text in Sec 3.4 about how the RS chooses what permissions to request has finally been changed according to the consensus reached in the 2017-01-05 telecon, namely it's okay to request permissions that don't suffice for the access the client attempted. I added an observation in the text to the effect that if the RS does this, it may result in further back-and-forth (based on our recent convos about inefficiencies). Please see what you think.

See below discussion.

Our agenda is sort of a tossed salad of topics that really need attention, so that the specs can be in consistent format with substantive issues closed ASAP. I've listed a bunch of items here in what I hope is a rational "easy to hard" order so we can build on success. Please feel free to respond in email ahead of time -- not that there's much left -- to share your opinions.

Set math:

• Should the AS be forced to grant CandidateGrantedScopes if they came from PermissionTicket, or not? Let's not take forever to decide this.

See Eve’s proposal below. This also ties to the new language added in Sec 3.4, mentioned above. Do we actually think it’s tenable for the RS not to request the actual scope that the client attempted access to (call it AttemptedScope)? The “partial results” challenge is our main conundrum underlying all the problems, it seems.

Can we separate all the scopes into “required for issuance” and “optional for issuance”?

The client does these actions:

1. Register for scopes at the AS (outside an RqP context: RegisteredScopes)
2. Attempt access at the RS (in an RqP context: AttemptedScope)
3. Request scopes at the AS (in an RqP context but inflected by what it’s capable of generally: RequestedScopes)

The RS does these actions:

1. Register scopes at the AS in a resource context (in an RO context: no variable)
2. Request permissions at the AS on behalf of a client (in an RO context: PermissionTicket) — for this, the RS has to evaluate the access attempt with no client context that is in band of UMA

We’re less certain now of our agreement on Jan 5 that it’s okay for the RS to request permissions that don’t suffice for the client’s access attempt. If we expand this out again, Justin had wanted to make it a SHOULD because the client now has the power to register/request its own permissions. But since the RS always has the “right to refuse service”, this controls for needing “empty permissions”. So it could be a MUST. But Justin would like the MUST to be okay as long as PermissionTicket can be empty.

If the RS’s API design is not pure REST, and the relationship between scopes and API calls is such that it’s impossible to map a single call to a single scope, what if AttemptedScope needs to map to multiple scopes — and even “all the resources” (because the API uses scopes as a moral equivalent of the entire API)? This is a frequent occurrence. George asks if, in this case, the RS could just request the necessary resources and not the specific scopes. So PermissionTicket would indeed have no scopes in it.

Some good examples of scopes that are invisible from the perspective of the API call:

• normal vs. admin privileges while reading (the same) data (which the RS could presumably interpret consistently as some resource)
• A POST that could look like create or update or delete scopes

• What is the purpose of providing a previous RPT -- upgrade in order to manage a single RPT? Let's use current OAuth grant logic by analogy as much as possible ("no surprises"), and not duplicate purposes between a PCT and an RPT provided on the same request.

Justin suggests that there are two choices: Either the AS accepts all the permissions in the previous RPT, or it adds all the scopes in the previous RPT to the requested scopes and recalculates; both should be possible.

Since no other OAuth grant allows the client to send a previous access token to the token endpoint, is this a case of overdesign to allow the client to try and manage its tokens through an up-scope path? Keep in mind that we still currently have the “efficiency challenge” around the client’s inability to ask for new resources by any path other than attempting access to them, and around the RS’s and AS’s inability to inform the client that it didn’t get what it wanted.

Will the client’s number of RPTs spin out of control if it can’t upgrade them? From the client developer’s perspective, what’s the expectation for token management? Normally, OAuth clients will be told by an AS what scopes they got back (but that’s not guaranteed).

Since the RPT is a tuple of RqP/C/RS/RO, if the client supplies a previous RPT on a request, it does seem that it would be asking for upgrades and if the AS obliges, it would become a supertoken. We believe the RPT has to be bound to a single RS because the resource IDs are within a PAT-specific namespace, and the RPT is introspected by a single RS. Whew.

Spec instructions:

• Add back language saying that the RPT is a tuple of RqP/C/RS/RO.

Eve floats an idea: What if we had a way for the RS, on permission requests, to (possibly OPTIONALLY) flag the scope that the client actually attempted access to? Then the AS would know that info -- call it AttemptedScope -- and we could a) have it tell the client whether or not it got issued during RPT issuance or b) decide that if it didn't get issued, this is good enough to fail the RPT request and/or c) return this info in the token introspection object so the RS doesn't have to track it?

Justin doesn’t like this idea because it encourages forcing failure of issuance. And if it’s all optional, what’s the point? The point could be that otherwise it’s a loss of information, the use of which, in different ecosystems, could be used by the AS, the RS, and/or the client to create efficiencies in a way that’s not as invasive to the spec as some other methods we’ve been discussing.

Regarding the partial-results conundrum:

• For APIs with a “close match” between API calls and scopes, informing the client that “it got AttemptedScope”, it would know. Otherwise, not. Better if the client is simply told what scopes work? But maybe it’s still better to keep that hidden.

• How to do authorization in the presence of a PCT on the request? a previous RPT? both?
• Do we think the AS needs to report scopes granted to the client?
• Do we still think the AS needs to report any contextual information about its authorization assessment to the RS?
• In Sec 1.4.2, it says the assessment phase starts immediately if the client asks for an RPT without pushing claims. This is also true only if the client doesn’t provide a PCT, right??

Slightly farther afield:

• Do we think the RS SHOULD document its permission request practices, just as it would document its API generally and its scopes, so that clients will know what to expect as they continue down the RPT request path?
  

RReg/permission-related:

• I’ve been getting feedback from several people about the goodness of our having added the ability to request multiple permissions at once. Combined with the popularity of the “lazy resource registration” pattern (which I’ve finally reflected in the swimlane), the RS will tend to call the rreg endpoint right before calling the permission endpoint. #277 is about allowing rreg of multiple resources. Should we align the request messages in other ways, like changing “scopes” to “resource_scopes”? Also, several people have pushed back on the array-for-multiple and object-for-singular design is inconsistent with frequent identity/LDAP practice and also inconsistent with the pattern we used in a lot of the rest of the spec.