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

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 21 Jan 2011 18:09:30 -0700

http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02

New version includes the following changes:

   o  Added body-hash support.
   o  Updated OAuth 2.0 reference to -12 and added token type registration template.
   o  Removed error and error URI attributes (codes were just a duplication of the HTTP status codes).

Feedback would be greatly appreciated.

EHL

---

From: Michael D Adams <[email-masked]>
Date: Fri, 21 Jan 2011 17:35:58 -0800

> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02

That link redirects me to -01

$ curl -I 'http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02'
HTTP/1.1 302 Found
Date: Sat, 22 Jan 2011 01:35:45 GMT
Server: Apache/2.2.16 (Debian)
Location: http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-01
Content-Type: text/html; charset=US-ASCII

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 21 Jan 2011 18:56:43 -0700

The tools are slow. Just try again.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Michael D Adams
> Sent: Friday, January 21, 2011 5:36 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02
>

---

From: Skylar Woodward <[email-masked]>
Date: Thu, 27 Jan 2011 12:51:30 +0100

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.

- 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.

- 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.

- 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.

Of all these points, I'm most interested in feedback from others on the use of client_secret+token_secret as option for the signature key.

skylar

On Jan 22, 2011, at 2:09 AM, Eran Hammer-Lahav wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth