Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)

[Evan Gilbert <[e-mail]>]

On Wed, May 19, 2010 at 6:33 PM, Manger, James H <
[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>