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.
- 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.
- 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.
====
We're meeting tomorrow at what would be our usual time and coordinates (special meeting time/length of 90 minutes, 8:30-10am Pacific), except on Tuesday instead of Thursday:
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.
- 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.
- 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.