Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02

[Eran Hammer-Lahav <[e-mail]>]

> -----Original Message-----
> From: Skylar Woodward [mailto:[e-mail]]
> Sent: Thursday, January 27, 2011 3:52 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02
> 
> This is excellent. Thanks for pulling together a signature-based token spec.
> Some feedback:
> 
> - As I think was mentioned in a previous post, this spec is also attractive as
> method for asserting client credentials (eg, for access token requests). Your
> point is noted on substituting "client_id" as "token" though some language to
> recommend the general application of this field could be helpful for those
> reading the spec to draw the same conclusion. My personal preference
> might be the use of the word "assertion" over "token" if this is meant to be a
> general-purpose mechanism. Otherwise, people will naturally draw a strong
> correlation between related OAuth specs. I suppose this is the same sort of
> tension involved in keeping a more general name of MAC or assuming a
> more integral term, OAUTH_MAC. In any case, it feels like a "hack" to ask
> developers to put "client_id" into the "token" field, so I prefer multi-purpose
> names where multiple uses are intended.

The 'token' attribute was changed to 'id' and is now defined as the MAC key identifier.

> - When presenting an MAC token, it would be attractive if client credentials
> could also be captured in the assertion without relying on a separate
> assertion (imagine the confusion in two Authorization headers, MAC
> [token=client_id] and MAC [token=token]).  A simple solution (and one that
> preserves the same double-secret signature as OAuth 1.0) would be to
> require the value of "secret" (used as the signing key) to be a concatenation
> of client_secret and token_secret. I assume this kind of special instruction
> could be made by providers just as simply as the explanation of the use of
> "token" for client_id in client auth. I mention it to see if anyone sees conflicts
> or objections to this use, or if it is worth including the option in the spec in
> some manner.  If the spec is trying to remain more independent from the
> core OAuth spec, then I suppose that's a reason to both allow such alternate
> use and not address it. If the spec means to address common use cases and
> draw tight correlation between the two specs, then I see this as an positive
> clarification. Validating client identity on the presentation of tokens is a
> valuable ability. Using client credentials in the assertion allows for the
> signature to include an element that is potentially never sent over the wire
> or in a previous OAuth exchange.

The concept of including both the token credentials and client credentials in one request was explicitly thrown out of OAuth 2.0. It is one of the bad design choices in 1.0 and makes deployment at scale much harder. Do you have use cases for authenticating a single request with more than one set of credentials?
 
> - Using a body hash and making it optional is a great alternative to the OAuth
> 1.0a method incorporating content body params. Given the confusion that
> parameter ordering and sorting caused for 1.0a why not apply the same
> method for query-string parameters?  That is, normalize the query-string
> parameters, sort them, create a parameter hash, and include it in the
> assertion (optional).  This allows providers to not require this if they consider
> it to be unnecessary for security as well as a hurdle to message signing. In any
> case, I'd see both elements as either optional or required.

The only reason we normalize the request URI is that on many client and server platforms, the layer at which this is implemented does not have access to the raw request (both on the client and server). Calculating a MAC on the entire request URI is critical. Providers wishing to avoid it should not use query parameters.
 
> - As expressed, I had concerns over versioning of the format as any
> modification could introduce brittleness to the construction of the Signature
> Base String. Your preference seems to be to introduce MAC2 if
> incompatibility or confusion arises. Assuming everyone else is fine with that,
> it's an acceptable path forward.

Yep. I have no intention turning this too into a framework...
 
EHL