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