IETF LC comments are all addressed.
I don't have full data on whether IANA has all the needed approvals, but they will look again when this goes on a telechat.
Putting in "external party" since we are waiting to have the cluster of four documents go to the IESG together.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-ace-oauth-authz-27. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are fifteen actions which we must complete.

NOTE: We’re asking the ADs how to handle the registrations for which Hannes is the only reviewer.

IANA Question --> Several sections of the current draft propose to create new registries (Sections 8.1, 8.3, 8.4, 8.6, 8.7, 8.9, and 8.11). For each of these requests, IANA asks the authors where the new registries are to be located. Should they be added to an existing registry page? If not, do they belong in an existing category at http://www.iana.org/protocols? For each of the new registries, it is not clear from the context of the request where the new registries should be established.

First, a new registry is to be created called the ACE Authorization Server Request Creation Hints registry. The new registry will be established in a location to be determined later.

IANA Question --> What is the range of values possible for CBOR Keys?

The registration rules for the new registry are as follows:

< 65536 : Private Use
-65536 to -257 : Specification Required
-256 to 255 : Standards Action
256 to 65535 : Specification Required

There are initial registrations in the new registry as follows:

+-----------+----------+---------------------+---------------|
| Name | CBOR Key | Value Type | Reference |
|-----------+----------+---------------------|---------------|
| AS | 1 | text string | [ RFC-to-be ] |
| kid | 2 | byte string | [ RFC-to-be ] |
| unassigned| 3-4 | | |
| audience | 5 | text string | [ RFC-to-be ] |
| unassigned| 6-8 | | |
| scope | 9 | text or byte string | [ RFC-to-be ] |
| unassigned| 10-38 | | |
| cnonce | 39 | byte string | [ RFC-to-be ] |
+-----------+----------+---------------------+---------------+

Second, in the OAuth Extensions Error Registry on the OAuth Parameters registry page located at:

https://www.iana.org/assignments/oauth-parameters/

the following two registrations will be made:

Name: unsupported_pop_key
Usage Location: token error response
Protocol Extension: The ACE framework [ RFC-to-be ]
Change Controller: IESG
Reference: [ RFC-to-be Section 5.6.3]

Name: incompatible_profiles
Usage Location: token error response
Protocol Extension: The ACE framework [ RFC-to-be ]
Change Controller: IESG
Reference: [ RFC-to-be Section 5.6.3]

As this section requests registrations in a Specification Required (see RFC 8126) registry, the IESG-designated expert for the OAuth Extensions Error Registry has asked that you send a review request to the mailing list oauth-ext-review@ietf.org. This review must be completed before the document's IANA state can be changed to "IANA OK."

Third, a new registry is to be created called the OAuth Error Code CBOR Mappings registry. The new registry will be established in a location to be determined later.

IANA Question --> What is the range of values possible for CBOR Values?

The registration rules for the new registry are as follows:

< -65536 : Private Use
All other values : Expert Review

There are initial assignments in the new registry as follows:

+------------------------+-------------+---------------+
| Name | CBOR Values | Reference |
|------------------------+-------------|---------------|
| invalid_request | 1 | [ RFC-to-be ] |
| invalid_client | 2 | [ RFC-to-be ] |
| invalid_grant | 3 | [ RFC-to-be ] |
| unauthorized_client | 4 | [ RFC-to-be ] |
| unsupported_grant_type | 5 | [ RFC-to-be ] |
| invalid_scope | 6 | [ RFC-to-be ] |
| unsupported_pop_key | 7 | [ RFC-to-be ] |
| incompatible_profiles | 8 | [ RFC-to-be ] |
+------------------------+-------------+---------------+

Fourth, a new registry is to be created called the OAuth Grant Type CBOR Mappings registry. The new registry will be established in a location to be determined later.

IANA Question --> What is the range of values possible for CBOR Values?

The registration rules for the new registry are as follows:

< -65536 : Private Use
All other values : Expert Review

There are initial assignments in the new registry as follows:

