I'm working on the agenda, which will include a series of concrete issues to work through, mostly not huge and some from email (e.g. the latest from the set math thread). For now, if you haven't yet familiarized yourself with rev 10, please do.
https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-10.html
Also, please make a note to do your best to attend all meetings through Feb 9.
Here's the key part of the newly changed TOC; it could yet be changed further and I've already collected some good feedback:
1. Introduction
1.1 Roles and High-Level Communications
1.2 Notational Conventions
1.3 Federated Authorization
1.3.1 HTTP Usage
1.3.2 Resource and Scope Interpretation
1.4 Protocol Flow Summary
1.4.1 Protection API and Related Resource Owner Actions
1.4.2 Authorization Interface and Related Authorization Server and Requesting Party Actions
1.4.3 Protected Resource Interface and Related Resource Server Actions
1.5 Time-to-Live Considerations
2. Authorization Server Configuration
2.1 Configuration Properties
2.2 Configuration Document
2.3 Requests to Authorization Server for Configuration Document
2.4 Authorization Server Response Containing Configuration Document
3. Protocol Flow Details
3.1 Resource Server Obtains PAT
3.2 Resource Server Registers Resources for Protection
3.3 Client Attempts Access to Protected Resource With No Token
3.4 Resource Server Requests Permissions on Client's Behalf With Authorization Server
3.4.1 Resource Server Request to Permission Endpoint
3.4.2 Permission Ticket Creation and Management
3.4.3 Authorization Server Response to Resource Server on Permission Request Success
3.4.4 Authorization Server Response to Resource Server on Permission Request Failure
3.5 Resource Server Responds to Client's Tokenless Access Attempt
3.5.1 Resource Server Response to Client on Permission Request Success
3.5.2 Resource Server Response to Client on Permission Request Failure
3.6 Authorization Process: The UMA Grant
3.6.1 Client Request to Authorization Server for RPT
3.6.2 Client Request to Authorization Server for RPT With Pushed Claims
3.6.3 Client Redirect of User Agent to Authorization Server for Interactive Claims-Gathering
3.6.4 Authorization Server Redirect of User Agent Back to Client After Interactive Claims-Gathering
3.6.5 Authorization Assessment
3.6.6 Authorization Server Response to Client on Authorization Success
3.6.7 Authorization Server Response to Client on Authorization Success With PCT
3.6.8 Authorization Server Response to Client on Authorization Failure
3.7 Client Attempts Access to Protected Resource With RPT
3.8 Resource Server Determines RPT Status
3.8.1 Resource Server Request to Token Introspection Endpoint
3.8.2 Authorization Server Response to Resource Server on Token Introspection Success
3.9 Resource Server Responds to Client’s Access Attempt With RPT
3.9.1 Permissions Assessment
3.9.2 Resource Server Response to Client on Sufficiency of Authorization
3.9.3 Resource Server Response to Client on Insufficiency of Authorization
Eve Maler (sent from my iPad) | cell +1 425 345 6756
Cigdem asked some good questions in a series of comments she sent me:
Core Section 3.5.3
<https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-09.html#give-rpt> (rev
09) has a Note that explains: "The authorization server is free to choose
to return either the same RPT that appeared in the request or a new RPT,
and it is also free to choose to *invalidate or retain the validity* of the
original RPT or any permission that was previously added to that RPT."
Cigdem's questions were (slightly edited):
*If the original RPT was valid, wouldn't the client have gotten access to
the resource at the resource server? Would the client ever ask for another
RPT with a valid original RPT? Does it describe the case where the RPT was
for one resource/scope and not expired, but the client tried to use it to
access another resource/scope and failed?*
What we were trying to say was that:
1. *(Client can bring no RPT and ask for one -- not a concern)*
1. *(AS can issue a new RPT A -- not a concern)*
2. Client can bring RPT A that doesn't have a permission for what it
wants to do and ask for an RPT that works for what it wants to do
1. AS is allowed to reissue the existing RPT A (same RPT string), having
added the relevant permissions to it
2. AS can issue a new RPT B (different RPT string), having added the
relevant permissions to it
1. AS can invalidate the old RPT A that the client brought it upon
this action
2. AS can retain the validity of the old RPT A that the client
brought it and any of its permission(s) -- presumably ones
that are still
good and that the client didn't just try to exercise but found wanting
The question is, do all these options truly make sense? Is it, for example,
such a common pattern for an AS to invalidate all previous tokens and stuff
all current permissions into the latest and greatest access token (which
equates to list item 2.2.1 above) that doing anything else is insanity? Any
other option would leave the client juggling multiple tokens, and having to
guess which ones unlock which resources.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
So, uh, happy new year. :-)
https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-10.htmlhttps://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-03.html
I've been working on great detailed comments from Cigdem and Mike (thanks!)
and other mostly editorial stuff, and managed to implement 98% of the big
section refactoring I've been talking about for a while
(flatten-consolidate-shorten). Please try and give these a read-through.
Questions:
- I'm starting to believe that the "*authorization interface*" is
actually properly the "*UMA grant*", tip to toe. In one place I actually
did call it that. True?
- I added a precondition/assumption that the client needs to use the *client
credentials grant* to get an access token to use in the header when it
makes a call to the token endpoint to get an RPT. Is my understanding
correct? We didn't say anything about this before.
- We have "five definitive errors" that *end the authorization process*.
But is there anything that should happen to make this truly definitive?
Should permission tickets expire, or what?
- I've got a couple of other *Table of Contents nerd questions* that I'd
love to pore over with others similarly inclined in a quick session before
our Thursday session. Self-identify and I'll find you.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
