[WG-UMA] New core spec with Step 3; next stop, scopes
Eve Maler
http://mrtopf.clprojects.net/uma/draft-uma-core.html
http://mrtopf.clprojects.net/uma/draft-uma-core.txt
Now I think we're at the point where we need to get more precise about the scope registration solution. It seems we are well down the path of choosing the scope proposal (vs. a highly Web-resource-specific resource registration approach); if you will recall, Christian's proposal is here:
http://mrtopf.clprojects.net/uma/draft-uma-scope-registration.html
http://mrtopf.clprojects.net/uma/draft-uma-scope-registration.txt
Ah, and I see Domenico just has sent some new UX wireframes exploring how scope might work in practice; please check that out!
Scope needs to affect several parts of the protocol. I thought I wrote up this list at some point before, but can't find it, so here's another attempt. *=passed in a message
Step 1 (or anytime thereafter?)
- *Host registers scopes with AM
Step 2
- Requester attempts protected resource access at host, allowing host to infer potential suitable scope(s)
- *Host redirects requester to AM with info about what scope(s) to ask for (needs to be secured somehow?)
- *Requester conveys desired scope(s) in approaching AM
- AM uses desired scope info to match applicable policy (hmm, did we account for multiple scopes here?)
Step 3
- Requester attempts access, this time with token, allowing host to infer required suitable scope(s)
- (Host conveys token to AM for validation)
- *Assuming token is valid, AM returns applicable scopes for it
- Host maps applicable scopes to scope of attempted access
Did I miss anything?
Eve
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