+--------------------+------------+---------------+---------------+
| Name | CBOR Value | Original | Reference |
| | | Specification | |
|--------------------+------------+---------------+---------------|
| password | 0 | RFC6749 | [ RFC-to-be ] |
| authorization_code | 1 | RFC6749 | [ RFC-to-be ] |
| client_credentials | 2 | RFC6749 | [ RFC-to-be ] |
| refresh_token | 3 | RFC6749 | [ RFC-to-be ] |
+--------------------+------------+---------------+---------------+

Fifth, in the OAuth Access Token Types registry on the OAuth Parameters registry page located at:

https://www.iana.org/assignments/oauth-parameters/

the following, single registration will be made:

Type name: PoP
Additional Token Endpoint Response Parameters: cnf, rs_cnf
HTTP Authentication Scheme(s): N/A
Change Controller: IESG
Reference: [ RFC-to-be ]

As this section also requests a registration in a Specification Required (see RFC 8126) registry, the IESG-designated expert for the OAuth Access Token Types Registry has asked that you send a review request to the mailing list oauth-ext-review@ietf.org. This review must be completed before the document's IANA state can be changed to "IANA OK."

Sixth, a new registry is to be created called the OAuth Access Token Type CBOR Mappings registry. The new registry will be established in a location to be determined later.

IANA Question --> What is the range of values possible for CBOR Values?

The registration rules for the new registry are as follows:

< -65536 : Private Use
All other values : Expert Review

There are initial assignments in the new registry as follows:

+--------+--------+---------------+-----------------+
| Name | CBOR | Reference | Original |
| | Value | | Specification |
+--------+--------+---------------+-----------------+
| Bearer | 1 | [ RFC-to-be ] | RFC6749 |
| PoP | 2 | [ RFC-to-be ] | [ RFC-to-be ] |
+--------+--------+---------------+-----------------+

Seventh, a new registry is to be created called the ACE Profile registry. The new registry will be established in a location to be determined later.

IANA Question --> What is the range of values possible for CBOR Keys?

The registration rules for the new registry are as follows:

< 65536 : Private Use
-65536 to -257 : Specification Required
-256 to 255 : Standards Action
256 to 65535 : Specification Required

Initially, this registry will be empty.

Eighth, in the OAuth Parameters registry on the OAuth Parameters registry page located at:

https://www.iana.org/assignments/oauth-parameters/

the following, single registration will be made:

Name: ace_profile
Parameter Usage Location: token response
Change Controller: IESG
Reference: [ RFC-to-be Section 5.6.4.3]

As this section also requests a registration in a Specification Required (see RFC 8126) registry, the IESG-designated expert for the OAuth Parameters Registry has asked that you send a review request to the mailing list oauth-ext-review@ietf.org. This review must be completed before the document's IANA state can be changed to "IANA OK."

Ninth, a new registry is to be created called the OAuth Parameters CBOR Mappings registry. The new registry will be established in a location to be determined later.

IANA Question --> What is the range of values possible for CBOR Values?

The registration rules for the new registry are as follows:

< -65536 : Private Use
All other values : Expert Review

There are initial assignments in the new registry as follows:

+-------------------+----------+---------------------+---------------+
| Name | CBOR Key | Value Type | Reference |
|-------------------+----------+---------------------|---------------|
| access_token | 1 | byte string | [ RFC-to-be ] |
| expires_in | 2 | unsigned integer | [ RFC-to-be ] |
| unassigned | 3-4 | | |
| audience | 5 | text string | [ RFC-to-be ] |
| unassigned | 6-8 | | |
| scope | 9 | text or byte string | [ RFC-to-be ] |
| unassigned | 10-23 | | |
| client_id | 24 | text string | [ RFC-to-be ] |
| client_secret | 25 | byte string | [ RFC-to-be ] |
| response_type | 26 | text string | [ RFC-to-be ] |
| redirect_uri | 27 | text string | [ RFC-to-be ] |
| state | 28 | text string | [ RFC-to-be ] |
| code | 29 | byte string | [ RFC-to-be ] |
| error | 30 | unsigned integer | [ RFC-to-be ] |
| error_description | 31 | text string | [ RFC-to-be ] |
| error_uri | 32 | text string | [ RFC-to-be ] |
| grant_type | 33 | unsigned integer | [ RFC-to-be ] |
| token_type | 34 | unsigned integer | [ RFC-to-be ] |
| username | 35 | text string | [ RFC-to-be ] |
| password | 36 | text string | [ RFC-to-be ] |
| refresh_token | 37 | byte string | [ RFC-to-be ] |
| ace_profile | 38 | unsigned integer | [ RFC-to-be ] |
| cnonce | 39 | byte string | [ RFC-to-be ] |
+-------------------+----------+---------------------+---------------+

