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 -~----------~----~----~----~------~----~------~--~---
