Subject: [Ace] Genart last call review of draft-ietf-ace-oauth-authz-27

From: Stewart Bryant via Datatracker <[email-masked]>
Date: Thu, 12 Dec 2019 12:44:40 -0800

Reviewer: Stewart Bryant
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-ace-oauth-authz-27
Reviewer: Stewart Bryant
Review Date: 2019-12-12
IETF LC End Date: 2019-12-13
IESG Telechat date: Not scheduled for a telechat

Summary: Reviewed from the point of view of a generalist, this is a well
written document with just a few nits that ought be be addressed.

Major issues: None

Minor issues: None

Nits/editorial comments:

Abstract

   This specification defines a framework for authentication and
   authorization in Internet of Things (IoT) environments called ACE-
   OAuth.  The framework is based on a set of building blocks including
   OAuth 2.0
SB> OAuth 2.0 needs a RFC or other reference
=====
   and CoAP,

SB> CoAP is not in the list of well-known abreviations and needs expanding
====
   thus transforming a well-known and widely used
   authorization solution into a form suitable for IoT devices.
   Existing specifications are used where possible, but extensions are
   added and profiles are defined to better serve the IoT use cases.

   While prior work on authorization solutions for the Web and for the
   mobile environment also applies to the Internet of Things (IoT)
   environment, many IoT devices are constrained, for example, in terms
   of processing capabilities, available memory, etc.  For web
   applications on constrained nodes, this specification RECOMMENDS the
   use of CoAP [RFC7252] as replacement for HTTP.

SB> Please expand CoAP
===
   A detailed treatment of constraints can be found in [RFC7228], and

SB> I think you should provide a short context on "constraints"

   the different IoT deployments present a continuous range of device
   and network capabilities.  Taking energy consumption as an example:
   At one end there are energy-harvesting or battery powered devices
   which have a tight power budget, on the other end there are mains-
   powered devices, and all levels in between.
===

   More detailed, interoperable specifications can be found in profiles.
SB> What do you mean by "profiles" as a word on its own?
====

   A third building block is CBOR [RFC7049],
SB> CBOR needs to be expanded on first use.
====

      HTTP, HTTP/2, QUIC, MQTT, Bluetooth Low Energy, etc., are also
      viable candidates.

SB> These really need references
SB> Except for HTTP the abreviations need expanding on first use.
=====

   In this example, the attribute AS points the receiver of this message
   to the URI "coaps://as.example.com/token" to request access
   permissions.  The originator of the AS Request Creation Hints payload
   (i.e., RS) uses a local clock that is loosely synchronized with a
   time scale common between RS and AS (e.g., wall clock time).
   Therefore, it has included a parameter "nonce" (see Section 5.1.2.1).

SB> I think the above text could usefully be re-worded for clarity.
SB> The "therefore" does not seem to follow the preceeding text.
====
   o  A RS sending a "cnonce" parameter in an an AS Request Creation
SB> An RS...
=====

---

From: Ludwig Seitz <[email-masked]>
Date: Sat, 14 Dec 2019 17:20:34 +0100

> like any other last call comments.

Thank you Stewart for this review, comments inline.

Note that the posting of an update draft might be a bit delayed due to
issues with my affiliation change. You can inspect my edits here
meanwhile: https://github.com/ace-wg/ace-oauth

/Ludwig

> SB> OAuth 2.0 needs a RFC or other reference

Both fixed

> SB> CoAP is not in the list of well-known abreviations and needs expanding

Fixed

>     use of CoAP [RFC7252] as replacement for HTTP.

Fixed
> SB> I think you should provide a short context on "constraints"

I added a reference to Appendix A which does just that.

> SB> What do you mean by "profiles" as a word on its own?

I added some clarification
> SB> CBOR needs to be expanded on first use.

Fixed
> SB> Except for HTTP the abreviations need expanding on first use.

Done, note that there does not seem to be an expansion for QUIC.

> SB> The "therefore" does not seem to follow the preceeding text.

I rephrased this to hopefully improve readability and clarify the
"therefore" (and s/nonce/cnonce).

>     o  A RS sending a "cnonce" parameter in an an AS Request Creation

This doesn't feel right, since there is no consonant in RS and the R in
"Resource Server" (the expansion of RS) is not silent either. Is there a
grammar rule that I'm unaware of?

You did however make me aware of a typo later in that sentence where
there it says: "an an".

---

From: Ludwig Seitz <[email-masked]>
Date: Sat, 14 Dec 2019 17:29:35 +0100

> SB> OAuth 2.0 needs a RFC or other reference

I'm now in the process of posting -29 including the updates you
suggested. The idnits tool complains that the abstract should not
contain references, so I'm rolling back those changes.
There is a reference to the RFCs of OAuth and CoAP at first mention in
the text body.

/Ludwig

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 15 Dec 2019 23:32:27 -0800

> You did however make me aware of a typo later in that sentence where

I think you would say "a resource server" but "an ar ess".

-Ben