Tenth, in the OAuth Parameters registry on the OAuth Token Introspection Response registry page located at:

https://www.iana.org/assignments/oauth-parameters/

the following, single registration will be made:

Name: ace_profile
Description: The communication and communication security profile used between client and RS, as defined in ACE profiles.
Change Controller: IESG
Reference: [ RFC-to-be Section 5.7.2]

As this section also requests a registration in a Specification Required (see RFC 8126) registry, the IESG-designated experts for the OAuth Token Introspection Response Registry have asked that you send a review request to the mailing list oauth-ext-review@ietf.org. This review must be completed before the document's IANA state can be changed to "IANA OK."

Eleventh, a new registry is to be created called the OAuth Token Introspection Response CBOR Mappings registry. The new registry will be established in a location to be determined later.

IANA Question --> What is the range of values possible for CBOR Values?

The registration rules for the new registry are as follows:

< -65536 : Private Use
All other values : Expert Review

There are initial assignments in the new registry as follows:

+-------------------+----------+-------------------------+---------------+
| Parameter name | CBOR Key | Value Type | Reference |
|-------------------+----------+-------------------------|---------------+
| iss | 1 | text string | [ RFC-to-be ] |
| sub | 2 | text string | [ RFC-to-be ] |
| aud | 3 | text string | [ RFC-to-be ] |
| exp | 4 | integer or | [ RFC-to-be ] |
| | | floating-point number | [ RFC-to-be ] |
| nbf | 5 | integer or | [ RFC-to-be ] |
| | | floating-point number | [ RFC-to-be ] |
| iat | 6 | integer or | [ RFC-to-be ] |
| | | floating-point number | [ RFC-to-be ] |
| cti | 7 | byte string | [ RFC-to-be ] |
| unassigned | 8 | | |
| scope | 9 | text or byte string | [ RFC-to-be ] |
| active | 10 | True or False | [ RFC-to-be ] |
| token | 11 | byte string | [ RFC-to-be ] |
| unassigned | 12-23 | | |
| client_id | 24 | text string | [ RFC-to-be ] |
| unassigned | 25-29 | | |
| error | 30 | unsigned integer | [ RFC-to-be ] |
| error_description | 31 | text string | [ RFC-to-be ] |
| error_uri | 32 | text string | [ RFC-to-be ] |
| token_type_hint | 33 | text string | [ RFC-to-be ] |
| token_type | 34 | text string | [ RFC-to-be ] |
| username | 35 | text string | [ RFC-to-be ] |
| unassigned | 36-37 | | |
| ace_profile | 38 | unsigned integer | [ RFC-to-be ] |
| cnonce | 39 | byte string | [ RFC-to-be ] |
| exi | 40 | unsigned integer | [ RFC-to-be ] |
+-------------------+----------+-------------------------+---------------|

Twelfth, in the JSON Web Token Claims registry on the JSON Web Token (JWT) registry page located at:

https://www.iana.org/assignments/jwt/

the following three registrations will be made:

Claim Name: ace_profile
Claim Description: The profile a token is supposed to be used with.
Change Controller: IESG
Reference: [ RFC-to-be Section 5.8]

Claim Name: exi
Claim Description: "Expires in". Lifetime of the token in seconds from the time the RS first sees it. Used to implement a weaker from of token expiration for devices that cannot synchronize their internal clocks.
Change Controller: IESG
Reference: [ RFC-to-be Section 5.8.3]

