Subject: [OAUTH-WG] OAuth Request JSON Encoding

From: Justin Richer <[email-masked]>
Date: Thu, 9 Jul 2020 15:29:27 -0400

In the ten years since OAuth started, we’ve seen a huge shift away from form encoding to JSON encoding for sending data to a server. And yet, OAuth is stuck with form encoding. So I thought, why can’t we change that?

I put together a quick proposal for how this would work.

https://www.ietf.org/id/draft-richer-oauth-json-request-00.html <https://www.ietf.org/id/draft-richer-oauth-json-request-00.html>

The basic idea is that you take the map of form inputs and make it into a JSON object. For some fields, like scope and authorization_details, you can define a JSON-specific encoding to make use of object and array structures native to JSON. You also don’t have to url-encode values inside the JSON strings. 

Caveat, I haven’t tried implementing this yet, but I think it’s not likely to be that difficult for either the client or server side of things. At worst it seems like it’d be a pretty simple middleware function. Functionality can be detected at the AS by the content negotiation in HTTP (client sends content-type of JSON), and can be advertised as an option in the metadata (or in an OPTIONS call to the token endpoint, to be more HTTP-friendly).

 — Justin

---

From: Tom Jones <[email-masked]>
Date: Mon, 13 Jul 2020 08:19:55 -0700

What, exactly is json encoding? It sounds like a python or java method.
Afaik json can be encoded in utf 8 16 or 32. But form encoding is limited
to ascii or even to base64url
. Is that the point. Will GNAP specify one encoding?

thx ..Tom (mobile)

On Thu, Jul 9, 2020, 12:29 PM Justin Richer <[email-masked]> wrote:

> In the ten years since OAuth started, we’ve seen a huge shift away from
> form encoding to JSON encoding for sending data to a server. And yet, OAuth
> is stuck with form encoding. So I thought, why can’t we change that?
>
> https://www.ietf.org/id/draft-richer-oauth-json-request-00.html
>
> The basic idea is that you take the map of form inputs and make it into a
> JSON object. For some fields, like scope and authorization_details, you can
> define a JSON-specific encoding to make use of object and array structures
> native to JSON. You also don’t have to url-encode values inside the JSON
> strings.
>
> Caveat, I haven’t tried implementing this yet, but I think it’s not likely
> to be that difficult for either the client or server side of things. At
> worst it seems like it’d be a pretty simple middleware function.
> Functionality can be detected at the AS by the content negotiation in HTTP
> (client sends content-type of JSON), and can be advertised as an option in
> the metadata (or in an OPTIONS call to the token endpoint, to be more
> HTTP-friendly).
>
>  — Justin
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 13 Jul 2020 17:32:51 +0200

On 2020-07-13, at 17:19, Tom Jones <[email-masked]> wrote:
> 
> What, exactly is json encoding?

JSON is defined in RFC 8259.
The term “encoding” is ambiguous here, it could be used for the encoding of a JSON text (which employs UTF-8) or the representation of an application data model using the JSON generic data model.

> It sounds like a python or java method.

Many languages and platforms support JSON.

> Afaik json can be encoded in utf 8 16 or 32.

Early definitions of JSON said so, even though that practically never happened in interchange.  RFC 8259 supports UTF-8 encoding only.

Grüße, Carsten

---

From: Filip Skokan <[email-masked]>
Date: Mon, 13 Jul 2020 17:47:44 +0200

Hello Justin, 

Your ID changes both how a client sends a request as well as how the, already a json, token response is structured (as far as i can see it changes scope from a space separated value to an array). 

The response morphing will be confusing to clients.

I don’t think there’s much to explore here, apart from authorization_details param sent to the token endpoint form encoded i don’t find much unnatural about the existing oauth interface. 

Filip

Odesláno z iPhonu

> 9. 7. 2020 v 21:29, Justin Richer <[email-masked]>:
> 
>

---

From: Justin Richer <[email-masked]>
Date: Mon, 13 Jul 2020 12:09:47 -0400

The intent was to only affect the request, not the response, though I can see the confusion that would arise in having those be at odds with each other. 

 — Justin

> On Jul 13, 2020, at 11:47 AM, Filip Skokan <[email-masked]> wrote:
> 
> Hello Justin, 
>

---

From: Tom Jones <[email-masked]>
Date: Mon, 13 Jul 2020 09:10:31 -0700

ahh - thx - so that explains why RFC 6749 OAuth 2.0 is ambiguous on the
topic. I suspect that means that GNAP will take a dependency on 8259,
Peace ..tom

On Mon, Jul 13, 2020 at 8:34 AM Carsten Bormann <[email-masked]> wrote:

> The term “encoding” is ambiguous here, it could be used for the encoding
> of a JSON text (which employs UTF-8) or the representation of an
> application data model using the JSON generic data model.
>
> Early definitions of JSON said so, even though that practically never
> happened in interchange.  RFC 8259 supports UTF-8 encoding only.
>
> Grüße, Carsten
>
>

---

From: Filip Skokan <[email-masked]>
Date: Mon, 13 Jul 2020 19:00:55 +0200

Apologies Justin, i read it in a rush. 

But, even more so after your clarification, if the ID means responses are unmodified it’s just confusing - as you say - at odds with each other, since i’d send in scope as array and get it back as a string from the token response. 

Odesláno z iPhonu

> 13. 7. 2020 v 18:09, Justin Richer <[email-masked]>:
>

---

From: Justin Richer <[email-masked]>
Date: Mon, 13 Jul 2020 15:18:35 -0400

It’s all good, I wrote it relatively quickly and I haven’t actually built it out. The idea struck me this week, as I was working on something for a client, that it would be a fairly simple translation from the map structure of form encoding to a JSON-based map structure for the same key-value pairs, and you could skip all the form encoding for the values and occasionally make use of a more native encoding method for some values like scope.

For aligning request and response, it could say that there’s an alternate response encoding as well but only if the client uses this request format. That’s a lot for the AS to track, but it would let clients speak only one dialect natively. It might be squirrely but then again it might just make sense for the AS to track it all.

Ultimately it’s a back-patch because all OAuth values are going to have to define form encodings and an extension couldn’t take full advantage of this unless it was written to be JSON-only, which would be a bit weird and limiting. For example, I didn’t look at applying it to PAR because the PAR values are defined in terms of query parameters already, and are therefore beholden to those rules and not the token endpoint rules. It might work there, too, but probably not even as smoothly as this!

I appreciate the read through and the comments! I’d be curious if there’s any energy in the group to pick it up.

 — Justin

> On Jul 13, 2020, at 1:00 PM, Filip Skokan <[email-masked]> wrote:
> 
>>> On Jul 13, 2020, at 11:47 AM, Filip Skokan <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hello Justin, 
>>> 
>>>> 9. 7. 2020 v 21:29, Justin Richer <[email-masked] <mailto:[email-masked]>>:
>>>> 
>>>> 
>>>> [email-masked] <mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>