It should be noted that it won't continue to be able to set the Authorization-header via JavaScript, so JS-clients will not be able to support Authorization-headers in the future..
See the Editors Draft for reference (bullet point #5) http://dev.w3.org/2006/webapi/XMLHttpRequest/Overview.html#setrequestheader Safari 4 Beta still allows the header to be set, but WebKit Nightly denies the header. This coincidentally broke my current application horribly because it required the ability to set the Authorization-header. I'll now have to rewrite the API-calling code to use OAuth transmitted over one of the two remaining ways.. Someone maybe want to contact W3C / WhatWG that the Authorization- header is Nice To Have as a allowed header.. -Morten On Mar 16, 2009, at 8:54 PM, Eran Hammer-Lahav wrote: > 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 -~----------~----~----~----~------~----~------~--~---