Claim Name: cnonce
Claim Description: "client-nonce". A nonce previously provided to the AS by the RS via the client. Used to verify token freshness when the RS cannot synchronize its clock with the AS.
Change Controller: IESG
Reference: [ RFC-to-be ]

As this section also requests a registration in a Specification Required (see RFC 8126) registry, the IESG-designated experts for the JSON Web Token Claims Registry have asked that you send a review request to the mailing list jwt-reg-review@ietf.org. This review must be completed before the document's IANA state can be changed to "IANA OK."

Thirteenth, in the CBOR Web Token (CWT) Claims registry located at:

https://www.iana.org/assignments/cwt/

the following, four new registrations will be made:

Claim Name: scope
Claim Description: The scope of an access token as defined in [RFC6749].
JWT Claim Name: scope
Claim Key: [ TBD-at-Registration ]
Claim Value Type: byte string or text string
Change Controller: IESG
Reference: [I-D.ietf-oauth-token-exchange]

Claim Name: ace_profile
Claim Description: The profile a token is supposed to be used with.
JWT Claim Name: ace_profile
Claim Key: [ TBD-at-Registration ]
Claim Value Type: integer
Change Controller: IESG
Reference: [ RFC-to-be Section 5.8]

Claim Name: exi
Claim Description: The expiration time of a token measured from when it was received at the RS in seconds.
JWT Claim Name: exi
Claim Key: [ TBD-at-Registration ]
Claim Value Type: integer
Change Controller: IESG
Reference: [ RFC-to-be Section 5.8.3]

Claim Name: cnonce
Claim Description: The client-nonce sent to the AS by the RS via the client.
JWT Claim Name: [ TBD-at-Registration ]
Claim Key: cnonce
Claim Value Type: byte string
Change Controller: IESG
Reference: [ RFC-to-be Section 5.8]

IANA notes that the authors suggest Claim Key values for ace_profile (38), exi (40) and cnonce (39).

As this section also requests a registration in a Specification Required (see RFC 8126) registry, the IESG-designated experts for the CBOR Web Token (CWT) Claims Registry have asked that you send a review request to the mailing list cwt-reg-review@ietf.org. This review must be completed before the document's IANA state can be changed to "IANA OK."

Fourteenth, in the application registry on the Media Types registry located at:

https://www.iana.org/assignments/media-types/

a single, new media type is to be registered as follows:

Name: ace+cbor
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Fifteenth, in the CoAP Content-Formats on the Constrained RESTful Environments (CoRE) Parameters registry page located at:

https://www.iana.org/assignments/core-parameters/

the following, single registration will be made:

Media Type: application/ace+cbor
Encoding:
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

IANA notes that the authors have suggested a value of 19 for this registration.

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-12-13):

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: ace-chairs@ietf.org, ietf@augustcellars.com, draft-ietf-ace-oauth-authz@ietf.org, Jim Schaad <ietf@augustcellars.com>, kaduk@mit.edu, ace@ietf.org
Reply-To: last-call@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-ace-oauth-authz-27.txt> (Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)) to Proposed Standard


The IESG has received a request from the Authentication and Authorization for
Constrained Environments WG (ace) to consider the following document: -
'Authentication and Authorization for Constrained Environments (ACE)
  using the OAuth 2.0 Framework (ACE-OAuth)'
  <draft-ietf-ace-oauth-authz-27.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2019-12-13. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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 and CoAP, 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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3123/



The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc4949: Internet Security Glossary, Version 2 (Informational - Independent Submission Editor stream)

DATE 2 March 2019 - version -21

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) Is should be a Proposed Standard and that is reflected in the
meta information.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document describes a framework for the use of OAuth 2.0
  in a constrained environment.  The document is mainly targeted
  at the protocols defined for CoAP, but other protocols can
  be used as well.  The framework defines the fields and
  symmantics needed for doing authorization and authenticiation
  of a client. 

Working Group Summary

  The concesus on the document wa generally very solid.  There
  were some issues that arose between the ACE and OAuth working
  groups over a couple of issues.  These issues appear to have
  been resolved.

