Am 08.04.2010 16:31, schrieb Eran Hammer-Lahav:
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.
Can you please give details on that? You removed query and post parameters for signed requests. Doesn't this cause adoption problems, too?
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
I didn't argue against passing tokens as parameters. I just said: "don't include it in the standard, please". I still don't see any benefit - just confusion.
Moreover as I already pointed out, query parameters are dangerous from a security standpoint. Do you really want to standardize something like that? Or do you want to improve internet security?
they allow existing browsers to deploy OAuth *today*.
I don't understand this. Would you please give examples? Browsers today natively support BASIC/DIGEST/SPNEGO with authorization headers, they could do this the same way for OAUTH.
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.
What does this mean with respect to my proposal? regards, Torsten.
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
