Subject: [OAUTH-WG] review http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-01

From: Leif Johansson <[email-masked]>
Date: Wed, 02 Jan 2013 12:52:47 +0100

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...
- 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.
- the wording in 3.1 makes it a bit hard to tell when you're talking about
HotK or stock OAUTH.
- "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)?
- 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 does "put into the body of the HTTP request." mean? Are
you using any particular mime-type for instance?
- 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.

        Cheers Leif

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 11 Jan 2013 10:40:47 +0200

Hi Leif, 

thanks for the timely review. 

> added by the definite form...

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

> 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

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

OK. 

> change 'hotk' to 'hotk_id'.

OK. 

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

Newly defined parameters need to follow some syntax. 

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

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

> using signatures (JWS) would be a lot easer to code for in practice. Its

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. 

Ciao
Hannes

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