Thanks Eve, comments inserted ... On 2010-03-04, at 12:51 PM, Eve Maler wrote:
> 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. This was explicitly out of scope for WRAP. There are scale and privacy advantages to the PR and AR not meeting. The PR needs to trust the AR the issued the Access Token (and of course be able to verify the Access Token was issued by the AR), but the AR does NOT need to be aware of the PR. In this way, WRAP > 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".) Interesting use of WRAP. I don't see a hole in WRAP for you to do this. Is there some functionality missing? > > 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. I can see it being useful in a standard return parameter that can contain an value undefined by WRAP (similar to the scope parameter), that is used by the AS to communicate to the Client what else the Client needs to be granted an Access Token. Is this what you are asking for? > > 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. Is there something missing in WRAP to do this? > > 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. Different scenarios will require different scope values. We thought it useful to define the parameter so that it would be easier library providers and specs like UMA to define the value without also having to define the parameter. > > 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.) When developing WRAP, we envisioned that the PR would verify and interpret locally. > > 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. Posting what you find to the list prior to Anaheim would be useful for the rest of us to have a chance to digest and then we can discuss in detail at Anaheim. -- Dick _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
