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
--
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.
