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 protected]> 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 <[email protected]>: >> >> >> 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 >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
