Skip to main content

Additional OAuth Parameters for Authorization in Constrained Environments (ACE)
draft-ietf-ace-oauth-params-16

Yes

(Benjamin Kaduk)

No Objection

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

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

Roman Danyliw Yes

Comment (2021-03-22 for -13)
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

Alvaro Retana No Objection

Erik Kline No Objection

Francesca Palombini No Objection

Comment (2021-03-24 for -13)
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?

John Scudder No Objection

Lars Eggert No Objection

Comment (2021-03-25 for -13)
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

Martin Duke No Objection

Comment (2021-03-18 for -13)
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)
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)
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)
* 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 steering group member) Yes

Yes (for -13)

                            

(Martin Vigoureux; former steering group member) No Objection

No Objection (for -13)