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