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

[Marius Scurtescu <[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.

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
>