Re: [OAUTH-WG] review

Hannes Tschofenig <> Fri, 11 January 2013 08:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C64C821F86D2 for <>; Fri, 11 Jan 2013 00:40:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.534
X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wGg3r1XO--5H for <>; Fri, 11 Jan 2013 00:40:50 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B378721F86CD for <>; Fri, 11 Jan 2013 00:40:49 -0800 (PST)
Received: from ([]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MeNF3-1TcBm33N0R-00QFku for <>; Fri, 11 Jan 2013 09:40:48 +0100
Received: (qmail invoked by alias); 11 Jan 2013 08:40:48 -0000
Received: from (EHLO []) [] by (mp017) with SMTP; 11 Jan 2013 09:40:48 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18uCQ4+LwMulXHBItBi2CAateWQNMZIUaFuB1m2EV CdJDPcK5VSW9xC
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="us-ascii"
From: Hannes Tschofenig <>
In-Reply-To: <>
Date: Fri, 11 Jan 2013 10:40:47 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Leif Johansson <>
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Subject: Re: [OAUTH-WG] review
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: Fri, 11 Jan 2013 08:40:50 -0000

Hi Leif, 

thanks for the timely review. 

On Jan 2, 2013, at 1:52 PM, Leif Johansson wrote:
> Some comments in the order I discovered them...
> - the term holder-of-_the_-key (my ascii-emphasis) is used when
> the normal terminology is just "holder-of-key", not sure what is
> added by the definite form...

In the meanwhile I am convinced that the entire holder-of*-key terminology is confusing. 

> - s/incredients/ingredients/g
> - say "a mechanism for secure and scalable key management" in 1 (1)
> instead of using the word "dynamic" which is pretty vague.

What I tried to express is that the keying material is distributed as part of the protocol exchange rather than provisioned out of band. 
But adding secure, and scalable is certainly also desirable. 

> - the wording in 3.1 makes it a bit hard to tell when you're talking about
> HotK or stock OAUTH.

Certainly true. In that section I am talking about the enhanced OAuth version. 

> - "profile" seems like too generic term to spend what is essentially a
> choice of key format.


> - in the example authz request you should clearly state that the 'id'
> parameter is use to carry the key identifier (just to improve
> readability). Perhaps
> change 'hotk' to 'hotk_id'.


> - why do key identifiers, profile names etc need their own ABNF (end
> of 3.1.1)?

Newly defined parameters need to follow some syntax. 

> - when computing the signature, don't you want to hash over the
> entire request string so that you include the HTTP version? At least
> in theory the semantics of the method is tied to the version...

What to include in the computation of the keyed message digest is up for discussion. 
I am OK with including the HTTP version as well.

> - what does "put into the body of the HTTP request." mean? Are
> you using any particular mime-type for instance?

I should have been more precise. 
Actually, I would like to leave that open for discussion of where to put the JWS structure. It may not always be best to put it into the body of the message. 

> - have you investigated the deployability of 3.2.2? I would expect that
> using signatures (JWS) would be a lot easer to code for in practice. Its
> a strange world.

I fully agree with you. A solution that utilized TLS is certainly more difficult to deploy than a JSON-based variant. The main purpose of the writeup was to illustrate the solution space. 
It might actually make sense two separate the two variants into two different documents since they are so different. 


>        Cheers Leif
> _______________________________________________
> OAuth mailing list