On Thu, Apr 15, 2010 at 12:27 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote:
>
> On 4/15/10 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?
>
> I really think we shouldn't. :-)
>
> Requests are longer for no reason.
Not much longer, the number of parameters is small. Why is this a problem?
> You need to show how a prefix actually
> helps. Otherwise, it is the same as adding an 'protocol=oauth' to every
> request just for fun.
I think I did.
>> Not having such a prefix will lead to collisions with query parameter
>> on the authz server endpoints
>
> Having a prefix without an extension policy does not help at all to prevent
> collisions. This is a false expectation. There is no difference between
> saying 'don't add new parameters with the oauth_ prefix' or 'don't add new
> parameters with names already used by this specification'.
I agree this is not perfect, but that does not mean it does not help.
It is one thing to say to implementors to stay away from parameters
stating with "oauth_" and a totally different thing to say stay away
from "scope", "mode", "callback", ... and whatever we will add to
newer versions to the spec. All these are very common words and
chances for collision are high.
>> 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.
>
> Callback parameters are a bit different. We still need to solve the issue of
> how to allow client state in callbacks (state parameter or free-for-all).
> But here too, a prefix does not solve collisions. You have the same
> extension policy issue.
State aside, the callback may want to have query parameters, even in
the registered version. Why disallow that?
> A prefix just "solves" potential collision between the core spec and other
> specs using the same parameter names. It does not help how to avoid
> collisions between extensions and vendors. OAuth 1.0a had a prefix and then
> we spent weeks discussion who else can define oauth_ parameters. It just
> moved the problem somewhere else - the extension policy.
Not trying to solve the extension issue at all.
Marius
>
>> 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
