On Wed, May 19, 2010 at 6:33 PM, Manger, James H < james.h.man...@team.telstra.com> 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. > This is really problematic - All implementers will have to properly parse form fields *and* parse JSON (and Base64 decode to boot). - JavaScript clients are likely to have XSS holes. If clients don't execute something like this code (from gadgets.json<http://www.google.com/codesearch/p?hl=en#MSH8LMSqi38/trunk/features/core/json.js&q=io.js%20package:%22http://svn.apache.org/repos/asf/incubator/shindig/%22&d=2>), then they will be exposing themself to XSS. if (/^[\],:{}\s]*$/.test(text.replace(/\\["\\\/b-u]/g, '@'). replace(/"[^"\\\n\r]*"|true|false|null|-?\d+(?:\.\d*)?(?:[eE][+\-]?\d+)?/g, ']'). replace(/(?:^|:|,)(?:\s*\[)+/g, ''))) { return eval('(' + text + ')'); } - Developers will not be able to read source directly I'm a fan of Base64 encoding JSON for the purposes of creating a canonicalized string for signing. But this is not a good default transport. > > 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
