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 <jric...@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...@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 <jric...@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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
