Since I wasn't able to make the call, let me try to lay it out end to end for people to see what I'm talking about:

0) Alice sets up a relationship between RS and AS, just like UMA says to do today. Done, no big deal.

1) Bob tells his client to access a resource, the resource says "no", and points bob's client at the AS along with a ticket (which should be passed in the response header, but that's another issue)
2) Bob's client registers with the AS (dynamically on its own, or by pestering bob to email an admin and do it the hard way, whatever).
3) Bob's client then sends a request to the token endpoint using a *new* OAuth grant type, let's call it grant_type=uma_authorization (in reality it's a URI but work with me here). The ticket is passed as another parameter, since it's just a simple string.
4) The combination of the client's own credentials and the ticket are sufficient to start the token request process for Bob's client.
5) As this is a call to the token endpoint, the client can even ask for a specific set of scopes, just like it could with a refresh token or other backchannel grant types.
6) The AS decides that it needs to know more about Bob before it can issue a token, so it responds with "need_info" to the client.
Bob's client then figures out a way to get those claims to the AS, either by casting a spell and getting a magical assertion that can ignore audience restrictions and other security and sanity measures (which people have pointed out that they're already doing in practice) or by having Bob interactively present himself to the claims gathering endpoint.
7) If the client passes an assertion, it can do so to the token endpoint in a new parameter, like say uma_assertion=ejy...foo. Basically "oh let me try that again but with more stuff this time".
8) If the client sends Bob to the interactive claims gathering endpoint, Bob can log in to a local account, or use a federated login (like the OIDC model we used in PoF), or provide some shared secret that Alice emailed to him, or squint really, really hard at his screen -- whatever the claims require. The AS is still free to have this be whatever it wants, importantly including capturing Bob's consent to use the client (since it's identified itself here). [ Also note that in the alice-to-alice case, the AS can basically re-purpose its authorization endpoint after Alice logs in and this all collapses to vanilla OAuth. ]
9) With the claims probably in place, the client can try again at the token endpoint with the same ticket.
10) If the claims aren't good enough, repeat 6-9 ad nauseum until someone guesses the right set of claims (but that's another issue). If they're good enough, issue an OAuth token using the standard OAuth token endpoint response structure. This includes expiration, scopes, and other hints to the client. It can even include a refresh token, ID token, or other extension stuff. This also allows the RPT to be a PoP token without UMA having to say anything about whether or not it is, since token_type is a required response parameter and UMA can now inherit new token definitions.

Bob never sees or uses the authorization endpoint. Bob never needs an account (federated or othewise) at the AS that is capable of doing regular-user stuff like issuing OAuth tokens. The AS doesn't have to carve out special "external" accounts that only allow for the "uma_authorization" scope but not act as regular OAuth resource owners. (Remember, this is Alice's AS, not Bob's, and Bob has no business getting a regular OAuth token here.)

The AAT isn't needed for anything since Bob's client is identified directly and Bob is identified through claims (which already exist). The client could further be identified through claims if it wants to.

The RPT endpoint isn't needed since this is now just a slightly-specialized OAuth grant type. Many systems (including our own) already have hooks for extending with handlers for new grant types as this is once place where OAuth is *already* extensible. In our own implementation, we'd get handed the request from the token endpoint handler (which already validates the client and syntax of the input among other things)

The JSON response from the protected API isn't needed either since the ticket is a single string and can easily (and safely) be passed back in a header. ( again this is another issue but if we're breaking all wire compatibility let's get it right... and a note on the returning-the-ticket-as-a-header thing. It also opens the door for public API responses and discovery of multiple user stuff, like this (totally off the cuff):

Public data can be solved like: Bob's client talks to a URL with no token and gets back some data, but a header that says "if you want more go to this AS and present this ticket.

Multi-user data (like the userinfo endpoint) can be solved like: Bob's client talks to a URL and gets sent back a header that says "if you want more then give me an indicator of who you're after (an opaque token, a webfinger URI) or go to this interactive page to have Bob figure it out, then come back and we'll talk again". Basically, you can bootstrap the process with some user interaction that could lead into George's multi-stage protected discovery system.  )


