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. OK. > - 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'. OK. > - 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. Ciao Hannes > > Cheers Leif > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
