I'm sorry that I'm late on this but for what it's worth:
Server Response Format: I prefer A (form-encoded only). It's the simplest
solution that requires the least amount of client-side technology. JSON is
too complex a spec for simply encoding a set of flat key-value parameters
when where is already a well-established way to do this today in the HTTP
spec. My second preference is B (JSON only).
Client authentication: OAuth 1.0a was fine with authentication explicitly
expressed in the headers and I think 2.0 should stay the same.
More importantly, however -- I think that the spec should try to keep
things simple rather than offer multiple choice on many different aspects
of the implementation. The world is full of complicated specs and it's
always easier to keep adding options than to choose one of several
alternatives. Better to pick one that works well enough for everyone
rather than to keep adding choices to satisfy special cases that may or
may not be important in the future.
So in either of those cases, if Eran or whoemever is so empowered were to
choose, for example, "JSON only" and "HTTP basic only," then I would
support both choices over a set of options even though in both cases
neither is my first choice.
greg
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Eran Hammer-Lahav
Sent: Sunday, May 09, 2010 5:07 PM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
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
---
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)
_______________________________________________
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
