[WG-UMA] Notes from 11 Jan 2011 conformance ad hoc call
Eve Maler
We started working through Cordny's Step 1 test cases (http://kantarainitiative.org/confluence/download/attachments/45057622/Testcase1_logical_05122010.pdf) and the language in the core spec around Step 1 (http://mrtopf.clprojects.net/uma/draft-uma-core.html).
Step 1 first test case:
We think we need to mention that the host takes on a role of OAuth client, in addition to (or, for our purposes right now in step 1, instead of) OAuth resource server. And the AM has the role (in step 1) of both an authorization server and a resource server, where the protected resources in question are the endpoints of the UMA-dictated authorization API that AMs present to hosts.
Terminology question: Should UMA start using OAuth terminology more closely? Perhaps we could use "client" successfully instead of "requester", and "[end-user] resource owner" instead of "authorizing user". But since hosts and AMs play multiple OAuth roles, maybe it wouldn't be as easy to switch to "resource server" and "authorization server" respectively for them.
Substep 2 can't point to a stable dynamic registration draft yet, but we hope to point to one that the wider OAuth community agrees on eventually.
Further, the AM doesn't strictly have to support dynamic registration, which means that the host's attempt to get client credentials at this juncture could fail. Questions we need to answer:
- Does the AM have to declare ahead of time (maybe in its metadata) whether or not it supports dynamic client registration and, if so, what standard it supports for doing so?
- What should the host's behavior be if it can't successfully get client credentials after the user has said "Use this AM"?
- The AM's decisions around client credential provisioning (whether dynamic or static) are intimately bound up with trust models. For example, it might require static provisioning so as to "whitelist" specific hosts. Or eventually we might profile UMA further to allow for dynamic demands for claims during step 1 to ensure that the host meets trust framework liability requirements.
- The host may itself want to make trust model decisions about the AMs it is willing to work with. This could be reflected in the host only offering to connect to a small subset of "whitelisted" AMs on the user's behalf, or by other more dynamic means. What should happen to the UX in this case?
- UMA doesn't want to solve all the trust model problems in the world, but if hosts and AMs respectively could present third-party-asserted claims about their participation in trust frameworks, then the UMA step 1 process could take advantage of them.
Step1Branch1 test case: The description of how the user provisions the URL to the host can be softened; the UX style of provisioning is not dictated by UMA.
Step1Substep1Branch1 Happy flow: This makes the key assumption that the AM has made a well-formed hostmeta doc according to UMA's constraints.
Step1Substep1Branch2 (still in progress??): Let's nickname this "stupid host". This is accounted for in the spec already by making sure to say that the host MUST conform to the hostmeta spec in constructing the URL and GETting the hostmeta content. The errors the user would experience through "stupid host" would be HTTP-level errors of some kind, such as a 404, and in fact the user may not even experience it: the host would get the 404 from its direct interaction with the AM.
Note that the host may have already gotten client credentials from the AM on a purely OAuth or an UMA basis, let's say on Bob's behalf last week, such that at the time that it tries to pull UMA-specific endpoints on this user's behalf, it has already completed the registration process. But should it always refresh its understanding of the UMA endpoints for each new user even if it has already gotten them prior? Since the hostmeta document is a web resource that can have a header indicating how long it can be cached, the host should have the right to not retrieve this again if it already did.
Let's try and construct all the happy flows we can think of for step 1:
Flow 1a (happy): Photoz hasn't ever interacted with CopMonkey before, and CopMonkey supports dynamic client introduction with no trust-model constraints: Alice introduces Photoz to CopMonkey by giving it the CM URL. Photoz constructs the hostmeta URL from it, follows the URL, retrieves the hostmeta, and successfully finds well-formed UMA-related hostmeta there. Photoz dynamically asks for and gets client credentials (let's assume using UMA's own dynamic client credential spec for now). Finally, Photoz, redirects Alice to the CM end-user authorization endpoint.
Flow 1b (happy): Photoz has interacted with CopMonkey before on Bob's behalf, and already got client credentials, and already has cached versions of UMA-related hostmeta endpoint information that is still valid: Alice tells Photoz she wants to use CopMonkey, and Photoz proceeds immediately to redirecting Alice to the CM end-user authorization endpoint.
Flow 1c (happy): Photoz has gotten static OAuth client credentials from CopMonkey in a normal OAuth static relationship-building fashion, but it has not previously paid any attention to CM's UMA-related endpoints: Alice tells Photoz she wants to use CM. Photoz constructs the hostmeta URL from it, follows the URL, retrieves the hostmeta, and successfully finds well-formed UMA-related hostmeta there. It doesn't need to use the dynamic client registration endpoint found there because it already has OAuth client credentials, but it makes use of the other endpoints found there in redirecting Alice to the CM end-user authorization endpoint.
We could make trust-constraining flows that assume various sorts of whitelisting, blacklisting, or (eventually) dynamic claims-based trust establishment.
The last unhappy flow could be nicknamed "bad hostmeta on AM". This should account for the purely syntactic problem of the hostmeta format being broken, or the AM not putting the hostmeta in the right place according to the hostmeta spec.
What should the host do in response to the AM's error? It would have to produce an error response for the user somehow.
Next steps/AIs:
Eve and Cordny to brush up the Step 1 test cases and the core spec Step 1 section to reflect this discussion, moving revised test cases to the wiki.
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