[WG-UMA] New flowchart: scoped access in pictures

Eve Maler eve at xmlgrrl.com
Thu Mar 31 11:11:41 EDT 2011


After our discussions of the last couple of weeks, I thought it might be useful to have a high-level sketch of message flows to consider.

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 bob at 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:
> 
>> Here is another way to understand the scoped access discussion we had on Feb 23-24; hopefully I translated all the discussed details correctly.  (The callout letters are just for unambiguous reference during discussion.)
>> 
>> 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
>> 
>> <uma-flowchartV4.png>


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl



More information about the WG-UMA mailing list