[Ace] Review of draft-jones-ace-cwt-proof-of-possession-00

[Jim Schaad <[e-mail]>]

Abstract - I am unclear how this is a profile of RFC 7800 rather than a
restatement of that document.   In what way does this qualify as a profile?

Introduction - I do not understand the second half of the first sentence in
the introduction.  It claims that the document is going to show how proof of
possession is done, however this seems to be explicitly declared as out of
scope in section 3.5.

Section 2 - Since this document is currently planned to come from the ACE
working group,  I would suggest that it would be reasonable to provide the
equivalent terminology to what is in this document. -- see actors

Section 3 - para 1 - missed  a s/JSON/CBOR/

Section 3 - para 2 - I am not sure of the following:
- Why this is included here and not a separate section
- Why the concept of an anonymous POP is not supported
- Why the concept of the issuer being inferred from the authentication key
on the CWT is not supported
- I will note that draft-ietf-ace-oauth-authz does not require either of
these fields to be present.

Section 3.1 - The first two sentences seems to be slightly contradictory -
the first says the cnf claim is used to identify the POP key.  The second
states that it may have something other than a POP key in it.

Section 3.1 - I am not a fan of MUST ignore statements at this level.  It
should be  profile statement if anything.

Section 3.1 - last paragraph - Does this mean that only one claim can be in
the cnf claim - or are some values of different levels?  For example -can I
have a COSE_Key and an Kid?  This might be considered to be multiple POP
keys.

Section 3.2 - Profiles can require that additional elements can be required
in the COSE_Key element - and example would be to require that the algorithm
identifier be present.

Section 3.2 - I do not understand why this paragraph is doing in this
section give the section title.  Why is it not in section 3.3 or in a
separate section.  I think it makes mores sense at the end of the next
section.

Section 3.3 - Why is title not symmetric with section 3.2 and the word
encrypted be absent?

Section 3.4 - This section just makes me uncomfortable.  Use a value that
was potentially chosen for collisions does not seem to be a good idea.  I
think this really needs some additional guidance about using.

Section 4 - Is there any reason to suppose that the use of asymmetric
secrets are immune from replay attacks?


Section 3.1 - para 1 -sentence #2  -  I do not understand the implication
that the POP key implies the authenticity of the token.  That statement
makes no sense to me.  This would look  like a self-signed certificate as
the authentication point. 

Jim