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. 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). 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). 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
