Re: [OAUTH-WG] MAC Token Comments

Eran Hammer-Lahav <> Sat, 19 November 2011 17:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ADF1B21F86FF for <>; Sat, 19 Nov 2011 09:22:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.544
X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I267jnEH+NH1 for <>; Sat, 19 Nov 2011 09:22:14 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 37A8B21F8663 for <>; Sat, 19 Nov 2011 09:22:14 -0800 (PST)
Received: (qmail 3002 invoked from network); 19 Nov 2011 17:22:13 -0000
Received: from unknown (HELO ( by with SMTP; 19 Nov 2011 17:22:13 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([]) with mapi; Sat, 19 Nov 2011 10:22:14 -0700
From: Eran Hammer-Lahav <>
To: Justin Richer <>, "" <>
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" <>
Subject: Re: [OAUTH-WG] MAC Token Comments
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 19 Nov 2011 17:22:14 -0000


> -----Original Message-----
> From: [] On Behalf
> Of Justin Richer
> Sent: Friday, August 12, 2011 11:44 AM
> To:
> 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."

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