Thanks for taking a look, and I'd say your gloss of it is exactly right. The idea is that externalizing the authorization function from many hosts to a clever enough AM service (there are plenty of UX implications here in addition to protocol stuff) could let you keep better track of your digital footprint, apply consistent policy across various categories (per host, per requester, per resource class...), and even help you extract promises (or payments) from the requester before granting access.
The one sub-relationship among the four parties that is the *least* dynamic is the user's introduction of the host to the AM. It's the one prerequisite step before the actual authorization flow. LRDD/XRD comes into play in that first step too, though, enabling the host to learn how to begin authenticating to the AM and subsequently how to send (OAuth-enabled) UMA access requests to it. Swimlane diagrams of the steps are linked off here: > http://kantarainitiative.org/confluence/display/uma/UMA+Explained ...as is a flowchart of the post-step-1 authorization flow. Eve On 23 Nov 2009, at 6:53 PM, John Panzer wrote: > It sounds very interesting. In OAuth terms, I think it adds, to the basic > OAuth 3 legged flow, the ability to delegate the authorization decisions > 'normally' made out of band of the OAuth protocol to a completely separate > service. Aftet 60 seconds looking at it, my first silly question is how the > AM service is determined -- it looks like everything is based on LRDD > starting from the resource being accessed? > > -- > John Panzer / Google > [email protected] / abstractioneer.org / @jpanzer > > > > On Mon, Nov 23, 2009 at 6:04 PM, Eve Maler <[email protected]> wrote: > The User-Managed Access effort[1], previously mentioned on this list as > "ProtectServe", intends to solve user-driven permissioning (authorization) > problems at Internet scale. It is designed to be modular, and to reuse and > profile existing technology as much as possible. Therefore, we have attempted > to "stay out of the business of authentication", profiling OAuth lightly in > order to do so. > > The UMA group would be grateful for your feedback on our intended usage of > OAuth and its emerging discovery methods. Details can be found in the worked > example in our spec[2]; various explanatory materials about UMA in general > are available as well.[3] > > Briefly, the UMA protocol has four distinct parties vs. OAuth's three: > there's an authorizing user, a consumer/client (which we call a"requester"), > an SP/server (which we call a "host"), and an authorization manager. We > compose three instances of OAuth to introduce all these parties appropriately > to each other: there's user/host/AM (three-legged), requester/host > (two-legged), and requester/AM (another two-legged). Because of our goals to > allow most of these parties to meet fairly dynamically, we are leaning quite > heavily on XRD and LRDD for discovery; various simplifying assumptions could > probably be made to simplify this picture, however. > > (If you find UMA's use cases and design center interesting, you'd be very > welcome at the table.[4]) > > Thanks, > > Eve > UMA group chair > > [1] http://kantarainitiative.org/confluence/display/uma/Home > [2] http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol > [3] http://kantarainitiative.org/confluence/display/uma/UMA+Explained > [4] http://signup.kantarainitiative.org/?selectedGroup=11 > > > Eve Maler > [email protected] > http://www.xmlgrrl.com/blog > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > Eve Maler [email protected] http://www.xmlgrrl.com/blog -- You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
