When replacing the placeholders with actual values, how do you know what encoding should be used? Does URL encoding work in all cases?
Marius On Fri, Apr 16, 2010 at 7:33 AM, Manger, James H <[email protected]> wrote: > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
