Additional OAuth Parameters for Authorization in Constrained Environments (ACE)
draft-ietf-ace-oauth-params-16
Yes
No Objection
Note: This ballot was opened for revision 13 and is now closed.
Roman Danyliw Yes
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
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
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
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
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
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
* 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
(Martin Vigoureux; former steering group member) No Objection