Document Quality

  There have been at least four different groups who have
  announced an implementation at some level of the specification.
  While two of those implementations share a certain amount of
  common code, there are two implementations which have done
  interop tests at various times which do not share any code
  based on this document.

  The scope and issues of trying to deal with some of the
  OAuth 2.0 documents can be challenging at times.  While
  it is believed that a good job has been done, there are
  some potential areas where different people might end up
  doing new things.

Personnel

  Jim Schaad is the Document Shepherd.  Ben Kaduk is the
  responsible AD.

(3) I have done a detailed read a number of times during the WGLC
process and while shepherding to make sure all WGLC comments were
addressed.  Additionally, I have done an implementation of the document
during development.

(4) Between the implentations of the framework that we have and the
healthy discussions during the WGLC, I am confident that there has
been quite broad review of the document.

(5) No broader review should be needed.  During the process there has
been significant review from the OAuth working group.

(6) I have no issues with this specific document.  I do have a problem
with how the registries have been setup in OAuth, but that is not
germane to this document.

(7) All authors have indicated that they do no know of any additional IPR
that needs to be disclosed.
Ludwig  2/25/19
Goren  2/25/19
Erdtman 2/25/19
Hannes  2/27/19

(8) There is an IPR disclosure on this document.  During the shepards review, I specifically requested if there were any concerns about this IPR and none were raised. 

(9) The set of people that have contributed probably represent about a dozen
individuals in the WG.

(10) There has been no extreme discontent expressed during the discussions.

(11) No ID nits are called out.

(12)  The only formal review needed is for a new media type.
The media type request for application/ace+cbor was mailed 23 Feb 2019.

(13) All references are tagged and reasonable.

(14) All of the normative documents which are in process are at the
same stage of development and thus should not cause any issues.

(15) There are no downward normative references.

(16) This document represents the first iteration.  It profiles and extends
some of the OAuth documents, but this is not done by modifications of the
documents themselves.

(17) It was somewhat painful.  I looked at all items that were defined
and should be registered to make sure that they existed in the IANA
considerations.  I compared the registrations of items with the required
templates or columns in the IANA registries.  A detailed walk of the
new registries along with reasonable behavior was examined.

(18) The following new IANA registries are created:

ACE Authorization Server Request Creation Hints -
Contains a set of attributes to be returned from a resource server
that can be used by a client when building the request to the
authorization server.  There is not currently an equivalent registry
for OAuth so it is not clear that an OAuth person is going to be
extremely useful.  Some implementation experience would probably
be useful, but is definitely not required.

OAuth Error Code CBOR Mappings -
Contains a mapping of errors that can be returned in OAuth.  No
special expertise should be required for the experts.

OAuth Grant Type CBOR Mappings -
Contains a mapping of grant types from the OAuth registry to a
CBOR integer.  No special expertise should be required for the
experts.

OAuth Access Token Type CBOR Mapping -
Contains a mapping of token types from the OAuth registry to
a CBOR integer.  No special expertise should be required for
the experts.

ACE Profile -
Contains the set of ACE profiles that use the framework.
The experts should have a solid working knowledge of the framework
as they need to be able to evaluate any new profile against the
framework to make sure that all of the conditions outlined are
fulfilled.

OAuth Parameters CBOR Mapping -
Contains the set of mappings from OAuth parameters to integer
values.  No special expertise should be required for the
experts.

OAuth Token Introspection Response CBOR Mappings -
Contains the mapping of response parameters from the OAuth
registry to a CBOR integer and type.  No special expertise should
be required for the experts.

List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

(19) No automated checks were done.

DATE 2 March 2019 - version -21

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) Is should be a Proposed Standard and that is reflected in the
meta information.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document describes a framework for the use of OAuth 2.0
  in a constrained environment.  The document is mainly targeted
  at the protocols defined for CoAP, but other protocols can
  be used as well.  The framework defines the fields and
  symmantics needed for doing authorization and authenticiation
  of a client. 

Working Group Summary

  The concesus on the document wa generally very solid.  There
  were some issues that arose between the ACE and OAuth working
  groups over a couple of issues.  These issues appear to have
  been resolved.

