Parameters that can be JSON lists rather than space separated sting s probably should be unless there is some compelling reason as in scopes to keep them space separated. May as well save unnecessary string parsing. John B.
On 2013-02-15, at 11:58 AM, Justin Richer <jric...@mitre.org> wrote: > In case people missed a subtle change, I wanted to bring it to the group's > attention: > > The metadata parameters "request_uri" and "grant_type" are now JSON lists > instead of space-separated lists of strings. The "scope" parameter remains a > space-separated string, taking its definition from RFC6749 section 3.3. This > is due to a conversation that came up around the use of the "scope" parameter > in the introspection endpoint, and folks generally thought that the > definitions should match. > > If we do JSON input (which there seems to be overwhelming support for), then > I believe we should at the very least split up lists that are lists instead > of forcing clients and servers to do string parsing. > > -- Justin > > On 02/11/2013 04:14 PM, Justin Richer wrote: >> Draft -05 of OAuth Dynamic Client Registration [1] switched from a >> form-encoded input that had been used by drafts -01 through -04 to a JSON >> encoded input that was used originally in -00. Note that all versions keep >> JSON-encoded output from all operations. >> >> Pro: >> - JSON gives us a rich data structure so that things such as lists, numbers, >> nulls, and objects can be represented natively >> - Allows for parallelism between the input to the endpoint and output from >> the endpoint, reducing possible translation errors between the two >> - JSON specifies UTF8 encoding for all strings, forms may have many >> different encodings >> - JSON has minimal character escaping required for most strings, forms >> require escaping for common characters such as space, slash, comma, etc. >> >> Con: >> - the rest of OAuth is form-in/JSON-out >> - nothing else in OAuth requires the Client to create a JSON object, merely >> to parse one >> - form-in/JSON-out is a very widely established pattern on the web today >> - Client information (client_name, client_id, etc.) is conflated with access >> information (registration_access_token, _links, expires_at, etc.) in root >> level of the same JSON object, leaving the client to decide what needs to >> (can?) be sent back to the server for update operations. >> >> >> Alternatives include any number of data encoding schemes, including form >> (like the old drafts), XML, ASN.1, etc. >> >> >> -- Justin >> >> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05 >> _______________________________________________ >> 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
