On 2010-03-05, at 6:57 AM, Eve Maler wrote: > More below... > > On 4 Mar 2010, at 5:43 PM, Dick Hardt wrote: > >> 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 > > (Unfinished sentence?)
D'oh ... In this way WRAP is a claims based model. > > As noted above, it's fine for this to be out of scope for WRAP itself, but > it's in UMA's scope. > >> >>> 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? > > I don't understand the comment/question. Are you suggesting the WRAP pattern > (same as the three-legged OAuth pattern, which our current spec uses) can't > be applied to new use cases? It's pretty much a vanilla application of the > pattern. If it's not interesting as a generic solution and the problem space > is only UMA's, that's certainly okay with us. > I have no issue with WRAP being used in this way. I have not seen the pattern before. Perhaps once UMA is well known, others will want to use the same pattern and we can standardize it. >> >>> >>> 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? > > I'm not sure if we're technically "asking for" anything, just floating the > use case and pointing out that if we were to layer on WRAP as it's written > today, we'd have to extend the possible responses to token requests somehow. > Maybe a new parameter that flags a need for more info from the > client/requester is a good idea, but if it's just another undefined > parameter, I'd rather have a clean definition of an "extension point" for how > others could add parameters (or response types?). Lots of undefined fields > in a core spec doesn't seem interop-friendly. I don't see if as being widely used enough to standardize in the spec. Having UMA standardize it makes sense to me. As mentioned, standardizing the name similar to the wrap_scope parameter would make it easier for libraries. > >> >>> >>> 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? > > I'm not sure. If WRAP has the same assumption OAuth does about the "same > person" operating the client app as is logging into the protected > resource/AS/SP/server, then that's a conceptual difference. But I don't > think we saw any need (yet) for syntax changes in this area to support what > we want to do. > >> >>> >>> 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. > > I'd like to learn more about the other use cases. If common cases exist and > can be sedimented in for more universal support, that would be cool. (If > not, okay.) But along the lines of my earlier comment on extension points, > I'm not sure standardizing the field is valuable without standardizing any > values at all -- it may just confuse people about whether they're supposed to > stuff a bunch of different things into the one parameter if they seem vaguely > "scope"-related, or invent their own, or whatever. And then you have to > worry about how to stuff incompatible scope values into the same parameter > side by side for hybrid use cases that use multiple extensions. Etc. The feedback we received from library writers was standardizing the syntax was useful. There was little agreement on what the value of wrap_scope would be across implementors, but all agreed a standard parameter for scope was useful. We could add to the spec to clarify how the scope parameter should be used. It could make sense for UMA to standardize what the scope values are. > >> >>> >>> 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. > > It's probably worth mentioning that at least two UMA scenarios (health data, > and distributed social networking services with "data portability") envision > applications that frequently serve as both hosts/PRs and requesters/clients, > so if processing burdens are removed from the client but placed on the PR, it > may not help us all that much. This is an area where I hope others can chime > in with use cases and constraints to figure out which "scaling" options suits > them best. (And if WRAP/OAuth remains silent on the issue, it seems UMA > could still define this loop as an extension.) I'm confused by your comments. The Client does not do any processing of the Access Token. Would you clarify who you are trying to offload Access Token validation from and to? _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
