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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
