Subject: [OAUTH-WG] Format of user-agent response parameters

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 16 Jan 2011 00:41:46 -0700

Why is the token returned in the fragment using form-encoding? This makes no sense. It should be a JSON string for the following reasons:

1.       All token responses should be the same, which will enable returning structured responses in the future as needed.

2.       Using fragments is specifically done to accommodate the user-agent environment, which means JavaScript. Why create extra work when JSON.parse() does it for you for free.

Returning the authorization code alone using form-encoded in the query still makes sense.

EHL

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 16 Jan 2011 20:01:39 +0100

+1 pro JSON

Am 16.01.2011 08:41, schrieb Eran Hammer-Lahav:
>
> Why is the token returned in the fragment using form-encoding? This 
> makes no sense. It should be a JSON string for the following reasons:
>
> 1.All token responses should be the same, which will enable returning 
> structured responses in the future as needed.
>
> 2.Using fragments is specifically done to accommodate the user-agent 
> environment, which means JavaScript. Why create extra work when 
> JSON.parse() does it for you for free.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 18 Jan 2011 15:02:51 -0800

On Sat, Jan 15, 2011 at 11:41 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> Why is the token returned in the fragment using form-encoding? This makes no
> sense. It should be a JSON string for the following reasons:
>
>
>
> 1.       All token responses should be the same, which will enable returning

They cannot all be the same. response_type=code has the response in
the query parameter, so I think we should stick with flat name/value
pairs.

> 2.       Using fragments is specifically done to accommodate the user-agent
> environment, which means JavaScript. Why create extra work when JSON.parse()
> does it for you for free.

The argument was that it is a somewhat more difficult to safely parse
JSON in JavaScript (maybe I remember wrong).

Unless we have a good reason to change to JSON, considering it is late
in the game, I think we should not make changes.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 18 Jan 2011 23:16:13 -0700

> -----Original Message-----
> From: Marius Scurtescu [mailto:[email-masked]]
> Sent: Tuesday, January 18, 2011 3:03 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Format of user-agent response parameters
> 
> > 1.       All token responses should be the same, which will enable
> > returning structured responses in the future as needed.
> 
> They cannot all be the same. response_type=code has the response in the
> query parameter, so I think we should stick with flat name/value pairs.

*Token* responses. When a code is returned alone, it is not a token response...

> 
> > 2.       Using fragments is specifically done to accommodate the
> > user-agent environment, which means JavaScript. Why create extra work
> > when JSON.parse() does it for you for free.
> 
> The argument was that it is a somewhat more difficult to safely parse JSON in
> JavaScript (maybe I remember wrong).

Now that most browsers support JSON.parse(), it is trivial. I think the point was the danger of using eval() which is very bad but common practice.
 
> Unless we have a good reason to change to JSON, considering it is late in the
> game, I think we should not make changes.

I agree this is a breaking change that has little immediate value. But long term it will provide a significant benefit in having a consistent token representation across the two formats. On the other hand, JSON will also require encoding since '{' and '"' are not allowed unescaped in the fragment.

Oh well.

EHL