Re: [OAUTH-WG] Issue: Authorization endpoint parameter extension policy

[John Kemp <[e-mail]>]

On Apr 15, 2010, at 3:15 PM, Marius Scurtescu wrote:

> I really think we should keep a standard parameter prefix like
> "oauth_". What are the issue with having a prefix?

I think the downside is the extra bytes on the wire.

The upside is that this might prevent accidental collision with OAuth parameters by people who haven't read the spec. or looked at the registry. 

I don't think it solves all collision problems, which is probably why people don't see it as a high-value thing to do.

> 
> 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.

Having a prefix doesn't solve ALL collision possibilities. There is some limited utility in preventing accidental collision by people outside of the OAuth community. The question is whether that is worth the extra bytes. Or are there some other good arguments for or against?

I can see both points of view. Is a possible compromise to make a shorter prefix than 'oauth_' (how about 'oa_' - 3 bytes instead of 6)?

- johnk

> 
> Marius
> 
> 
> 
> On Thu, Apr 15, 2010 at 12:08 PM, John Kemp <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>