On Thu, Apr 15, 2010 at 12:22 PM, David Recordon <record...@gmail.com> wrote:
> 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. :)
Lost you. Where do I argue for twisting anything?
If vendors want to add custom parameters and avoid collisions they can
always create their own prefix.
Why exactly is a standard prefix a problem?
Marius
>
>
> 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
