[WG-UMA] New flowchart: scoped access in pictures
Eve Maler
In tomorrow's ad hoc call, let's try and hammer out the exact desired messaging structure in the etherpad. Before the call, please review this diagram, the relevant meeting notes, and the current state of sections 3 and 4 of the core spec:
Etherpad: http://openetherpad.org/uma-am-host-flows
Meeting notes: http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2011-02-24
Core spec: http://mrtopf.clprojects.net/uma/draft-uma-core.html
Thanks,
Eve
Eve Maler
Eve
========
discussion from 21 Mar 2011 ad hoc meeting:
Attending: Eve, Paul, Christian, Domenico, George
We reviewed the v5 flowchart (sent just before the call started). Our recent consensus was to separate R authentication from R authorization. We believe one consequence is that the R access token is less meaningful all by itself, and its issuance would want to be "two-legged". Is that correct? George points out that this means that the access token no longer binds the R, AM, and user together, which means we've lost something. If the access attempt at the protected resource can, on its face, be observed by the H to be relevant to a particular user, it has enough information to send the R to the AM.
Does it make sense to bind the user, AM, and R with the access token by means of a classic OAuth web server flow that has the semantic only of confirming the requesting party's identity as being identical with the authorizing user, not the semantic of authorizing particular scopes of access? In essence, it would be "log in to confirm connection" without the "consent to this sharing scope" part. The AM would be able to track access tokens of the "this is Alice again" type vs. access tokens of the "autonomous requester" type -- in effect, it's a powerful claim, if an implicit one, that the AM could treat preferentially in mapping policies to access by this party.
UX considerations are really important when it comes to satisfying OAuth-style Alice-to-Alice use cases. Look at the Dropbox example: It has a clear distinction between accesses by client applications to which Alice has provided her username and password (could have been an OAuth access token if Dropbox had wanted to do that, much as Twitter uses it for the Twitter native iPhone client) and accesses by other people.
George's healthcare example shows how signed JWT would be valuable. You could have a "three-legged" JWT and also a R-H "two-legged" JWT, which is what he sketched. In the current discussion, this is also an option: a 3L token representing Alice's confirmation that she herself made the access request could be embedded as part of a 2L R-H token.
Paul prefers the 2L approach 100% of the time in the "C" box. He predicts added complexity in the AM and possibly the R if the authentication phase is used to substitute for getting authorization claims, because there will be two flows for the same thing. He advocates using OAuth exclusively if a 3L flow is needed, and UMA exclusively for all user-not-present use cases. Eve is concerned that this relegates UMA to a less interesting set of use cases, since centrally managing a large set of Alice-to-Alice sharing episodes is valuable.
George observes that if the access token gotten in the "C" box represents merely the R (client) and is not a meaningful representation of the requesting party (since that data would have to be supplied as a claim in the "H" box), it seems not very valuable. Paul would rather put it this way: Its "Alice-ness" is not known until the R gets as far as the "H" box -- and, in fact, the unique identity of the requesting party may not be relevant to getting access (e.g., in the case of anonymous "over-18" policies). So does this mean that the requester has to manage the knowledge of which requesting party it's acting on behalf of, and figure out unilaterally whether that party is "known" or "unknown" as far as this H is concerned? [Paul, George, others: Thoughts?]
I think that R needs to know whether it has an existing token for the requesting party (as Paul has stated). The question is does it need to let host know about this "new" requesting party in the B->C flow? or can it wait until H? What is the host going to do with the information that a "new" requesting party is requesting access? In the normal OAuth flow, the host just returns "not authorized" and waits for the authorized token at which time it learns that this is a new requesting party. I think that, so far, we have the same here. H barfs at the B box and then waits for R to show up again, token in tow. It doesn't even care if the token is good or not, since we're outsourcing that decision for now. In essence, the "new requester" contextual label was simply meant to say that the R showed up without a token. Then I'm a little confused by the "two-legged" label :) Well, the R and AM are joined in OAuth but conceptually separated in UMA, right? So I was thinking that the R+AM
is the second leg together. The label was meant to raise the possibility that the user_authz endpoint doesn't/does get used. So how would R+AM be represented? I don't see that construct in OAuth. It's the "server side" in general, no? I'm digging up Phil's "legs" diagrams now... :) Ahh... I'm behind in that department... it's on my "to read" list. Here it is: http://independentidentity.blogspot.com/2011/02/does-oauth-have-legs.html He uses "legs" slightly unusually, but it's still helpful. (Hey, looks like he used the same OmniGraffle template as I did!)
>From his diagram, I don't see how R+AM fit into two legs. The host knows which AM is reuired for a given resource, and if two-legged is needed, would be able to identify the requesting service. Does the host need to know the requesting R+AM pair as if it's the wrong AM it will fail anyway?
Yeah, we have a simplifying assumption here (which is unfortunate, but...). Let's say a requester approaches a PR. The H has to be able to disambiguate, from the nature of the approach (endpoint and/or method...), which user and therefore which AM is relevant.
I'm currently thinking that IF we require 3L at the "C" box stage, the requester's request message would have to have some sort of flag saying "try giving me the user_authz endpoint and I'll try to use it". If we don't require it, the whole exercise becomes more trivial.
Anyway, the H (as already spec'd in our current core spec) has to then give the R the relevant endpoints to go to for tokens, authzs, etc. If our simplifying assumption doesn't hold, we're simply toast (so far).
So, assuming that R doesn't have the necessary "stuff" to access the PR, what is the use case where the AM disambiguation requires the R identity as an input? You mean requesting party identity, or truly R (requester) identity? The later, the service making the request. I don't think this info ever helps the AM, so that's not the right use case to motivate needing it. Sorry, I was thinking about the host needing to tell R which AM to use. Which is really the main part of B->C right? yes. if the H doesn't know which AM to send the R to, the whole thing is stuck idling. Agreed, so is the identification of R needed for H to make that decision? Basically, what information is required at H in order to determine R needs to be sent to the AM? My naive dividing line was that only the HTTP request at the H should be needed: URI plus the call made. So then I'm not sure an R+AM token is needed at the B->C stage. All R needs at that stage is which AM to interact with. Right? Paul? But w
ithout a token, R, can't proceed downward in the flow, per OAuth. Right, so when R determines it doesn't have a token, it tries to access the PR and get the appropriate AM to interact with. It then goes through the claims process with the AM, the result of which is the token to use for D->E.
So you'd prefer that the token+claims->authz/scope flow not involve the H in the middle, then? that would be more similar to our "modern" UMA flow than the flowchart currently shows
iow, no needing to keep going back to the H to be told "sorry, still not good enough". But I'm not sure if we then really have to go well off the OAuth reservation. I think once R has a token, it needs to involve H (per the latest flow chart). It's just that no token is needed for B->C. The establishment of a token for access to this PR should be between R and AM. How that token is created could be 3L or maybe some other way. (Maybe this was the point all along and I just misread where the "always two-legged?" note applied) Oh - let's ruminate on that. Take a careful look at notes above to see if they help.
(Gotta run now! TTFN)
(I also worry about R unilaterally giving a unique (if pseudonymous) correlation handle for its user to the AM by virtue of asking for a new token for each user - then again, we said we don't care about privacy of requesting parties! Come to think of it, maybe this isn't a worry at all.)
Eve Maler http://www.xmlgrrl.com/blog
+1 425 345 6756 http://www.twitter.com/xmlgrrl
_______________________________________________
WG-UMA mailing list
WG-...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma
Eve Maler
For the following, I'm assuming that:
- The access token granting (B-C) is always two-legged and now represents the semantic of a requesting party, NOT a requester. These are both a semantic change from the current core spec.
- The claims flow (F->H) is the only place where meaningful requesting party identification/characterization (unique or non-unique) will take place for the purposes of matching against user policy at the AM. So, for example, if you want to ensure that the requesting party is b...@gmail.com and this was checked with 2FA, or make them promise to adhere to your trust framework rules, or make them "prove they're you" (Alice-to-Alice sharing), this is all done at the latter stage -- possibly with special claims semantics and "authorizing user is present" flows that we have yet to spec.
- The host is doing zero local validation/observation of any token and is shipping off such tasks to the AM. (We'll have to figure out deltas with the JSON meaningful-token approach later on, e.g., having to literally trade in old tokens to get new larger ones during scope upgrades.)
Here goes... Note that there's an ambiguity with H-the-Host and H-the-step, so I've spelled things out a bit more this time. I also discovered that my flowcharting technique leaves much to be desired. :-) Who wants to improve on it and sketch the actual spec text and sample messages??
A:
- Req->Host HTTP request: Req makes some observable request to Host. This is unstandardized by UMA.
B:
- Host internally observes the request.
"No" branch off B:
- Host->Req (HTTP 401 error) response: Host responds to request in A with HTTP "unauthz'd" (really "unauthn'd") error
and additional UMA-related AM endpoint info.
C:
- Do we have to point off to a dynamic/static client registration process here, as we have done for the host access token
process in step 1? This is an opportunity for AMs to bake certain AM-and-ReqParty (vs. AM-and-ReqParty-and-AuthzUser)
trust-model consequences into the otherwise relatively insignificant act of getting such an access token.
- Final step in this process: AM-Req (HTTP success) response: You have a token; try again.
- Req goes back up to A at this point.
D branch off B:
- Embedded Host-AM request-response loop begins:
E:
- Host->AM request: Host asks AM to validate token and, if valid, supply scope manifest associated with it.
(This is a bundling optimization, where the AM's response could branch off. Does this make sense to do?)
"No, token invalid" branch off E:
- AM-Host (HTTP success) response: Token invalid.
- Host goes back up to "No" branch off B at this point.
"Yes, token valid" branch off E:
- AM-Host (HTTP success) response: Token valid; here are the scopes associated with this token.
F:
- Host internally assesses the scopes returned with its knowledge of the access attempt made.
If zero scopes returned, it goes to the "No" branch regardless; this means it has never been through G with this requesting party.
G branch off F:
- Host-AM request message: Host registers a scope request ticket with AM, supplying a desired resource set ID and action.
- AM-Host (HTTP success) response: AM gives to Host something that can be used as ticket reference.
- Host-Req (HTTP 403 error) response: Host responds to request in A with HTTP "forbidden" error and additional UMA-related claims
negotiation endpoint info.
H:
- Embedded Req-AM request-response loop begins, in which there is embedded a reverse claims request-response loop!
This is currently outsourced to a separate spec; Claims 2.0 is our current example of how it would look, but it's incomplete
in saying how the communications are fully embedded, I think. Also, we really need special Alice-to-Alice claim semantics and flows!
- Final AM-Req (HTTP success) response: No more claims needed.
- Req goes back up to A, this time wielding token that theoretically should have the right scope unless Req delays too much.
When Host gets to E and F, it will discover that Req is hunky-dory.
K:
- Host-Req (HTTP success) response: Here's your protected resource.
- Req: Yay!
Eve
On 21 Mar 2011, at 10:05 AM, Eve Maler wrote:
> New version:
>
> <uma-flowchartV5.png>
> On 20 Mar 2011, at 8:24 PM, Eve Maler wrote:
>
>> <uma-flowchartV4.png>