While I agree that the spec would be much cleaner with only HTTP header support, and have tried that approach before, in practice it will cause significant adoption problems.
I rather add support for query and post parameters (we are really talking about a single parameter, oauth_token, outside the HTTP header), and in a few year deprecate it in OAuth 3.0. The benefit of these features is that they allow existing browsers to deploy OAuth *today*. As for the document structure, it is too early to tell. With OAuth 1.0a I ended shuffling the sections in draft -09... The spec has to tell a story. EHL On 4/8/10 1:54 AM, "Torsten Lodderstedt" <[email protected]> wrote: > > > Hi Eran, > > since you are re-working sections 5-7 now, I want to address some > general issues I see there. > > - What is the benefit of including "URI Query Parameter" and > "Form-Encoded Body Parameter" in the standard? I see OAuth as an HTTP > authentication scheme similar to BASIC or SPNEGO. All of these schemes > exclusively use Authorization headers for sending credentials from > clients to servers. That way, authorization is kept orthogonal from > the servers API. > Advantages: > + APIs can be combined with different authentication schemes > + Libraries can be plugged in and easily add authorization data > + no name clashes with API parameters > + can be combined with any HTTP method > > It's ok with me if someone wants to send tokens as Query/Body > Parameters. But then the token parameter becomes a part of the > resource servers API. Why standardizing that? > > From a security standpoint, sending tokens as query parameter is > problematic since their are many ways to leak them. Servers typically > log target URLs in default configurations, GET request URLs are stored > in browser caches and proxies. And what about Referer-Headers? > > When we adopted OAuth 1.0a, the fact that OAuth 1.0a supported three > different ways of sending tokens caused a lot of confusion. What type > is supported by what resource server? Do we need to support all of > them or a sub set? e.t.c. > > So IMHO removing 5.1.2 and 5.1.3 would make the standard much simpler > and easier to understand/implement/use. > > Moreover, it should save at least 2 pages. > > - I would like to suggest to change section ordering (5-7) in order to > facilitate readability. From my point of view, the major contribution > of the OAuth HTTP authentication scheme is the definition of the > Authorization headers syntax (and semantics). Why not putting this in > front? Further on, the natural counter part of the Authorization > header is the WWW-Authenticate header since it is used to advertise > important properties of the authentication scheme to clients. So I > would suggest to describe it afterwards. > > Based on this considerations, I would suggest the following structure > (just a sketch): > > 4 (was 7) Authorization Header > description of both variants > token only > token + signature > 5.2.1 Computing the signature > security considerations > e.g. implementations MUST support bearer tokens w/ HTTPS, resource > servers and clients SHOULD use it > 5 (was 6) WWW-Authenticate Header > > I'm willed to contribute a more elaborated proposal if you and the WG > agree with the direction I proposed. > > What do you think? > > regards, > Torsten. > > > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
