A partial solution to colliding parameter names and long URIS would be to use
URI templates.
For instance, in a 401 response when a client app tries to access a protected
resource, instead of an authz URI, return a template for an authz URI. The
template would include OAuth field names in squiggly brackets, to be replaced
by the field’s value when building an actual authz URI. The template could also
be provided in documentation.
Example:
C<-S 401
WWW-Authenticate: OAuth
u=”http://as.com/{type}/{client_id}?cb={callback}&no_ui={immediate}&oe=utf-8”
There are a couple of benefits:
1. The parts of the template outside the {…} placeholders can be chosen however
the service wants. There is no worry about clashes between proprietary query
params (like “oe=utf=8” above) and OAuth fields. There is no need for the
restrictions on URI that are in the current draft.
2. The constructed URI will be shorter as it doesn’t have to include the OAuth
field names, just their values. The field names could include an oauth_ prefix
without affecting URI sizes. The template itself will be longer than a base
authz URI to which query params are added, but that is a less important issue.
3. It provides a little bit of discovery automatically. The field names that
appear in placeholders (or their absence) tell the client app which features
are (or are not) supported. For instance, the example above shows that the
service supports the “immediate” mode, otherwise it wouldn’t include the
{immediate} placeholder. This may be enough for most feature negotiation needs.
There are disadvantages:
-1. Templates are a more complicated than always using query parameters. Just
{name} adds a little complexity. A more flexible placeholder syntax being very
slowly speced by the W3C (eg with defaults) adds more complexity -- but doesn’t
have to be adopted here.
With this proposal the {callback} placeholder in the authz template would be
filled by a client with its own template, with a placeholder for the auth code.
A service could still introduce its own placeholder field that clashed with a
subsequent OAuth definition. I think that is less of a concern.
--
James Manger
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
