As requested on today's call, here's a description of the places where UMA seems to need "more" than what the WRAP paradigm offers (both profiling and extending), based on the proposal at:
http://kantarainitiative.org/confluence/display/~xmlg...@idp.protectnetwork.org/Proposal+for+UMA+1.0+Core+Protocol Cautions in reading this note: - The mix of likely needed profiles and extensions for our use of the OAuth 1.0 paradigm (the existing spec on the UMA site) is quite different from the list presented here, and in addition, that spec wasn't written with a goal to highlight such items the way this proposal was. - The proposal is currently fairly high-level, and other profiling/extension needs may come to light if we proceed down this path -- or some of the needs may disappear. The proposal nonetheless tries to document profile and extension points as precisely as possible. - UMA's terminology is similar but not identical to WRAP's. The proposal tries to be as clear as possible about the distinctions, but caveat lector. - For all of the profile/extension items listed, they may be of interest only to UMAnitarians, or they might have wider application as optional or required portions of a core OAuth 2.0 spec. We're not trying to prejudice this outcome, just provide useful information for making the decision in the wider community. So, with all that said... Here is the conception of UMA's use of the WRAP paradigm as conceived in the proposal. 1. Currently, WRAP says nothing about how a Protected Resource and an Authorization Server "meet" and figure out how to work together. UMA has reason to make the user's choice of authorization management (AM) services and hosts of their resources be dynamic and flexible -- that's why it's called "user-managed access" -- so the proposal suggests a special way to use (an embedded instance of one of the user delegation profiles of) WRAP to introduce them, as a "step 1". (The token thus acquired by the host in this step plays a role in "step 3".) 2a. Another of UMA's goals is to allow authorizing users (roughly, Resource Owners) to make demands of other parties before granting them access rather than just permissioning the connection "silently". The mechanism for making these demands is to require the requesting side to provide claims (yes, in the identity claims sense) and even to make this process have legal enforceability consequences where possible. Thus, the proposal suggests an extended getting-a-token phase in a "step 2" that adds a new third option to the two usual WRAP options (successful access token response and unsuccessful access token response): a claims-required response. 2b. Due to our analysis of the legal (cough) and UX dimensions of the UMA proposition, we've discovered that it's useful to separate requesting parties (the legally responsible party "behind" the requester/Client) into legal persons vs. natural persons. This is a way in which UMA deviates from OAuth and WRAP entirely, in that we're figuring out how to do "person-to-person sharing" (Alice permissions Bob to subscribe to a hosted calendar of hers) along with "person-to-service sharing" (Alice permissions ECommerce.com to grab her current shipping address from her personal datastore). The current thinking is that it's a matter of putting the requester into a user-delegated flow vs. an autonomous-client flow as part of getting a token in step 2. 2c. Currently, WRAP doesn't say anything about how to fill the scope parameter value. In this context, an obvious optimization is the "all the photos that happen to be in this folder" authorization scenario. So we went ahead and proposed a simple JSON-based format for describing both simple access scope and basic wildcarded access scope. 3. The means by which a host interprets an incoming access token is not currently specified in WRAP. Unfortunately, UMA needs to know. :-) There seem to be two options: validating it locally or offloading validation. To avoid putting a signature validation burden on the host, we have proposed a strawman where the host can simply ask the AM to do the validation for it. (A personal observation: The local/offload choice all depends on various scale and loose coupling factors, but this is appealing for lots of reasons. It not only views the Authorization Server as an STS performing a typical token validation function, but pretty closely matches the classic access management paradigm where the policy enforcement point asks the centralized policy decision point what to do. And other useful info could also ride over this back channel, either in extensions or -- as the need arises -- in core OAuth.) n. Several people at the UMA table continue to be concerned about the overall risks in using the WRAP paradigm for controlling access to various kinds of sensitive information in various ways. It may not be acceptable in some UMA use cases, e.g., to use replayable tokens. As I promised on the call, I'll work with the UMA group to research this issue as precisely as possible in preparation for Anaheim, ideally including specific guidance from those who have submitted the most sensitive UMA scenarios or have the biggest concerns. Eve On 4 Mar 2010, at 11:01 AM, Eve Maler wrote: > Folks may be interested to see the following experiment being performed in > the UMA group: > > http://kantarainitiative.org/confluence/display/~xmlg...@idp.protectnetwork.org/Proposal+for+UMA+1.0+Core+Protocol > > This is a proposal for a spec that uses a WRAP-friendly approach to solving > our use cases. Please note the final comments in today's UMA telecon minutes > for cautions about additional requirements we have: > > http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2010-03-04 > > Eve > > Eve Maler > e...@xmlgrrl.com > http://www.xmlgrrl.com/blog > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
