Subject: [OAUTH-WG] Feedback on draft-hammer-http-token-auth-01

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 13 Feb 2010 23:42:15 +0100

Hi,

I have been involved in establishing token-based security in a 
large-scale environment with central identity management services and 
various web services relying on tokens for user authentication and 
authorization. We also tried to adopt OAuth 1.0a. Based on my 
experiences, I want to give you some feedback to 
draft-hammer-http-token-auth-01 and ask some questions.

* Generally, I highly welcome the idea to strictly distinguish token 
issuance and token usage. The design decision not to use any 
consumer-related data (key, secret) in the "Token" scheme is a logical 
consequence. Our attempt to adopt OAuth 1.0a was hindered by the fact 
that the signature calculation required the consumer secret. But in 
environements with central identity management, neiter user nor consumer 
credentials shall be known to the services. So the new proposal is a 
step in the right direction to support such deployments.

* §5.1 "The token identifier can be an opaque string or use a 
well-defined internal structure." Does the proposal really intend to 
pass token identifiers (== handles?) only? I would expect the option to 
pass complete tokens in the authorization header from client to server. 
In that way, no further communication is required between server and 
security systems.

* How do you envision token service discovery? IMHO, a client performing 
an unauthorized resource request should be given a link to the token 
service a server trusts along with the 401 response. Or shall YADIS/XRDS 
be employed for that purpose and how?

* From my point of view, deployments with different token types (SAML, 
Kerberos, SWT, ...) would benefit if the protocol explicitely supports 
token format descriptions. In the WWW-Authenticate-Header the server 
could publish the formats it supports. e.g.

HTTP/1.1 401 Unauthorized
      WWW-Authenticate: Token realm="http://example.com/",
                              format="saml20-base64 krb5-base64 swt"
                              coverage="base base+body-sha-256",
                              timestamp="137131190"

The client does not need (and shouldn't be) aware of the meaning of the 
different formats but it could pass this information with the requests 
to the service issuing the required token. The token service in turn 
would denote the token format as part of the response parameter. The 
client would (again uninterpreted) pass this information with the 
authorized resource requests and therewith gives the receiver a hint how 
to handle the token.

    GET /resource/1 HTTP/1.1
      Host: example.com
      Authorization: Token token="h480djs93hd8",
                           format="swt"
                           coverage="base",
                           timestamp="137131200",
                           nonce="dj83hs9s",
                           auth="djosJKDKJSD8743243/jdk33klY="

* The protocol supports authentication of message originator, replay 
detection, and message integrity protection as an alternative to 
transport-layer security. But, why don't you include message encryption? 
In this way, one could abandon on HTTPS even if data privacy or 
confidentiality is an issue. The token secret could be employed for that 
purpose. A good blueprint could be Kerberos-based message-layer security.

regards,
Torsten.