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

[Ballot comment]
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, .

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

[Ballot comment]
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.

[Ballot comment]
Thank you, I found this document clear and easy to understand. I did not check the examples, but am assuming that they are accurate.

[Ballot comment]
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?

[Ballot comment]
* 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.

[Ballot comment]
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

[Ballot comment]
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?

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-params-06. If any part of this review is inaccurate, please let us know.

IANA understands that some of the actions requested in the IANA Considerations section of this document are dependent upon the approval of and completion of IANA Actions in another document: [draft-ietf-ace-oauth-authz].

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

First, in the JSON Web Token Claims registry located at:

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

a single, new registration is to be made as follows:

Claim Name: rs_cnf
Claim Description: public key used by RS to authenticate itself to the client
Change Controller: IESG
Reference: [ RFC-to-be Section 3.3]

As this section 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."

Second, 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: rs_cnf
Claim Description: public key used by RS to authenticate itself to the client
JWT Claim Name: rs_cnf
Claim Key: [ TBD-at-Registration ]
Claim Value Type: map
Change Controller: IESG
Reference: [[ RFC-to-be ] Section 3.3]

IANA notes that the authors suggest a value of 41 for this registration.

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."

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

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

the following, three registrations will be made:

Name: req_cnf
Parameter Usage Location: token request
Change Controller: IESG
Reference: [ RFC-to-be Section 5]

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

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

As this section also requests a registration in a Specification Required (see RFC 8126) registry, the IESG-designated experts for the OAuth Parameters 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."

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

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

the following, two registrations will be made:

Name: cnf
Description: Key to prove the right to use a PoP token.
Change Controller: IESG
Reference: [ RFC-to-be Section 4.1]

Name: rs_cnf
Description: public key used by RS to authenticate itself to the client.
Change Controller: IESG
Reference: [ RFC-to-be Section 4.1]

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."

Fifth, in the new registry, "OAuth Parameters CBOR Mappings" established upon approval of [draft-ietf-ace-oauth-authz Section 8.9], three new registrations are to be made as follows:

Name: req_cnf
CBOR key: [ TBD-at-Registration ]
Change Controller: IESG
Reference: [ RFC-to-be Section 3.1 ]

Name: cnf
CBOR key: [ TBD-at-Registration ]
Change Controller: IESG
Reference: [ RFC-to-be Section 3.2 ]

Name: rs_cnf
CBOR key: [ TBD-at-Registration ]
Change Controller: IESG
Reference: [ RFC-to-be Section 3.2 ]

IANA notes that the authors have suggested values of 4 (req_cnf), 8 (cnf) and 41 (rs_cnf) for these new registrations.

Sixth, in the new registry, "OAuth Token Introspection Response CBOR Mappings" established upon approval of [draft-ietf-ace-oauth-authz Section 8.11], two new registrations are to be made as follows:

Name: cnf
CBOR key: [ TBD-at-Registration ]
Change Controller: IESG
Reference: [ RFC-to-be Section 4.1 ]

Name: rs_cnf
CBOR key: [ TBD-at-Registration ]
Change Controller: IESG
Reference: [ RFC-to-be Section 4.1 ]

IANA notes that the authors have suggested values of 8 (cnf) and 41 (rs_cnf) for these new registrations.

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
To: IETF-Announce
CC: ace-chairs@ietf.org, draft-ietf-ace-oauth-params@ietf.org, ietf@augustcellars.com, Jim Schaad , kaduk@mit.edu, ace@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Additional OAuth Parameters for Authorization in Constrained Environments (ACE)) to Proposed Standard


The IESG has received a request from the Authentication and Authorization for
Constrained Environments WG (ace) to consider the following document: -
'Additional OAuth Parameters for Authorization in Constrained
  Environments (ACE)'
  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 new parameters for the OAuth 2.0 token and
  introspection endpoints when used with the framework for
  authentication and authorization for constrained environments (ACE).
  These are used to express the proof-of-possession key the client
  whishes to use, the proof-of-possession key that the AS has selected,
  and the key the RS should use to authenticate to the client.




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

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


No IPR declarations have been submitted directly on this I-D.

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) The document is requested to be a Proposed Standard.  The header
information for the document reflects this.

