Hey John,
On 4/15/10 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?
People like short and general parameter names (see link relation types
registry discussion). If you make it easy for them to register these short
names, they usually do.
>>
>> 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?
Yes. The spec will define a set of reserved parameter names (no one is
allowed to change these), and rules for using new parameters without a
period in the name (common extension) and parameter with a period (vendor
specific extensions).
There is nothing I can do about people who do not read the spec and choose
to implement it differently.
>> 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)?
Any parameter not defined by the core spec.
EHL
> - 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
