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
