Hello OAuthers,
I have a couple of comments on the "Token Access Auth" draft.
Initial impression (as Eran asked for): Yuck.
Now I will try to be a bit more constructive.
This authentication draft breaks the existing model of HTTP authentication too
much. It puts a bunch of very different mechanisms (bearer, shared secret, and
public key crypto) into a single "Token" scheme. We should, instead, have 1
scheme per mechanism, which is how HTTP auth has been designed.
I agree with Dan Winship [email 2009-12-09] that a meta-scheme ("Token") with
multiple sub-schemes will not work well with existing code architectures, which
offer extensibility based on schemes, not based on any other parts of a
WWW-Authenticate header.
It looks like 'realm' has been replaced by 'class'. This is working against the
existing model for HTTP auth, without a compelling reason.
A major rational for separating OAuth into Delegation and Authentication
documents was to recognize that they are logically independent. Authentication
needs an id (eg a token or user-id) and, optionally, a key -- but has no
dependence on delegation. Ideally, authentication specs would not mention
(OAuth-style) delegation at all.
The authentication draft is too strongly bound to delegation by trying to
package all authentication mechanisms that can be used with delegation under a
single scheme. This cannot work.
There will be other schemes: at lower layers, signature in the URI, signing
excluding the host name, using password-based key agreement, using multiple
round-trips, non-http protocols etc.
I am not against developing a mechanism to sign HTTP requests with a shared
secret. I think it is far less important for the OAuth working group than
specifying the delegation flows, and signalling.
My suggestions:
1. Define 1 very simple bearer scheme -- with no mention of delegation. Don't
include request signing in the same document.
Eg Authorization: ID a=<authorization-id>
(use "WRAP" and "wrap_access_token" as labels if you must)
2. Optionally, work on a mechanism to sign an HTTP request with a shared secret
without needing to exchange multiple messages with the server. Ensure the
mechanism can include 2 ids (authentication id and authorization id), and a
channel binding parameter.
Plus the main part of the WG work: on delegation flows; server-to-client
signalling about how to do delegation (eg providing URI to redirect user to);
stating which hosts and/or URIs a token (and optional secret) can be used at;
working out how periodically refreshing credentials fits architecturally.
--
James Manger
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
> Of Eran Hammer-Lahav
> Sent: Monday, 7 December 2009 7:28 PM
> To: OAuth WG ([email protected])
> Subject: [OAUTH-WG] Token Access Authentication Scheme Draft
>
> http://www.ietf.org/id/draft-hammer-http-token-auth-00.txt
>
> This draft is my first attempt at defining a general purpose
> authentication scheme to fulfill the WG requirement to produce a scheme
> suitable for 2-legged authentication. It also supports the OAuth 3-
> legged use cases as discussed on the list. This draft is in very early
> stage and has been submitted early to help better facilitate the
> conversation.
>
> It has been hard for us to discuss ideas without a concrete proposal. I
> hope this will help and motivate people to participate and provide
> feedback and new ideas. While there are many holes in the draft, it
> should be pretty easy to follow it.
>
> Major changes from OAuth 1.0:
>
> * New auth scheme with new parameter names
> * Signature base string replaced with normalized request string, and
> now does not require *any* encoding
> * Supports multiple token classes, authentication methods, and coverage
> scope
>
> Main feedback requested:
>
> * Initial impressions - this is particularly important to get. Does the
> draft make sense?
> * Functionality - does it include all the requested/required
> functionality?
> * Abstraction level - do the attributes provide the right level of
> configuration and choice?
>
> Please refrain from editorial feedback at this point (grammar, typos,
> etc.), but do provide structural feedback.
>
> I plan to push an updated version by Wed which will incorporate as much
> feedback as I can. I plan to ask for the WG to promote this draft to a
> WG item within 2 weeks.
>
> Thanks,
>
> EHL
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
