I misspoke. OAuth Core 1.0 5.2 implies that servers must support all three methods since clients will send parameters using one of three methods. The EC edition clarifies this a bit and says that clients must use one (and only one) of the three methods unless an extension is used.
Section 4.2 does not list parameter deliver methods as part of the documentation, which reinforces the fact that servers are expected to support all three methods. I think the confusion comes from the OAuth discovery spec which made this optional on the server side. So no, to be compliant with the spec as written today, servers must support all three methods and client should use the first method they can in the list (to apply the preference indicated). I think moving forward servers should be required to support the Authorization header, not sure about the other two. EHL On 3/16/09 12:32 PM, "Martin Atkins" <[email protected]> wrote: Thanks. That seems to agree with my interpretation. It would be useful to be explicit in the specification that the server is not required to accept all three. Eran Hammer-Lahav wrote: > OAuth is silent on which method you should use, other than to express > some weak preference. The server needs to communicate which methods it > supports and the client must use those. > > EHL > > > On 3/16/09 11:52 AM, "Martin Atkins" <[email protected]> wrote: > > > > > In section 5.2 of OAuth Core 1.0, and in section 3.4 of Eran's "Editor's > Cut" draft, three different mechanisms are listed for encoding request > parameters, implying that support for all three is required. However, > it's not clear to me who this requirement applies to and how it applies. > > Here are my two interpretations: > > * SPs must accept all three mechanisms, allowing the client to choose > which to use in a given request. > > * SPs document which of these may be used on their endpoints; client > libraries should support all three, but clients must be written to use > only a mechanism allowed in the SP documentation. > > Reading between the lines, I'm guessing that the motivation for > supporting these three different approaches is that some server > frameworks make it difficult for server-side apps to read the > "Authorization" header on incoming requests. In particular, I don't > believe it's made available to CGI programs running under Apache. > > With that assumption in mind, it seems that the second interepretation > above must be the correct one, since that will allow a service provider > that is unable to support the Authorization header to require clients to > use one of the other mechanisms. > > Does this seem like a reasonable interpretation? And assuming that it > is, is it compliant to make a server implementation that *only* accepts > arguments in the Authorization header? > > (My reason for doing this is that I wish to support OAuth alongside > Basic in my implementation, so requests without an Authorization header > would return 401 Unauthorized containing the WWW-Authenticate > challenges.) > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