Document Quality

  There have been at least four different groups who have
  announced an implementation at some level of the specification.
  While two of those implementations share a certain amount of
  common code, there are two implementations which have done
  interop tests at various times which do not share any code
  based on this document.

  The scope and issues of trying to deal with some of the
  OAuth 2.0 documents can be challenging at times.  While
  it is believed that a good job has been done, there are
  some potential areas where different people might end up
  doing new things.

Personnel

  Jim Schaad is the Document Shepherd.  Ben Kaduk is the
  responsible AD.

(3) I have done a detailed read a number of times during the WGLC
process and while shepherding to make sure all WGLC comments were
addressed.  Additionally, I have done an implementation of the document
during development.

(4) Between the implentations of the framework that we have and the
healthy discussions during the WGLC, I am confident that there has
been quite broad review of the document.

(5) No broader review should be needed.  During the process there has
been significant review from the OAuth working group.

(6) I have no issues with this specific document.  I do have a problem
with how the registries have been setup in OAuth, but that is not
germane to this document.

(7) All authors have indicated that they do no know of any additional IPR
that needs to be disclosed.
Ludwig  2/25/19
Goren  2/25/19
Erdtman 2/25/19
Hannes  2/27/19

(8) There is an IPR disclosure on this document.  During the shepards review, I specifically requested if there were any concerns about this IPR and none were raised. 

(9) The set of people that have contributed probably represent about a dozen
individuals in the WG.

(10) There has been no extreme discontent expressed during the discussions.

(11) No ID nits are called out.

(12)  The only formal review needed is for a new media type.
The media type request for application/ace+cbor was mailed 23 Feb 2019.

(13) All references are tagged and reasonable.

(14) All of the normative documents which are in process are at the
same stage of development and thus should not cause any issues.

(15) There are no downward normative references.

(16) This document represents the first iteration.  It profiles and extends
some of the OAuth documents, but this is not done by modifications of the
documents themselves.

(17) It was somewhat painful.  I looked at all items that were defined
and should be registered to make sure that they existed in the IANA
considerations.  I compared the registrations of items with the required
templates or columns in the IANA registries.  A detailed walk of the
new registries along with reasonable behavior was examined.

(18) The following new IANA registries are created:

ACE Authorization Server Request Creation Hints -
Contains a set of attributes to be returned from a resource server
that can be used by a client when building the request to the
authorization server.  There is not currently an equivalent registry
for OAuth so it is not clear that an OAuth person is going to be
extremely useful.  Some implementation experience would probably
be useful, but is definitely not required.

OAuth Error Code CBOR Mappings -
Contains a mapping of errors that can be returned in OAuth.  No
special expertise should be required for the experts.

OAuth Grant Type CBOR Mappings -
Contains a mapping of grant types from the OAuth registry to a
CBOR integer.  No special expertise should be required for the
experts.

OAuth Access Token Type CBOR Mapping -
Contains a mapping of token types from the OAuth registry to
a CBOR integer.  No special expertise should be required for
the experts.

ACE Profile -
Contains the set of ACE profiles that use the framework.
The experts should have a solid working knowledge of the framework
as they need to be able to evaluate any new profile against the
framework to make sure that all of the conditions outlined are
fulfilled.

OAuth Parameters CBOR Mapping -
Contains the set of mappings from OAuth parameters to integer
values.  No special expertise should be required for the
experts.

OAuth Token Introspection Response CBOR Mappings -
Contains the mapping of response parameters from the OAuth
registry to a CBOR integer and type.  No special expertise should
be required for the experts.

List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

(19) No automated checks were done.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1)
What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

(3)
Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

(4)
Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?


(5)
Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

(6)
Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

(7)
Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

(8)
Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

(9)
How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

(10)
Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

(11)
Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

(12)
Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

(13)
Have all references within this document been identified as
either normative or informative?

(14)
Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

(15)
Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

(16)
Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.


(17)
Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

(18) The following new IANA registries are created:

ACE Authorization Server Information -

OAuth Error Code CBOR Mappings -

OAuth Grant Type CBOR Mappings -

Token Type CBOR Mappings -

