I thought we already settled this (though am having a hard time
finding the specific thread). Either we spec for interop or for
vendors being able to twist the spec in their own ways. I vote for
interop. :)
On Thu, Apr 15, 2010 at 12:15 PM, Marius Scurtescu
<mscurte...@google.com> wrote:
> I really think we should keep a standard parameter prefix like
> "oauth_". What are the issue with having a prefix?
>
> Not having such a prefix will lead to collisions with query parameter
> on the authz server endpoints or on the callback URL. Even if state is
> not passed with additional parameters on callbacks. This also leads to
> adding further limitations on these URLs, by not allowing query
> parameters.
>
> Marius
>
>
>
> On Thu, Apr 15, 2010 at 12:08 PM, John Kemp <j...@jkemp.net> wrote:
>> Hello,
>>
>> On Apr 15, 2010, at 2:27 PM, Eran Hammer-Lahav wrote:
>>
>>> OAuth 2.0 flows use a single authorization endpoint (with 'type' parameter).
>>> This endpoint is OAuth-specific but must allow for extension parameters
>>> (standard or vendor-specific).
>>>
>>> The issue is how to best allow for extensions defining new parameters. The
>>> danger is common parameter names ('scope', 'language', 'permission') being
>>> used differently by different vendors, creating interop issues with
>>> libraries.
>>
>> If the OAuth specification defines the name for a parameter, and people
>> claim to implement the specification, they must use those parameter names
>> according to the specified usage. In other words, implementations of OAuth
>> should all do the same thing, and use the same names for the OAuth-specific
>> parameters. But, deployments of OAuth will use OAuth implementations and
>> possibly have additional requirements (such as passing other query string
>> parameters which may collide with the OAuth ones). And particular OAuth
>> vendors may add other extension parameters (agreed between particular
>> implementations but not perhaps within the entire community) to the query
>> string. All of that might be covered by "conformance to the specification" -
>> conformant implementations MUST not define parameters with names that clash
>> with the agreed OAuth names.
>>
>>>
>>> Prefix alone (for the core or extensions) does not solve the problem since
>>> extensions still suffer from potential namespace collision.
>>
>> Right. You cannot solve this problem. The danger is for those who don't read
>> the spec. (because they don't have to - they are buying a product, or using
>> a library).
>>
>>> 'oauth_' prefix
>>> makes all the parameter names longer, but doesn't add real value - defining
>>> new parameters, with or without the 'oauth_' prefix is still the same
>>> problem.
>>>
>>> The typical solution is to define an extension policy, using a registry or
>>> domain-namespace for new names.
>>>
>>> Proposal:
>>>
>>> Plain parameter names (names without '.' character) require registration
>>> (IANA registry with a published specification). This will encourage people
>>> to share their parameters and improve interop beyond the core protocol
>>> parameters.
>>
>> It will - how?
>>
>>>
>>> Vendor specific names will require a prefix using either registered vendor
>>> names (e.g. 'google', 'fb', 'yahoo').
>>
>> How will you *require* this - will there be a statement to that effect in
>> the specification - "conformant implementations MUST NOT define query
>> parameters that clash withe names int he OAuth registry "? What will you do
>> about deployments which include an OAuth library and do not know anything at
>> all about the OAuth requirements?
>>
>>> Alternatively, use the same extension
>>> policy as OpenID where extensions use any prefix and include a prefix URI
>>> identifier (e.g.
>>> http://example.com?etx.language=en&ns:ext=http://example.com/spec1).
>>>
>>
>> What do you consider an "extension" for this purpose (some parameter agreed
>> on by two or more conforming OAuth implementations)?
>>
>> - johnk
>>
>>> EHL
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
