The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework
draft-ietf-ace-oscore-profile-19

I tried, but failed, to come up with a reason to DISCUSS this document just to troll my new co-AD.

As in one of the other ACE documents, the variable use of apostrophes and quotes created mental dissonance.  Here, though, it's not just in the JSON-like examples, but even in the prose.  It's consistent until about Section 4, and then it begins to change.  The second-last paragraph of Section 4.2 even uses both.

Within Section 1.1, the text describes the draft variably as "this document", "this specification", "the document", and "this memo".  That's weird.  And "memo" appears again in Acknowledgements.

In Section 6, you might want to clarify that the context is discarded when any of the things in that list occur.  Or is it only when all of them occur?

In Section 7, is "provisionings" a word?  Perhaps change "considerably more token provisionings than expected" to "considerably more tokens provisioned than would be expected".

Thank you to Kathleen Moriarty for the SECDIR review.

Thanks you for addressing my DISCUSS and COMMENT feedback.

Thanks to Linda Dunbar for the OpsDir review, and to the authors for addressing it.

It's always nice when directorate reviews improve the document.

Thanks for this document.
 
I support Roman's discuss and have similar observations when it comes to normative text usage (see Roman's discuss comments).

Some nits below --

* Section 2:
      This
      profile RECOMMENDS the use of OSCORE between client and AS, to reduce
      the number of libraries the client has to support, but other
      protocols fulfilling the security requirements defined in section 5
      of [I-D.ietf-ace-oauth-authz] (such as TLS or DTLS) MAY be used as
      well.

 [TLS, DTLS] reference is missing.

* Section 3.2:
   Typo : s/parameeter/parameter

Thank you for the work put into this document.

I found no points to comment/discuss on.

As a side comment, I find it sad that the data tracker is missing the doc shepherd's name (except if Jim Schaad's family has requested the change).

Regards,

-éric

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/Es7PhQvSnCixYRfEYs0RLqcLYC0/)
contains a nits that I wanted to make sure you were aware of.

Section 3.2, paragraph 14, nit:
-    the 'cnf' parameeter of the access token response.  If included, the
-                   -
+    the 'cnf' parameter of the access token response.  If included, the

Sec 4.1. I don't understand how the OSCORE security context is secure. In Sec 4.1 it says the C-RS communications need not be protected. But the context is fully derived from parameters that go back and forth over this channel. Why can't an observer simply compute the OSCORE keys?