ACE Profile -

Token Endpoint CBOR Mappings -

Introspection Endpoint CBOR Mappings -


List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

(19)
Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

**************************************************************************

**DONE** Stefanie Gerdes

Ben Kaduk

>
> On 22/10/2018 21:09, Jim Schaad wrote:
> > * Section 5.8.2 - If the RS is going to do introspection, can it send some
> > type of "Server Busy - try again in xxx" while it does the introspection
> > rather than just doing an ack of the request and possibly waiting a long
> > time?
>
> This is probably transport protocol specific, and we were asked not to
> link the framework to a specific protocol, thus I don't know if we can
> provide guidance here.

I think it would be okay to say something like "some transport protocols
may provide a way to indicate that the server is busy and the client should
retry after an interval; this type of status update would be appropriate
while the server is waiting for an introspection response".  Which does
provide guidance, but in a non-normative fashion that does not require or
prohibit any given transport protocol.

Mike Jones:

**IGNORE** IT CAN'T BE A COINCIDENCE:  There's clearly a relationship between many of the CBOR numeric values used in this this specification and corresponding CBOR Web Token (CWT) claim identifiers, but oddly, the relationship is currently unspecified and the goals behind it are undefined.  The spec should be augmented to make the nature and goals of this relationship explicit.  I infer that there's such a relationship because the Mapping Parameters to CBOR in Section 5.6.5 apparently carefully do not overlap with the values registered in the IANA CWT Claims registry at https://www.iana.org/assignments/cwt/cwt.xhtml.  The Introspection mappings in Section 5.7.4 apparently carefully use the same values as CWT for the same things, but then adds additional values.  And some of these values are the same as values proposed for the CWT Claims registry in 8.13.  This has to be more than a coincidence but the spec doesn't currently say why.

Per my earlier reviews of the ace-authz spec, I believe that the ACE OAuth parameters should all be registered in the CWT Claims registry because of the possibility of them being used in signed requests in a manner analogous to https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17.  The parameters need to be registered to avoid future claim number conflicts.  While conflicts have clearly been carefully avoided to date, they will inevitably occur in the future unless the values are actually registered.  Please do so.

DON'T SQUAT ON NUMERIC REGISTRY VALUES:  Please change all instances of numbers to be assigned by designated experts in existing registries from specific values to "TBD".  For instance, all the values for the CWT Claims Registry in Section 8.13 (currently 12, 16, and 17) should be changed to TBD.  Our chair, Jim Schaad has been a vigorous advocate of not squatting in my past interactions with him as a Designated Expert and I believe would support this request.  Likewise, the "19" in the CoAP Content-Format Registration in Section 8.15 should become TBD.

**DONE** req_aud: Several examples use the "req_aud" parameter without defining it.  Doesn't this duplicate the "resource" parameter defined by https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01?  If so, please delete this parameter and use "resource".  If not, say how it is different and why the differences are necessary.

**DONE** rs_cnf:  There isn't a clear normative definition of this parameter.  It's mentioned obliquely but its purpose, syntax, and semantics should be plainly stated (as with each other newly defined parameter).

The proposed numbers in Figures 12 and 16 contain mismatches.  For instance, token_type is "14" in Figure 12 in Section 5.6.5 and "13" in Figure 16 in Section 5.7.4.  There's too much alignment for it to be a coincidence but if you intend alignment, please say so explicitly and fix the alignment.  The proposed ongoing alignment should also be described in the registration instructions for the Designated Experts.

-- Mike

P.S.  Per my earlier reviews of this specification, in my view as a Designated Expert for the CWT Claims registry, I believe that it's not appropriate to use up rare single-byte identifiers for most of the OAuth parameter encodings specified in 5.6.5.  I could be persuaded that "scope" merits one of these rare numbers, but "profile", "error", "grant_type", "access_token", and "token_type" probably do not, as they are application-specific and not of general applicability.  I also believe that some of the other Designated Experts for this registry agree with me.

Jim Schaad

* Section 3.1 - Refresh Token - I don't think that refresh tokens are going
to be strings because binary is more efficient.

