On Sun, May 9, 2010 at 3:06 PM, Eran Hammer-Lahav <[email protected]>wrote:
> DEADLINE: 5/13 > > I would like to publish one more draft before our interim meeting in two > weeks (5/20). Below are two open issues we have on the list. Please reply > with your preference (or additional solutions) to each item. Issues with > consensus will be incorporated into the next draft. Those without will be > discussed at the meeting. > > EHL > > --- > > 1. Server Response Format > > After extensive debate, we have a large group in favor of using JSON as the > only response format (current draft). We also have a smaller group but with > stronger feelings on the subject that JSON adds complexity with no obvious > value. > > A. Form-encoded only (original draft) > B. JSON only (current draft) > C. JSON as default with form-encoded and XML available with an optional > request parameter > A, with both JSON and XML support via an optional extension. I'd prefer to keep the core spec as clean as possible, and I think form encoding does that. > --- > > 2. Client Authentication (in flows) > > How should the client authenticate when making token requests? The current > draft defines special request parameters for sending client credentials. > Some have argued that this is not the correct way, and that the client > should be using existing HTTP authentication schemes to accomplish that such > as Basic. > > A. Client authenticates by sending its credentials using special parameters > (current draft) > B. Client authenticated by using HTTP Basic (or other schemes supported by > the server such as Digest) > B, if possible. (I'm fairly convinced it is possible, but I'm not 100% sure yet.) > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