Someone is going to have to explain to me what is possible in the current system that is not possible in the above setup, because I'm not seeing anything.

Can we build it like it is today? Yes of course; I've done so myself. It works, but it's clunky and ugly and requires lots of special "if-uma-do-this" kind of code. I don't like that. It also requires Bob being able to do a regular OAuth flow to get the AAT even if he's not a local user, and I don't like that either.

So let's say we did things this way and called it UMA 2.0.0 (since this is a very backwards-incompatible change set and the group has adopted semantic versioning). What does that mean for me as a developer? Quite frankly, it means a whole lot less special code for implementing UMA at the AS, the client, and the RS, assuming I'm starting from an OAuth system. And it makes it much, much easier for me to have dual-purpose codebases that do both UMA and OAuth. Both of these are highly appealing to me as a systems architect and developer, and I don't think that I would be standing alone in this opinion.


  -- Justin

On 8/6/2015 1:29 PM, Allan Foster wrote:
In the discussion there was talk of the new flow,  and how we get Bob's consent.

It came to me that we are only talking about using the token endpoint, at the moment.  In order to collect claims about Bob, wouldn't we need to use the User Endpoint?

If so,  this should happen early in the flow,  and is where the actual consent can be captured

Allan



On 8/7/15 1:05 AM, Eve Maler wrote:
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-06

Minutes

Roll call

Quorum was reached.

Minutes approval

MOTION: Approve the amended minutes of UMA telecon 2015-07-30. APPROVED by unanimous consent.

APAC-friendly sync update

This sync schedule is working really well.

Spec versioning process update

No update. Eve hasn't moved the repo over.

Issue resolution work

Issues 153 and 154

Not meaning to guess Justin's exact thought process in any way...

Observation #1: AS has a special "RPT endpoint", making up the entirety of the special "UMA authorization API", at which the UMA client asks for a special UMA "RPT" with authorization data on Bob's behalf, that acts suspiciously just like an ordinary OAuth token endpoint. If it were more like an OAuth token endpoint, greater UMA-OAuth alignment could be achieved.

Observation #2: The UMA "authorization API token" (AAT) is an extra layer and hindrance to the entire OAuth-friendly cycle in this case, particularly because it appears to require that Bob have a login at the AS.

Discussion: Isn't the last bit, about the login, just an implementation decision? He has to either be SSO'd into the AS, or have a local login at the AS, or be offered a federated ("NASCAR-like" or whatever) login option at the AS. More accurately stated, he has to be able to establish an authenticated relationship with Alice's AS.

Observation #3: If the AAT flow were entirely removed and the RPT endpoint were turned into a ordinary token endpoint, then Bob's client would approach it to ask for "an access token" (perhaps of some UMA-flavored type?).

Discussion: Eve contends that, since we are trying to keep everything as much the same as possible, then this new "UMA-flavored grant flow" would still (so far) have the the client approach the RS, fail, get a ticket, go to the AS's (now) token endpoint, ask for a token, and engage in the trust elevation flow we have already designed.

Observation #4: Instead of using an AAT in the header of the token request, it would use its client credentials to identify itself, basically using its own recognizance.

Discussion: Where else is the AAT required in headers? Is it required in the redirect of Bob for claims-gathering? No, there are other security measures imposed. What about in the case of an autonomous web service client? We think that this could use pushed claims to the token endpoint as well.

More discussion: The AAT isn't very high-value! So a kind of "merge" to elevate what was the AAT flow up into what was the RPT flow to become an analog of a typical OAuth flow looks attractive. That means the claims flow would be the very first thing Bob does – no AAT step before. That seems kind of clean as a UX, if we're not missing anything like Bob's consent. And we don't think we're missing that, because that's what the OAuth flow is designed to do. The RPT represents everything the AAT did, but more. Why didn't we consider this before? In fact, we did.

