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 > > 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
