Even put it on the wiki (http://wiki.oauth.net/) if you don't want to deal with IETF formatting yet. Eran and I are happy to clean stuff up. :)
On Thu, Apr 15, 2010 at 12:51 PM, Eran Hammer-Lahav <[email protected]> wrote: > 1. Write it > 2. Comply with naming policy of new parameters* > 3. Publish and get feedback. > 4. Fix and repeat #3 as needed. > 5. Register new parameter name* > > :-) > > * Pending new parameter name policy > > For now just call it ‘scope’. > > EHL > > > On 4/15/10 12:38 PM, "Marius Scurtescu" <[email protected]> wrote: > > Sure. Do we have a mechanism to define extensions? > > Marius > > > > On Thu, Apr 15, 2010 at 12:26 PM, David Recordon <[email protected]> > wrote: >> Marius, why don't we write a one page spec which defines scope as an >> extension? We end up with agreement around if scope is a useful >> parameter and a simple parameter name for multiple vendors (because it >> is an extension). Since you seem to be advocating for including scope >> the most, would you mind trying to write out a few paragraphs? >> >> Thanks, >> --David >> >> >> On Thu, Apr 15, 2010 at 12:20 PM, Marius Scurtescu >> <[email protected]> wrote: >>> I still have not seen any arguments why scope structure is needed for >>> interop. Client and server side libraries do not need to understand >>> the scope, they just pass it around. Client and server code do need to >>> understand the scope, but we are not dealing with that. >>> >>> Yes, a scope parameter does not buy much, it only prevents each authz >>> server from inventing their own custom parameter. >>> >>> Marius >>> >>> >>> >>> On Thu, Apr 15, 2010 at 12:07 PM, Eran Hammer-Lahav <[email protected]> >>> wrote: >>>> WRAP includes a loosely defined scope parameter which allows for >>>> vendor-specific (and non-interoperable) use cases. This was requested by >>>> many working group members to be included in OAuth 2.0 with the argument >>>> that while it doesn't help interop, it makes using clients easier. >>>> >>>> The problem with a general purpose scope parameter that is completely >>>> undefined in structure is that it hurts interop more than it helps. It >>>> creates an expectation that values can be used across services, and it >>>> cannot be used without another spec defining its content and structure. >>>> Such >>>> as spec can simply define its own parameter. >>>> >>>> In addition, it is not clear what belongs in scope (list of resources, >>>> access type, duration of access, right to share data, rights to >>>> re-delegate). >>>> >>>> The rules should be that if a parameter cannot be used without another >>>> documentation, it should be defined in that other document. >>>> >>>> Proposal: Request proposals for a scope parameter definition that >>>> improve >>>> interop. Otherwise, keep the parameter out of the core spec. >>>> >>>> EHL >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
