Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)

[DeWitt Clinton <[e-mail]>]

Response inline.

On Sun, May 9, 2010 at 5:17 PM, Dick Hardt <[e-mail]> wrote:

>
> On 2010-05-09, at 2:06 PM, Eran Hammer-Lahav 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
>
> I vote for B
>
> I would argue that form-encoded data adds complexity with no obvious value.
>
> *If* a JSON parser is not available, parsing the JSON that is returned is
> not that much different from parsing form-encoded data (remember that we are
> only using a very small subset of JSON)
>

I strongly disagree here.  The subset of JSON returned is "all valid JSON",
pure and simple.  Indeed, this was exactly what I was concerned about
before.

The server is *no* obligation to return something that can be parsed more
easily than full JSON.  If we don't make that crystal clear, then I worry
about no end to unsafe encoding and escaping issues down the road.

If the decision is to go with either option B or C, please do it only via
language that says that clients and servers both MUST be RFC 4627 compliant.
 I.e., a full JSON parser, or no JSON at all.

 -DeWitt


> More and more sites are returning both JSON and XML. Eventually everyone
> will see the light wrt. JSON ;-)
>
> >
> > ---
> >
> > 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)
>
> C. support both flows in the spec. An AS can decide what it wants to
> support. I would like to retain A as it may be challenging for some clients
> to use HTTP Basic, and easier for an AS to be always parsing parameters for
> each flow. I can see the advantages for some in using HTTP Basic.
>
> -- Dick
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>