Skip to main content

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


(Benjamin Kaduk)

No Objection

Erik Kline
John Scudder
Robert Wilton
Éric Vyncke
(Alvaro Retana)
(Martin Vigoureux)

Note: This ballot was opened for revision 13 and is now closed.

Roman Danyliw
Comment (2021-03-22 for -13) Not sent
Thanks to Elwyn Davies for the SECDIR review.

Two nits on references:
-- Section 1.  s/RFC7049/RFC8949/ as RFC7049 has been obsoleted
-- Section 4.  s/ I-D.ietf-oauth-mtls/RFC 8705/ as draft-ietf-oauth-mtls has been published
Erik Kline
No Objection
Francesca Palombini
No Objection
Comment (2021-03-24 for -13) Sent
Thank you for this document. A couple of minor comments below.


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

FP: Is any error message supposed to be sent in such a case?
John Scudder
No Objection
Lars Eggert
No Objection
Comment (2021-03-25 for -13) Sent
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
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, <>.

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
Martin Duke
No Objection
Comment (2021-03-18 for -13) Sent
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?
Murray Kucherawy
No Objection
Comment (2021-03-24 for -13) Sent
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.
Robert Wilton
No Objection
Warren Kumari
No Objection
Comment (2021-03-24 for -13) Not sent
Thank you, I found this document clear and easy to understand. I did not check the examples, but am assuming that they are accurate.
Zaheduzzaman Sarker
No Objection
Comment (2021-03-24 for -13) Sent
* 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.
Éric Vyncke
No Objection
Benjamin Kaduk Former IESG member
Yes (for -13) Unknown

Alvaro Retana Former IESG member
No Objection
No Objection (for -13) Not sent

Martin Vigoureux Former IESG member
No Objection
No Objection (for -13) Not sent