One of the things that I found particularly useful with working with OAuth1 was the ability to perform an entire transaction through URL parameter manipulation. This is why I wholly support keeping the client id and secret fields in the client auth flow and the username and password fields in the username flow. I'm fine with supporting alternative ways to pass information around, with various headers or basic auth or what have you, but I don't want to lose the ability to GET and/or POST a bunch of form parameters to use OAuth. I don't want to have to dive any deeper into the HTTP stack than that.
With that in mind, I support keeping the format parameter, with an alternative expression of the same information being made available via the Accepts header for clients that want to do that instead. -- Justin On Thu, 2010-06-10 at 13:51 -0400, Marius Scurtescu wrote: > I am implementing an OAuth 2 library and the format parameter does not > feel right. > > If a client is using a library then the response format should be > totally transparent to the client. The library may have a setting if > the client wants to force a format for whatever reason, but individual > messages that the client builds and receives should not care about the > format. > > I think initially the Accept header was used. All current "format" > uses are in direct requests, so Accept could be used. > > To give a counter example, the User-Agent flow does not use "format" > and it always returns form-encoded in the fragment. There where > discussions to use JSON for this flow as well. Should we do that? If > yes, do we need "format"? Accept does not work in this case. > > I don't have a good suggestions, just wondering if anyone else run > into this issue. > > Marius > _______________________________________________ > 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
