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.
Prefix alone (for the core or extensions) does not solve the problem since
extensions still suffer from potential namespace collision. '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.
Vendor specific names will require a prefix using either registered vendor
names (e.g. 'google', 'fb', 'yahoo'). 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).
EHL
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
