On 4/15/10 12:36 PM, "Marius Scurtescu" <mscurte...@google.com> wrote:
> 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?
It's longer for no reason.
>
>> 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.
Say it helps isn't proof, just an argument.
>
>>> 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.
So what happens when someone wants to add a language parameter? Do they call
is 'language' or 'oauth_language'? The prefix just doesn't solve anything
without a policy, and once you write a policy it is no longer needed.
>
>>> 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?
I don't think it should, but I am opposed to both random parameters and a
client state parameter. Either way, that's a different issue - let's try to
keep this focused on one issue at a time.
>
>> 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.
This is all about extensions (common or vendor specific)!
EHL
>
> 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
