On Wed, May 19, 2010 at 6:33 PM, Manger, James H <[email protected]> wrote: > Marius, > >> Only direct responses are JSON, form/url encoded >> still has to be used: >> - direct requests >> - through browser requests >> - through browser responses >> - through browser fragment responses > > A better solution would be to change the last two (token info delivered in a > callback URIs) so a single parameter (in the query or fragment) holds all the > token info -- as a base64url-encoded JSON value.
I don't think the last one can be changed, parsing JSON in JavaScript can be tricky, Evan shows that in his reply. Also Evan points out that decoding Base64 is yet one more thing, much more complicated than percent decoding. > That is more complicated if you are only delivering a single quantity (eg > just an access_token). However, the difference diminishes as more and more > features are added: expires_in, scope, sites, refresh_token, > access_token_secret, realm, auth_scheme, whatever-comes-out-of-OpenID-Connect > etc. > > A single parameter for token info in callback URIs also reduces the risk of > clashing with client-specific parameters in callback URIs as things are added > in the future (eg the earlier debate about no oauth_ prefix). If we could have JSON for all requests and responses, then maybe that will help. But I guess that's too hackish. If not, then not sure. Requests have just as many parameters as responses. > It eliminates the need to force all semantics to fit in a flat key/value > model. This can only get harder as features are added, or extensions are > supported. The OpenID 2.0 approach of namespaces and parameter name prefixes > is not pretty. JSON does not solve this, but its structure helps. > > I wouldn't be surprised if, in some scenarios, the token info gets too big to > fit in a URI. In that case even the user-agent flow will need to make a > direct request to get the token info, which is more likely to be delivered as > JSON. OpenID and SAML have found they need this (eg artefact flows). In this case the user-agent flow becomes the web server flow, which does this already, no? Marius > > > Please consider this as an open issue for today's meeting: a single parameter > holding a base64url-encode JSON value for packaging token info in a callback > URI. > > -- > James Manger > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
