On 2010-03-09, at 7:05 AM, Eve Maler wrote: > > 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.)
Thanks. Will add to list of edits. > 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). Understood. We could add to the spec that the validation could happen at a service instead of locally. -- Dick _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