More discussion: In both the authorization API circumstances and the newly imagined grant flow circumstances, how does Bob know exactly what claims the client is pushing?

Observation #5: UMA is still OAuth++ or value-add or something, in that the protection API that makes the AS and RS loosely coupled and makes possible trust establishment between them (using OAuth) is added on top, and in that Bob is a completely autonomous actor wrt Alice (which is why the grant flow we're considering has trust elevation as a key part of it), and in that the grant flow we're considering has asynchronicity as a key part of it. All the value-add still seems to adhere even if the AAT isn't part of the picture.

Discussion: Regarding the Privacy concerns: if the Client does a POST on the RPT to get the AuthzData added to it, the AS can still decide to return a new RPT to the Client (if the presented RPT had AuthzData for another RS attached to it). So that could be a AS-privacy setting? According to the APAC discussion yesterday, the answer appears to be yes. We can use a MUST to force the AS to mint a new token per RS. (Justin also noted in email that if the client tries to present a token from RS1 for upgrading with authorization data for RS2, the AS should not allow that.)

Discussion: Is UMA all pseudonymity-based? The AS knows Alice by AliceID(AS). The AS knows Bob through some set of claims, potentially. Each RS knows Alice by AliceID(RSn). Each PAT is a kind of pseudonymous federated ID by which both the AS and that RS know Alice. Each client has a set of access tokens (in the putative new solution) with a set of permissions, but not identifiers.

Discussion: How would the client manage multiple access tokens? All it knows is that it's trying to access a resource. How would it know that the token it has been given is new for this RS? What if the spec said this (bold is new)?

"If the client did not present a token in the request for authorization data, the authorization server creates and returns a new token. If the client did present a token in the request, the authorization server returns the token with which it associated the requested authorization data, which MAY be either the token that was in the request or a new one. In any case, the authorization server MUST return a new token when the client presents a token that is associated with a different resource server."

Summarizing our sense: Generally positive about most aspects, but there is a concern about how clients handle the token situation, and some uncertainty about ensuring that the requesting party really has a chance to authorize the interaction.

Next steps:

  • AI: Eve: Develop swimlanes (web sequence diagrams) of the putative new flows, along with pros and cons, and share with the group by Monday.
  • Let's TRY and have an active discussion, drawing in Nat, about the client concerns, before next Thursday.
  • Let's TRY and conclude issues 153 and 154 in the early part of next Thursday's meeting. If we have a specific proposal in front of us for issue 165, we'll consider it, otherwise not. We'll also take up 160, 161, 162, and 168 next time.

Regrets for next time: Andi, Robert, François, Ishan, James, Domenico. Ooh, next week is going to be tough for quorum, so everyone else please try and attend if they can!

AI status

  • AI: Thomas: Review the charter for potential revisions in this annual cycle.
  • AI: Sal: Investigate IP implications of formal liaison activities with other Kantara groups with the LC, and ultimately draft an LC Note as warranted.
  • AI: Gil: Edit the UIG to add Ishan's content and excerpt it for Eve to add to the FAQ, pointing everyone to the UIG.
  • AI: Sal: Fill out IDESG form to have UMA adopted as a recommended standard for use in the IDESG framework.
  • AI: Mike: Write SCIM protection case study to highlight client claims-based use case.
  • AI: Maciej: Write as many sections for the UIG as he can.
  • AI: Justin: Write a UIG section on default-deny and race conditions.

Attendees

As of 30 Jul 2015 (pre-meeting), quorum is 7 of 12. (François, Domenico, Sal, Thomas, Andi, Phani, Robert, Maciej, Eve, Arlene, Irwin, Mike)

  1. Eve
  2. Andi
  3. Irwin
  4. Domenico
  5. Maciej
  6. Robert
  7. Mike
  8. Arlene
  9. François

Non-voting participants:

  • Adrian
  • James
  • Rene
  • Mark
  • Ishan
  • Allan
  • Jin

Regrets:

  • Thomas
 

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com



_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma




_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma