Agreed with Eran. GET parameters certainly make exploring APIs easier.
On Thu, Apr 8, 2010 at 7:31 AM, Eran Hammer-Lahav <[email protected]> wrote: > 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 > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
