Re: [OAUTH-WG] OAuth Request JSON Encoding

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 <jricher@mit.edu>:
> 
> 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 <panva.ip@gmail.com> wrote:
>>> 
>>> 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 <jricher@mit.edu>:
>>> 
>>> 
>>> 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
>>> 
>>> 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
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
> 