**DONE** * Section 3.2 - we need to reference TLS 1.3 even if DTLS 1.3 is not yet
available.

* Description for Figure 6 -  Should the example somehow indicate in the
message that it is going to be an application/ace+cbor content.  Also, I
don't know that this is a good example in some ways because this is not a
currently documented profile anywhere.

**DONE** * Section 5.6.3 - Should the content type for an error response be
application/ace+cbor ?

**DONE** * Section 5.7.1 - Is the content format for a request application/ace+cbor?
I assume it is but that is not documented in this section.

**DONE** Section 5.8 - bytes arrays or byte strings?  I think CBOR uses the latter

**DONE** * Section 5.8.1 - What is the purpose of creating an identifier for a token?
Is this supposed to be used rather than the one from the AS for something
like shared secret TLS?  Note that this is an unprotected value.

* Section 5.8.1 - Given the change in the OSCORE profile, you might want to
make this an application/ace+cbor structure as well.

**DONE** * Section 5.8.1 - If the token is "not valid" is the RS required (i.e. MUST)
to try introspection before returning a response if the RS does
introspection?  The text currently says MAY.  If this is really MAY then the
text should say that the token is always successfully accepted by the RS.

* Section 5.8.2 - If the RS is going to do introspection, can it send some
type of "Server Busy - try again in xxx" while it does the introspection
rather than just doing an ack of the request and possibly waiting a long
time?

* Section 5.8.3 - third point - I think that the correct text would be "The
method does not provide timely expiration, but it makes sure that older
tokens will cease to be valid after newer issued tokens are registered with
the RS."  My problem is that just issuing tokens is not enough as they may
be going to a different RS for use.  This may also need to have some type of
rate limit to issued tokens or making the sequence number be on an
RS/audience basis.

* Section 6. - The recommendation not to use a shared secret for an audience
which is hosted by multiple servers is interesting.  This does require that
a multiple recipient COSE structure be used and it may be worth calling that
out.  Also the size of the CWT is going to grow for that.  You are also now
losing the low-level authentication and thus a signature wrapping is now
also needed.

**DONE** * Section 6 - "Developers MUST" para - May want to add that this can also be
mitigated to some extent by making sure that keys roll over more frequently.

* Section 6 - I am not sure that I agree with the SHOULD NOT in the last
paragraph.  Think multicast.

**DONE** * Section 6.4 - This also applies to sending back some type of identifier
from the RS->C when a token is registered.

**DONE** * Section 8.6.1 - Is pop still this document or is it Mike's document?

**DONE** * Section 8.9 - The description of reference is wrong.

**DONE** * Section 8.12 - some of these should move to the OAuth parameters document?

**DONE** * Section 8.13 - ditto

**DONE** * Appendix A -  para "CBOR, COSE, CWT"  - Is it really a requirement to use
CBOR or is that a recommended?  I thought this was part of what Hannes was
looking at.

**DONE** * Appendix A - para Client Credentials Grant  s/can the/can then/

* Registries -  I am wondering if we should think about re-writing a couple
of the registries.  As things stand it appears that the application/ace+cbor
content type is being used in 5 or 6 places.  It might make more sense to
have a registry for all of the CBOR abbreviations that are being used in a
single table and have multiple columns for each of the different places were
the content format is being used.  This would make it easier to keep
everything constant and can make re-use of integer values easier to see. 

* Comments on protection of CWT/Token:  I am wondering if there needs to be
any comments on how a CWT is going to be protected.  While it is ok to use
either a symmetric key or a direct key agreement operation for a single
recipient without forcing a signature operation to occur.  If the token is
going to be targeted a single audience hosted on multiple RSs then a
signature operation would be required for the purposes of authentication. 

**DONE** * I am not sure where this issue should be raised so I am putting it here.
Both of the profiles have as their last security consideration a statement
that the use of multiple access tokens is a bad idea.  Both of them also
devote a large section of text to how to deal with multiple access tokens as
does this document.  More methods of having multiple access tokens seem to
be coming down the path from the OAuth group.  This appears to be a distinct
contradiction within the set of documents that should be resolved.