Additional OAuth Parameters for Authentication and Authorization for Constrained Environments (ACE)
RFC 9201

Thank you for this document. A couple of minor comments below.

Francesca

1. -----

      better symmetric keys than a constrained client.  The AS MUST
      verify that the client really is in possession of the
      corresponding key.  Values of this parameter follow the syntax and

FP: I think it would have been helpful to give some details about how this is done "by verifying the signature ..." or a reference to where this is described.

2. -----

   parameters.  An RS MUST reject a proof-of-possession using such a
   key.

FP: Is any error message supposed to be sent in such a case?

All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. There is no need to let me
know what you did with these suggestions.

Paragraph 1, nit:
Elwyn Davies' Gen-ART review
(https://mailarchive.ietf.org/arch/msg/gen-art/Yauw_b5iNrPx-nQ095FyFKmQxlM/)
contained some nits that I wanted to make sure you were aware of.

Section 12.1, paragraph 1, nit:
>    [I-D.ietf-ace-cwt-proof-of-possession]
>               Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
>               Tschofenig, "Proof-of-Possession Key Semantics for CBOR
>               Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
>               possession-11 (work in progress), October 2019.

Outdated reference: draft-ietf-ace-cwt-proof-of-possession has been published as
RFC 8747

Section 12.1, paragraph 2, nit:
>    [I-D.ietf-oauth-mtls]
>               Campbell, B., Bradley, J., Sakimura, N., and T.
>               Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication
>               and Certificate-Bound Access Tokens", draft-ietf-oauth-
>               mtls-17 (work in progress), August 2019.
>

Outdated reference: draft-ietf-oauth-mtls has been published as RFC 8705

Section 12.1, paragraph 4, nit:
>    [RFC7049]  Bormann, C. and P. Hoffman, "Concise Binary Object
>               Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
>               October 2013, <https://www.rfc-editor.org/info/rfc7049>.

Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949)

Section 1, paragraph 3, nit:
-    Respresentation (CBOR) [RFC7049], JSON [RFC8259] MAY be used as an
-      -
+    Representation (CBOR) [RFC7049], JSON [RFC8259] MAY be used as an

In sec 3.1 it says the AS SHOULD reject req_cnf if the key is symmetric. But in Sec 5 it presents a totally reasonable use case where the C and RS hold a previously established (symmetric?) key.  These observations are somewhat contradictory. Should 3.1 include a qualifier. Would the AS know about this key a priori so that it can ignore the recommendation? If not, how can this be done safely?

Seems pretty straightforward to me, though I reserve the right to change that opinion as I make my way through the other ACE documents.

I realize ACE isn't responsible for CBOR notation, but I have to double-take every time I see something that looks like JSON yet has stuff like a mix of quotes and apostrophes as string delimiters of some kind.

Section 3.2: "of from" should be "or from", in the 'cnf" definition block.

Section 4: I think there's a parenthesis missing on the first line of the example.

Thank you, I found this document clear and easy to understand. I did not check the examples, but am assuming that they are accurate.

* Section 1:
   Nit : s/Respresentation/Representation

* Section 3.1:
  I have similar observation as Martin Duke, and the resolution suggested by author looks fine with me as long as the cases are distinguishable.   

* Section 12: 
   Refers to draft-ietf-ace-oauth-authz-33, -38 version is available now.