(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 specification defines new parameters for the OAuth 2.0 token
  and introspection endpoints.  These parameters are targeted for use
  with the OAuth protocol adapted for constrained devices.

Working Group Summary

  This document was created and modified in response to issues raised
  by the OAuth working group.  They deal with a case which the ACE
  OAuth protocol does not currently support, but which is recently
  introduced in OAuth.  This document represents a consensus between
  the two groups.

Document Quality

  There exist at least two implementations which are using these
  fields as part of the overall work.  As noted above there was an
  issue with the OAuth working group but it has been resolved.

Personnel

  Jim Schaad is acting as the Document Shepherd.  Benjamin Kaduk
  is the Responsible Area Director.

(3) I have reviewed and commented on this document as well as the
predecessor work that it was extracted from.  During this review I
checked the document against my code base and walked in detail through
all of the IANA registrations.  I believe that this document is ready
to progress.

(4) I have no concerns with the review of this document.

(5) There are no portions of this document that need extra review.

(6) I have no concerns that the AD should be aware of.

(7) All authors have confirmed that they have no IPR.
**Ludwig** 2/25/19

(8) No IPR disclosures have been filed on this document.

(9) A reasonable percentage of the active members of the working group
have reviewed the document.  The majority of the reviews were from about
six people.

(10) There are not any indications of appeals or extreme discontent.

(11) No ID nits were found.

(12) There is no formal review required.

(13) All references are appropriately normative or informative.

(14) All normative references are either complete or soon to advance
to the IESG

(15) There are no downward normative references.

(16) This document contains all new material and does not modify any
existing RFCs.

(17) I listed each of the different items that were created while doing
a read of the doument and then make sure there was a registration for each
of those items and visa versa.

(18) The document creates no new IANA registeries.

(19) No automated checks were performed on the document.

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) The document is requested to be a Proposed Standard.  The header
information for the document reflects this.

(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 specification defines new parameters for the OAuth 2.0 token
  and introspection endpoints.  These parameters are targeted for use
  with the OAuth protocol adapted for constrained devices.

Working Group Summary

  This document was created and modified in response to issues raised
  by the OAuth working group.  They deal with a case which the ACE
  OAuth protocol does not currently support, but which is recently
  introduced in OAuth.  This document represents a consensus between
  the two groups.

Document Quality

  There exist at least two implementations which are using these
  fields as part of the overall work.  As noted above there was an
  issue with the OAuth working group but it has been resolved.

Personnel

  Jim Schaad is acting as the Document Shepherd.  Benjamin Kaduk
  is the Responsible Area Director.

(3) I have reviewed and commented on this document as well as the
predecessor work that it was extracted from.  During this review I
checked the document against my code base and walked in detail through
all of the IANA registrations.  I believe that this document is ready
to progress.

(4) I have no concerns with the review of this document.

(5) There are no portions of this document that need extra review.

(6) I have no concerns that the AD should be aware of.

(7) All authors have confirmed that they have no IPR.
**Ludwig** 2/25/19

(8) No IPR disclosures have been filed on this document.

(9) A reasonable percentage of the active members of the working group
have reviewed the document.  The majority of the reviews were from about
six people.

(10) There are not any indications of appeals or extreme discontent.

(11) No ID nits were found.

(12) There is no formal review required.

(13) All references are appropriately normative or informative.

(14) All normative references are either complete or soon to advance
to the IESG

(15) There are no downward normative references.

(16) This document contains all new material and does not modify any
existing RFCs.

(17) I listed each of the different items that were created while doing
a read of the doument and then make sure there was a registration for each
of those items and visa versa.

(18) The document creates no new IANA registeries.

(19) No automated checks were performed on the document.

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) The document is requested to be a Proposed Standard.  The header
information for the document reflects this.

(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 specification defines new parameters for the OAuth 2.0 token
  and introspection endpoints.  These parameters are targeted for use
  with the OAuth protocol adapted for constrained devices.

Working Group Summary

  This document was created and modified in response to issues raised
  by the OAuth working group.  They deal with a case which the ACE
  OAuth protocol does not currently support, but which is recently
  introduced in OAuth.  This document represents a consensus between
  the two groups.

Document Quality

  There exist at least two implementations which are using these
  fields as part of the overall work.  As noted above there was an
  issue with the OAuth working group but it has been resolved.

Personnel

  Jim Schaad is acting as the Document Shepherd.  Benjamin Kaduk
  is the Responsible Area Director.

(3) I have reviewed and commented on this document as well as the
predecessor work that it was extracted from.  During this review I
checked the document against my code base and walked in detail through
all of the IANA registrations.  I believe that this document is ready
to progress.

(4) I have no concerns with the review of this document.

(5) There are no portions of this document that need extra review.

(6) I have no concerns that the AD should be aware of.

(7) NO
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) No IPR disclosures have been filed on this document.

(9) A reasonable percentage of the active members of the working group
have reviewed the document.  The majority of the reviews were from about
six people.

(10) There are not any indications of appeals or extreme discontent.

(11) No ID nits were found.

(12) There is no formal review required.

(13) All references are appropriately normative or informative.

(14) All normative references are either complete or soon to advance
to the IESG

(15) There are no downward normative references.

(16) This document contains all new material and does not modify any
existing RFCs.

(17) STILL IN ERROR

** JWT claim name for "rs_cnf" registration in section 9.2

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 document creates no new IANA registeries.

(19) No automated checks were performed on the document.