Re: [OAUTH-WG] MAC Token Comments

Eran Hammer-Lahav <eran@hueniverse.com> Sat, 19 November 2011 17:22 UTC

From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Justin Richer <jricher@mitre.org>, "oauth@ietf.org" <oauth@ietf.org>
Date: Sat, 19 Nov 2011 10:22:00 -0700
Thread-Topic: [OAUTH-WG] MAC Token Comments
Thread-Index: AcxZH97PSmoCML6PTe2lWNeQSBH6LRNv2RMg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234526735EE00@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <1313174628.22073.135.camel@ground>
In-Reply-To: <1313174628.22073.135.camel@ground>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Anganes, Amanda L" <aanganes@mitre.org>
Subject: Re: [OAUTH-WG] MAC Token Comments
Precedence: list

Thanks.

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Justin Richer
> Sent: Friday, August 12, 2011 11:44 AM
> To: oauth@ietf.org
> Cc: Anganes, Amanda L
> Subject: [OAUTH-WG] MAC Token Comments
> 
> 2: MAC Key: "The server MUST NOT reissue a previously issued MAC key and
> MAC key identifier combination."

Ok.
 
> 3: I would still like to see a binding for post body and url parameters.
> This could be as simple as defining a set of parameter names for everything
> used in the auth header, but I'm still given the impression that this has been
> deemed outside the scope of the MAC token. Our use case is to pass around
> signed URLs between servers with all query parameters protected by the
> signature, which we use 2-legged OAuth 1.0 for today. We can try to get
> language for this together if there's enough draw for it, but I haven't been
> hearing that from other folks yet so we might just try to draft an extension to
> the extension, instead.

I can see the value in this for signed redirections and callbacks. The problem, of course, is that once you mess with the request URI, it must be normalized which has been a significant source of friction in OAuth 1.0. If you have suggestions on how to add this functionality without introducing significant pain, we should discuss it.

> 5: This section's wording should be brought more in line with the descriptions
> of the OAuth protocol in both core and bearer, which in turn should actually
> be a bit closer together themselves. Seems like we need a succinct elevator
> pitch for "what is OAuth2" to drop into all of these locations (and other
> extension specs) -- anybody want to take a crack at distilling one from these
> three sources?

I just dropped the whole thing and kept a one line reference to OAuth 2.0. No need to explain it.

> 7.9: Grammar tweak: "Those designing additional methods should evaluate
> 	the compatibility of the normalized request string with their
> 	own security requirements."

Adding 'own' is superfluous.

EHL

[OAUTH-WG] MAC Token Comments Justin Richer
Re: [OAUTH-WG] MAC Token Comments William J. Mills
Re: [OAUTH-WG] MAC Token Comments William Mills
Re: [OAUTH-WG] MAC Token Comments Eran Hammer-Lahav