Thanks for your further feedback. Just a couple of comments back (eliding
other portions of the thread):
On 8 Mar 2010, at 2:21 PM, Dick Hardt wrote:
> On 2010-03-05, at 6:57 AM, Eve Maler wrote:
>>>>
>>>> 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.
It's a good idea to give guidance on how the scope parameter should be used.
That way, it will help avoid "abuse" of the parameter for other purposes, and
clashes if different deployments are using it in different ways. (I suspect
that the tradeoff here is making it (superficially?) appealing for implementers
vs. making it more interoperable for deployers.)
>
>>>> 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?
Right, the Client doesn't do this processing. However, if the point of making
tokens opaque to "the Client" is to save them trouble, I wanted to point out
that some of our use cases have the same overall application deploying a Client
along with also being a Protected Resource, and that it could be reasonable to
want to save such an app as much trouble as possible in the aggregate. WRAP
today assumes that "the Protected Resource" validates a signature locally.
However, this could be expensive (in the sense of requiring PKI
infrastructure). Another option is to have it offload validation to the
Authorization Server as a back-channel operation, which has its own pros and
cons. For now, in UMA we're thinking of defining the back-channel loop as an
extension (which could be completely opaque to the core protocol underneath).
Eve
Eve Maler
e...@xmlgrrl.com
http://www.xmlgrrl.com/blog
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
