Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)
draft-ietf-ace-oauth-authz-46

[Ballot comment]
Thanks for addressing my DISCUSS (discussion archived at https://mailarchive.ietf.org/arch/msg/ace/mrVrwJGreSSE2yNJK1uPW0P7p0o/ )

I keep the original ballot below for the leftover non-blocking points 1, 9,  18,  19,  32, 37.

Francesca

========== Original Ballot - 2021-03-24 ==============

Thank you for this document. I think this is an important document which should move forward, but I would like to discuss some points before it does so. These might result in simple clarifications, or might require more discussion, but I do hope they help improve the document.

General comments:

I found confusing to understand how optional or mandatory is the use of CBOR for profiles of this specification compared to the transport used. I understand the need for flexibility, but maybe it should be clarified the implication of using CoAP (is CBOR mandatory then?) vs HTTP (is CBOR always permitted? How is the encoding in that case? Is the same media type application/ace+cbor used in that case?). Note also that while requests include the content type to use, both in case HTTP or CoAP+CBOR are used, the response don't seem to include this information.

I would like it to be clarified what requirements (or even just recommendations) are there to use CoAP vs HTTP for different legs of the exchange - not necessarily remove the flexibility but to clarify for implementers what can be done and what would be the reasoning to do that: for example if both endpoints support HTTP with the AS, most likely you can have HTTP between C and RS, so does it really make sense to run this instead of OAuth 2.0? Right now all is permitted, but does it all make sense? I feel like this type of considerations are missing. As a note - I am not sure what allowing a different encoding than CBOR for any leg of the exchange adds to the specification - it makes things more confusing, and if needed it could be specified in another document.

While going through and thinking about encodings (assuming we keep the doc as is with regards to allowing more than just CBOR), I wondered if it would be better to define a new media type to use when the ACE framework is used with HTTP, to differentiate from OAuth 2.0, since some of the endpoints used are the same (/token and /introspect at the AS). I am interested to hear more from my co-AD as well if this would be an OK use of a new media type - I am thinking of the case where AS is supporting both OAuth 2.0 and the Ace framework - or if it is unnecessary, since the encodings are the same, and the parameters are registered in OAuth 2.0 registry.

More detailed comments below.
Francesca


Detailed comments:

1. -----

  sufficiently compact.  CBOR is a binary encoding designed for small
  code and message size, which may be used for encoding of self
  contained tokens, and also for encoding payloads transferred in
  protocol messages.

FP: "may be used" make it seem as if CBOR is always optional (even when CoAP is used). See points 11. and 13. for examples of text that seem to imply that CBOR is mandatory in some cases.

2. -----

      Refresh tokens are issued to the client by the authorization
      server and are used to obtain a new access token when the current
      access token becomes invalid or expires, or to obtain additional

FP: token validity - it is not clear what it means for a token to become invalid (vs expiring). As this is the first time it is mentioned, it should be explained here or referenced.

3. -----

        An asymmetric key pair is generated on the token's recipient
        and the public key is sent to the AS (if it does not already

          inside the token and sent back to the requesting party.  The
        consumer of the token can identify the public key from the


FP: "token's recipient" and "consumer of the token" - why not talk about client and resource server here? It would fit better with the terminology used in the rest of the document.

4. -----

    This framework RECOMMENDS the use of CoAP as replacement for HTTP for
  use in constrained environments.  For communication security this

FP: This was already stated in the introduction in the following sentence:

  of processing capabilities, available memory, etc.  For web
  applications on constrained nodes, this specification RECOMMENDS the
  use of the Constrained Application Protocol (CoAP) [RFC7252] as
  replacement for HTTP.

Not sure repeating is useful.

5. -----

  OAuth 2.0 (such as [RFC7521] and [RFC8628]).  What grant types works
  best depends on the usage scenario and [RFC7744] describes many
  different IoT use cases but there are two preferred grant types,
  namely the Authorization Code Grant (described in Section 4.1 of

FP: nit: s/works/work . I think "preferred" is probably not the right term here, and should be rephrased or clarified - preferred respect to?

6. -----

      In addition to the response parameters defined by OAuth 2.0 and
      the PoP access token extension, this framework defines parameters
      that can be used to inform the client about capabilities of the
      RS, e.g. the profiles the RS supports.  More information about

FP: I believe this is a leftover from a previous version of the document, but should be "profile" and not "profiles" as the AS is only allowed to communicate one profile to the client and RS - see for example the following sentences:

      The Client and the RS mutually authenticate using the security
      protocol specified in the profile (see step B) and the keys

      The AS informs the client of the selected profile using the
      "ace_profile" parameter in the token response.

7. -----

        (1) the client sends the access token containing, or
        referencing, the authorization information to the RS, that may
        be used for subsequent resource requests by the client, and

FP: s/may/will

8. -----

      While the structure and encoding of the access token varies
      throughout deployments, a standardized format has been defined
      with the JSON Web Token (JWT) [RFC7519] where claims are encoded
      as a JSON object.  In [RFC8392], an equivalent format using CBOR
      encoding (CWT) has been defined.

FP: Would it make sense to RECOMMEND the use of JWT when HTTP is used? Or is CWT always RECOMMENDED?

9. -----

  parameters.  When profiles of this framework use CoAP instead, it is
  REQUIRED to use of the following alternative instead of Uri-query
  parameters: The sender (client or RS) encodes the parameters of its
  request as a CBOR map and submits that map as the payload of the POST
  request.

FP: I think it should be better defined (or at least hinted in this paragraph) the mapping between the CBOR encoded parameters and the Uri-query parameters: are they all encoded as CBOR text strings?

10. -----

  Applications that use this media type: The type is used by
  authorization servers, clients and resource servers that support the
  ACE framework as specified in [this document].

FP: I suggest adding "that support the ACE framework with CBOR encoding, as specified ..."

11. -----

  The OAuth 2.0 AS uses a JSON structure in the payload of its
  responses both to client and RS.  If CoAP is used, it is REQUIRED to
  use CBOR [RFC8949] instead of JSON.  Depending on the profile, the
  CBOR payload MAY be enclosed in a non-CBOR cryptographic wrapper.

FP: This sentence seems to add a requirement (when CoAP is used, then CBOR must be used) only for communication from AS to C or RS. I could not find in the rest of the specification the same type of requirement for the other legs of communication (C to AS, RS to AS, C to RS). Please let me know if I missed it.

12. -----

  the AS authorization is not in scope for this document.  C may, e.g.,
  ask it's owner if this AS is authorized for this RS.  C may also use
  a mechanism that addresses both problems at once.

FP: nit - s/it's/its . Also "C may also use ... at once" such as? I think it would be good to give an example here.

13. -----

  valid access token.  The AS Request Creation Hints message is a CBOR
  map, with an OPTIONAL element "AS" specifying an absolute URI (see

FP: another case where CBOR seem mandatory.. Is this the case, even if HTTP or other protocol is used?

14. -----

      MUST discard the access token.  If this was an interaction with
      the authz-info endpoint the RS MUST also respond with an error
      message using a response code equivalent to the CoAP code 4.01
      (Unauthorized).

FP: This seems to imply that another endpoint could be used to receive an access token. Is that the case, and if so where is this defined?

15. -----

Section 5.8:

  If HTTPS is used, JSON or CBOR payloads may be supported.  If JSON
  payloads are used, the semantics of Section 4 of the OAuth 2.0
  specification MUST be followed (with additions as described below).

FP: I suggest to point to the specific subsection in OAuth - namely 4.1.3 and 4.1.4

16. -----

  If CBOR is used then these parameters MUST be provided as a CBOR map.

FP: s/as/in . I suggest to reference Figure 12.

17. -----

  the HTTP request entity-body, as defined in section 3.2 of [RFC6749].

FP: Section 3.2 of OAuth 2.0 specifies:

  The endpoint URI MAY include an "application/x-www-form-urlencoded"
  formatted (per Appendix B) query component ([RFC3986] Section 3.4),
  which MUST be retained when adding additional query parameters.  The
  endpoint URI MUST NOT include a fragment component.

which explicitly specifies that the parameters are transported as query components. I either suggest to change this reference to Appendix B of RFC6749.

18. -----

        "x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8'

FP: noted here since this is the first time it appears, but same comment for the rest of the document. I think it would make more sense to show examples where CBOR byte strings are used instead of Base64.

19. -----

  Figure 8 summarizes the parameters that can currently be part of the
  Access Information.  Future extensions may define additional
  parameters.

FP: This is useful! Why not having the same type of figure listing all acceptable parameters for the request (section 5.8.1)?

20. -----

  Header: Created (Code=2.01)
  Content-Format: "application/ace+cbor"
  Payload:
  {
    "access_token" : b64'SlAV32hkKG ...
      (remainder of CWT omitted for brevity;
      CWT contains COSE_Key in the "cnf" claim)',
    "ace_profile" : "coap_dtls",
    "expires_in" : "3600",
    "cnf" : {
      "COSE_Key" : {
        "kty" : "Symmetric",
        "kid" : b64'39Gqlw',
        "k" : b64'hJtXhkV8FJG+Onbc6mxCcQh'
      }
    }
  }

      Figure 9: Example AS response with an access token bound to a
                              symmetric key.

FP: Section 3.1 states:

      Symmetric PoP key:
        The AS generates a random symmetric PoP key.  The key is either
        stored to be returned on introspection calls or encrypted and
        included in the token.  The PoP key is also encrypted for the
        token recipient and sent to the recipient together with the
        token.

But in the example the key is not encrypted.

21. -----

  o  When using CBOR the raw payload before being processed by the
      communication security protocol MUST be encoded as a CBOR map.


FP: I don't understand "before being processed by the communication security protocol"

22. -----

  o  The Content-Format (for CoAP-based interactions) or media type
      (for HTTP-based interactions) "application/ace+cbor" MUST be used
      for the error response.

FP: Does this mean that CBOR is always used for errors? However in the same section:

  o  The parameters "error", "error_description" and "error_uri" MUST
      be abbreviated using the codes specified in Figure 12, when a CBOR
      encoding is used.

"when a CBOR encoding is used" so not always?

23. -----

Sections 5.8.2, 5.8.3, 5.9.1, 5.9.2, 5.9.3, 5.10.1

FP: I found useful that Section 5.8.1 spelled out the encoding when HTTP is used (See sentence below). I think it would be as useful to have the same type of phrasing in these and following sections (wherever it is missing now). I think in general it is very clear in the document what format the message has when CBOR is used, and it seems that CBOR can be used with HTTP according to this specification (but not sure it is actually recommended, what are the pros and cons). In some sections (5.8.2, 5.8.3, etc) it is left to implicit references to OAuth 2.0 for the implementers to figure out what the encoding is (and what media type is used), although modifications are added to it.

  When HTTP is used as a transport then the client makes a request to
  the token endpoint by sending the parameters using the "application/
  x-www-form-urlencoded" format with a character encoding of UTF-8 in
  the HTTP request entity-body, as defined in section 3.2 of [RFC6749].

24. -----

      including the error code "unsupported_pop_key" defined in
      Figure 10.

      including the error code "incompatible_ace_profiles" defined in
      Figure 10.

FP: nit - these error codes are not "defined" in figure 10.

25. -----

  In this framework the "pop" value for the "token_type" parameter is
  the default.  The AS may, however, provide a different value.

FP: I would change the sentence to:

  In this framework the "pop" value for the "token_type" parameter is
  the default.  The AS may, however, provide a different value from those registered in [IANA registry].

26. -----

  Clients that want the AS to provide them with the "ace_profile"
  parameter in the access token response can indicate that by sending a
  ace_profile parameter with a null value (for CBOR-based interactions)
  or an empty string (for JSON based interactions) in the access token
  request.

      Hints Section 5.3.  The parameter is encoded as a byte string for
  CBOR-based interactions, and as a string (Base64 encoded binary) for
  JSON-based interactions.

FP: OAuth 2.0 section 4.1.3 says that JSON is not used, the parameters are encoded using "application/x-www-form-urlencoded"
format in the request entity-body.

27. -----

  The figures of this section uses CBOR diagnostic notation without the

FP: Nit - s/use

28. -----

  A client using this method MUST make a POST request to the authz-info
  endpoint at the RS with the access token in the payload.  The RS

FP: The formatting of the request is unclear - could you clarify that it depends on the access token used, and the media type (or content format) needs to reflect that? I.e. if CWT is used, the media type MUST be application/cwt.

29. -----

  o  If token or claim verification fails, the RS MUST discard the
      token and, if this was an interaction with authz-info, return an
      error message with a response code equivalent to the CoAP code

FP: Same comment as before, "if this was an interaction with authz-info" - the alternative needs to be clarified.

30. -----

  Errors may happen during this initial processing stage:

  o  If token or claim verification fails, the RS MUST discard the
      token and, if this was an interaction with authz-info, return an
      error message with a response code equivalent to the CoAP code
      4.01 (Unauthorized).

      ...

  Next, the RS MUST verify claims, if present, contained in the access
  token.  Errors are returned when claim checks fail, in the order of
  priority of this list:

FP: It seems weird to read first about errors due to claim verification, and then "Next" discuss claim verification - unless this is two different claim verifications, in which case I think this needs to be clarified. Also in each claim:

      the RS MUST discard the token.  If this was an interaction with
      authz-info, the RS MUST also respond with a response code
      equivalent to the CoAP code 4.01 (Unauthorized).

Seems like a repeat of the sentence above.

31. -----

  on the authz-info endpoint and on it's children (if any).

FP: nit - s/it's/its

32. -----

  The POST method SHOULD NOT be allowed on children of the authz-info
  endpoint.

FP: What children? They do not seem to be defined, so I do not understand this sentence.

33. -----

        +  When creating the token, the AS MUST add a 'cti' claim ( or
            'jti' for JWTs) to the access token.  The value of this

FP: Since the use of CWT and JWT are only recommended, it might be good to rephrase this as to allow for other access token's encodings too.

34. -----

        +  When creating the token, the AS MUST add a 'cti' claim ( or
            'jti' for JWTs) to the access token.  The value of this
            claim MUST be created as the binary representation of the
            concatenation of the identifier of the RS with a sequence
            number counting the tokens containing an 'exi' claim, issued
            by this AS for the RS.

        +  The RS MUST store the highest sequence number of an expired
            token containing the "exi" claim that it has seen, and treat
            tokens with lower sequence numbers as expired.

FP: A question rather than a comment - I am not sure I understand this. An "exi" value might be higher for a different token (with a lower sequence number), so how does the counter of the tokens help? Wouldn't that make the RS discard a valid token just because it has a lower sequence number?

35. -----

  RS.  Therefore, C must not communicate with an AS if it cannot
  determine that this AS has the authority to issue access tokens for
  this RS.  Otherwise, a compromised RS may use this to perform a

FP: How is C supposed to determine that? Doesn't this sentence make the whole AS Creation Hints response useless - either the client already knows, or it doesn't and it must not communicate with it regardless of RS says?

36. -----

  compromised.  In order to prevent this, an RS may use the nonce-based
  mechanism defined in Section 5.3 to ensure freshness of an Access

FP: please mention "cnonce" to make it easier to find.

37. -----

  There may be use cases were different profiles of this framework are
  combined.  For example, an MQTT-TLS profile is used between the
  client and the RS in combination with a CoAP-DTLS profile for
  interactions between the client and the AS.  The security of a
  profile MUST NOT depend on the assumption that the profile is used
  for all the different types of interactions in this framework.

FP: This seems strange - maybe I just don't understand how this is supposed to work, but each profile defines exactly at least C - RS communication and security, if several are combined, it seems that at least the C-RS would conflict.

[Ballot comment]
One minor comment:  I found it a slight leap in the introduction in the final paragraph ("More detailed, ...") that talks about interoperable specifications (implying that specification is not interoperable) and profiles (where it isn't clear where these have come from).  So, an extra sentence to bridge the concepts might be helpful in the introduction.  As a nit, the paragraph is also missing a comma in "interoperate while".

[Ballot comment]
Section 1, paragraph 3, comment:
>    of processing capabilities, available memory, etc.  For web
>    applications on constrained nodes, this specification RECOMMENDS the
>    use of the Constrained Application Protocol (CoAP) [RFC7252] as
>    replacement for HTTP.

Since the rest of this section is pretty careful in explaining that there is a
capability spectrum for IoT devices, I was surprised about this broad
recommendation against HTTP (which is also repeated elsewhere in the text.)

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

Stewart Bryant's Gen-ART review
(https://mailarchive.ietf.org/arch/msg/gen-art/04lPOKG404s-LNfVm40ZE8s-Wig/)
contained some nits that I wanted to make sure you were aware of.

"Table of Contents", paragraph 1, nit:
> Table of Contents

Some sections don't use title case.

Section 4, paragraph 9, nit:
-    In Bluetooth Low Energy, for example, advertisements are broadcasted
-                                                                      --
+    In Bluetooth Low Energy, for example, advertisements are broadcast

Section 5.3, paragraph 15, nit:
-    freshness nevetheless, the RS has included a "cnonce" parameter (see
+    freshness nevertheless, the RS has included a "cnonce" parameter (see
+                  +

"Appendix E.", paragraph 33, nit:
-      as playload the Access Information, including the access token and
-          -
+      as payload the Access Information, including the access token and

[Ballot comment]
I share Eric V's concern about the apparently stale nature of the shepherd writeup.  It seems to be a common oversight lately.

I also agree with Eric about Section 3.  Nicely done.

Since I'm getting to this document last in our queue this week, I find I have little to contribute here that my colleagues didn't already include in their positions, save this one gem:

Section 8.2 should probably say explicitly that the registration should refer to this document, since that is a column of the registry to which you are adding an entry.

[Ballot discuss]
Thank you for this document. I think this is an important document which should move forward, but I would like to discuss some points before it does so. These might result in simple clarifications, or might require more discussion, but I do hope they help improve the document.

General comments:

I found confusing to understand how optional or mandatory is the use of CBOR for profiles of this specification compared to the transport used. I understand the need for flexibility, but maybe it should be clarified the implication of using CoAP (is CBOR mandatory then?) vs HTTP (is CBOR always permitted? How is the encoding in that case? Is the same media type application/ace+cbor used in that case?). Note also that while requests include the content type to use, both in case HTTP or CoAP+CBOR are used, the response don't seem to include this information.

I would like it to be clarified what requirements (or even just recommendations) are there to use CoAP vs HTTP for different legs of the exchange - not necessarily remove the flexibility but to clarify for implementers what can be done and what would be the reasoning to do that: for example if both endpoints support HTTP with the AS, most likely you can have HTTP between C and RS, so does it really make sense to run this instead of OAuth 2.0? Right now all is permitted, but does it all make sense? I feel like this type of considerations are missing. As a note - I am not sure what allowing a different encoding than CBOR for any leg of the exchange adds to the specification - it makes things more confusing, and if needed it could be specified in another document.

While going through and thinking about encodings (assuming we keep the doc as is with regards to allowing more than just CBOR), I wondered if it would be better to define a new media type to use when the ACE framework is used with HTTP, to differentiate from OAuth 2.0, since some of the endpoints used are the same (/token and /introspect at the AS). I am interested to hear more from my co-AD as well if this would be an OK use of a new media type - I am thinking of the case where AS is supporting both OAuth 2.0 and the Ace framework - or if it is unnecessary, since the encodings are the same, and the parameters are registered in OAuth 2.0 registry.

More detailed comments below.
Francesca

[Ballot comment]
Detailed comments:

1. -----

  sufficiently compact.  CBOR is a binary encoding designed for small
  code and message size, which may be used for encoding of self
  contained tokens, and also for encoding payloads transferred in
  protocol messages.

FP: "may be used" make it seem as if CBOR is always optional (even when CoAP is used). See points 11. and 13. for examples of text that seem to imply that CBOR is mandatory in some cases.

2. -----

      Refresh tokens are issued to the client by the authorization
      server and are used to obtain a new access token when the current
      access token becomes invalid or expires, or to obtain additional

FP: token validity - it is not clear what it means for a token to become invalid (vs expiring). As this is the first time it is mentioned, it should be explained here or referenced.

3. -----

        An asymmetric key pair is generated on the token's recipient
        and the public key is sent to the AS (if it does not already

          inside the token and sent back to the requesting party.  The
        consumer of the token can identify the public key from the


FP: "token's recipient" and "consumer of the token" - why not talk about client and resource server here? It would fit better with the terminology used in the rest of the document.

4. -----

    This framework RECOMMENDS the use of CoAP as replacement for HTTP for
  use in constrained environments.  For communication security this

FP: This was already stated in the introduction in the following sentence:

  of processing capabilities, available memory, etc.  For web
  applications on constrained nodes, this specification RECOMMENDS the
  use of the Constrained Application Protocol (CoAP) [RFC7252] as
  replacement for HTTP.

Not sure repeating is useful.

5. -----

  OAuth 2.0 (such as [RFC7521] and [RFC8628]).  What grant types works
  best depends on the usage scenario and [RFC7744] describes many
  different IoT use cases but there are two preferred grant types,
  namely the Authorization Code Grant (described in Section 4.1 of

FP: nit: s/works/work . I think "preferred" is probably not the right term here, and should be rephrased or clarified - preferred respect to?

6. -----

      In addition to the response parameters defined by OAuth 2.0 and
      the PoP access token extension, this framework defines parameters
      that can be used to inform the client about capabilities of the
      RS, e.g. the profiles the RS supports.  More information about

FP: I believe this is a leftover from a previous version of the document, but should be "profile" and not "profiles" as the AS is only allowed to communicate one profile to the client and RS - see for example the following sentences:

      The Client and the RS mutually authenticate using the security
      protocol specified in the profile (see step B) and the keys

      The AS informs the client of the selected profile using the
      "ace_profile" parameter in the token response.

7. -----

        (1) the client sends the access token containing, or
        referencing, the authorization information to the RS, that may
        be used for subsequent resource requests by the client, and

FP: s/may/will

8. -----

      While the structure and encoding of the access token varies
      throughout deployments, a standardized format has been defined
      with the JSON Web Token (JWT) [RFC7519] where claims are encoded
      as a JSON object.  In [RFC8392], an equivalent format using CBOR
      encoding (CWT) has been defined.

FP: Would it make sense to RECOMMEND the use of JWT when HTTP is used? Or is CWT always RECOMMENDED?

9. -----

  parameters.  When profiles of this framework use CoAP instead, it is
  REQUIRED to use of the following alternative instead of Uri-query
  parameters: The sender (client or RS) encodes the parameters of its
  request as a CBOR map and submits that map as the payload of the POST
  request.

FP: I think it should be better defined (or at least hinted in this paragraph) the mapping between the CBOR encoded parameters and the Uri-query parameters: are they all encoded as CBOR text strings?

10. -----

  Applications that use this media type: The type is used by
  authorization servers, clients and resource servers that support the
  ACE framework as specified in [this document].

FP: I suggest adding "that support the ACE framework with CBOR encoding, as specified ..."

11. -----

  The OAuth 2.0 AS uses a JSON structure in the payload of its
  responses both to client and RS.  If CoAP is used, it is REQUIRED to
  use CBOR [RFC8949] instead of JSON.  Depending on the profile, the
  CBOR payload MAY be enclosed in a non-CBOR cryptographic wrapper.

FP: This sentence seems to add a requirement (when CoAP is used, then CBOR must be used) only for communication from AS to C or RS. I could not find in the rest of the specification the same type of requirement for the other legs of communication (C to AS, RS to AS, C to RS). Please let me know if I missed it.

12. -----

  the AS authorization is not in scope for this document.  C may, e.g.,
  ask it's owner if this AS is authorized for this RS.  C may also use
  a mechanism that addresses both problems at once.

FP: nit - s/it's/its . Also "C may also use ... at once" such as? I think it would be good to give an example here.

13. -----

  valid access token.  The AS Request Creation Hints message is a CBOR
  map, with an OPTIONAL element "AS" specifying an absolute URI (see

FP: another case where CBOR seem mandatory.. Is this the case, even if HTTP or other protocol is used?

14. -----

      MUST discard the access token.  If this was an interaction with
      the authz-info endpoint the RS MUST also respond with an error
      message using a response code equivalent to the CoAP code 4.01
      (Unauthorized).

FP: This seems to imply that another endpoint could be used to receive an access token. Is that the case, and if so where is this defined?

15. -----

Section 5.8:

  If HTTPS is used, JSON or CBOR payloads may be supported.  If JSON
  payloads are used, the semantics of Section 4 of the OAuth 2.0
  specification MUST be followed (with additions as described below).

FP: I suggest to point to the specific subsection in OAuth - namely 4.1.3 and 4.1.4

16. -----

  If CBOR is used then these parameters MUST be provided as a CBOR map.

FP: s/as/in . I suggest to reference Figure 12.

17. -----

  the HTTP request entity-body, as defined in section 3.2 of [RFC6749].

FP: Section 3.2 of OAuth 2.0 specifies:

  The endpoint URI MAY include an "application/x-www-form-urlencoded"
  formatted (per Appendix B) query component ([RFC3986] Section 3.4),
  which MUST be retained when adding additional query parameters.  The
  endpoint URI MUST NOT include a fragment component.

which explicitly specifies that the parameters are transported as query components. I either suggest to change this reference to Appendix B of RFC6749.

18. -----

        "x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8'

FP: noted here since this is the first time it appears, but same comment for the rest of the document. I think it would make more sense to show examples where CBOR byte strings are used instead of Base64.

19. -----

  Figure 8 summarizes the parameters that can currently be part of the
  Access Information.  Future extensions may define additional
  parameters.

FP: This is useful! Why not having the same type of figure listing all acceptable parameters for the request (section 5.8.1)?

20. -----

  Header: Created (Code=2.01)
  Content-Format: "application/ace+cbor"
  Payload:
  {
    "access_token" : b64'SlAV32hkKG ...
      (remainder of CWT omitted for brevity;
      CWT contains COSE_Key in the "cnf" claim)',
    "ace_profile" : "coap_dtls",
    "expires_in" : "3600",
    "cnf" : {
      "COSE_Key" : {
        "kty" : "Symmetric",
        "kid" : b64'39Gqlw',
        "k" : b64'hJtXhkV8FJG+Onbc6mxCcQh'
      }
    }
  }

      Figure 9: Example AS response with an access token bound to a
                              symmetric key.

FP: Section 3.1 states:

      Symmetric PoP key:
        The AS generates a random symmetric PoP key.  The key is either
        stored to be returned on introspection calls or encrypted and
        included in the token.  The PoP key is also encrypted for the
        token recipient and sent to the recipient together with the
        token.

But in the example the key is not encrypted.

21. -----

  o  When using CBOR the raw payload before being processed by the
      communication security protocol MUST be encoded as a CBOR map.


FP: I don't understand "before being processed by the communication security protocol"

22. -----

  o  The Content-Format (for CoAP-based interactions) or media type
      (for HTTP-based interactions) "application/ace+cbor" MUST be used
      for the error response.

FP: Does this mean that CBOR is always used for errors? However in the same section:

  o  The parameters "error", "error_description" and "error_uri" MUST
      be abbreviated using the codes specified in Figure 12, when a CBOR
      encoding is used.

"when a CBOR encoding is used" so not always?

23. -----

Sections 5.8.2, 5.8.3, 5.9.1, 5.9.2, 5.9.3, 5.10.1

FP: I found useful that Section 5.8.1 spelled out the encoding when HTTP is used (See sentence below). I think it would be as useful to have the same type of phrasing in these and following sections (wherever it is missing now). I think in general it is very clear in the document what format the message has when CBOR is used, and it seems that CBOR can be used with HTTP according to this specification (but not sure it is actually recommended, what are the pros and cons). In some sections (5.8.2, 5.8.3, etc) it is left to implicit references to OAuth 2.0 for the implementers to figure out what the encoding is (and what media type is used), although modifications are added to it.

  When HTTP is used as a transport then the client makes a request to
  the token endpoint by sending the parameters using the "application/
  x-www-form-urlencoded" format with a character encoding of UTF-8 in
  the HTTP request entity-body, as defined in section 3.2 of [RFC6749].

24. -----

      including the error code "unsupported_pop_key" defined in
      Figure 10.

      including the error code "incompatible_ace_profiles" defined in
      Figure 10.

FP: nit - these error codes are not "defined" in figure 10.

25. -----

  In this framework the "pop" value for the "token_type" parameter is
  the default.  The AS may, however, provide a different value.

FP: I would change the sentence to:

  In this framework the "pop" value for the "token_type" parameter is
  the default.  The AS may, however, provide a different value from those registered in [IANA registry].

26. -----

  Clients that want the AS to provide them with the "ace_profile"
  parameter in the access token response can indicate that by sending a
  ace_profile parameter with a null value (for CBOR-based interactions)
  or an empty string (for JSON based interactions) in the access token
  request.

      Hints Section 5.3.  The parameter is encoded as a byte string for
  CBOR-based interactions, and as a string (Base64 encoded binary) for
  JSON-based interactions.

FP: OAuth 2.0 section 4.1.3 says that JSON is not used, the parameters are encoded using "application/x-www-form-urlencoded"
format in the request entity-body.

27. -----

  The figures of this section uses CBOR diagnostic notation without the

FP: Nit - s/use

28. -----

  A client using this method MUST make a POST request to the authz-info
  endpoint at the RS with the access token in the payload.  The RS

FP: The formatting of the request is unclear - could you clarify that it depends on the access token used, and the media type (or content format) needs to reflect that? I.e. if CWT is used, the media type MUST be application/cwt.

29. -----

  o  If token or claim verification fails, the RS MUST discard the
      token and, if this was an interaction with authz-info, return an
      error message with a response code equivalent to the CoAP code

FP: Same comment as before, "if this was an interaction with authz-info" - the alternative needs to be clarified.

30. -----

  Errors may happen during this initial processing stage:

  o  If token or claim verification fails, the RS MUST discard the
      token and, if this was an interaction with authz-info, return an
      error message with a response code equivalent to the CoAP code
      4.01 (Unauthorized).

      ...

  Next, the RS MUST verify claims, if present, contained in the access
  token.  Errors are returned when claim checks fail, in the order of
  priority of this list:

FP: It seems weird to read first about errors due to claim verification, and then "Next" discuss claim verification - unless this is two different claim verifications, in which case I think this needs to be clarified. Also in each claim:

      the RS MUST discard the token.  If this was an interaction with
      authz-info, the RS MUST also respond with a response code
      equivalent to the CoAP code 4.01 (Unauthorized).

Seems like a repeat of the sentence above.

31. -----

  on the authz-info endpoint and on it's children (if any).

FP: nit - s/it's/its

32. -----

  The POST method SHOULD NOT be allowed on children of the authz-info
  endpoint.

FP: What children? They do not seem to be defined, so I do not understand this sentence.

33. -----

        +  When creating the token, the AS MUST add a 'cti' claim ( or
            'jti' for JWTs) to the access token.  The value of this

FP: Since the use of CWT and JWT are only recommended, it might be good to rephrase this as to allow for other access token's encodings too.

34. -----

        +  When creating the token, the AS MUST add a 'cti' claim ( or
            'jti' for JWTs) to the access token.  The value of this
            claim MUST be created as the binary representation of the
            concatenation of the identifier of the RS with a sequence
            number counting the tokens containing an 'exi' claim, issued
            by this AS for the RS.

        +  The RS MUST store the highest sequence number of an expired
            token containing the "exi" claim that it has seen, and treat
            tokens with lower sequence numbers as expired.

FP: A question rather than a comment - I am not sure I understand this. An "exi" value might be higher for a different token (with a lower sequence number), so how does the counter of the tokens help? Wouldn't that make the RS discard a valid token just because it has a lower sequence number?

35. -----

  RS.  Therefore, C must not communicate with an AS if it cannot
  determine that this AS has the authority to issue access tokens for
  this RS.  Otherwise, a compromised RS may use this to perform a

FP: How is C supposed to determine that? Doesn't this sentence make the whole AS Creation Hints response useless - either the client already knows, or it doesn't and it must not communicate with it regardless of RS says?

36. -----

  compromised.  In order to prevent this, an RS may use the nonce-based
  mechanism defined in Section 5.3 to ensure freshness of an Access

FP: please mention "cnonce" to make it easier to find.

37. -----

  There may be use cases were different profiles of this framework are
  combined.  For example, an MQTT-TLS profile is used between the
  client and the RS in combination with a CoAP-DTLS profile for
  interactions between the client and the AS.  The security of a
  profile MUST NOT depend on the assumption that the profile is used
  for all the different types of interactions in this framework.

FP: This seems strange - maybe I just don't understand how this is supposed to work, but each profile defines exactly at least C - RS communication and security, if several are combined, it seems that at least the C-RS would conflict.

[Ballot comment]
Thanks for working on this document. I found the overview section very helpful to setup the knowledge required to absorb the rest of the document.

I have following observations and/or nits, hopefully this will improve this document -

* Section 1:
    For web
    applications on constrained nodes, this specification RECOMMENDS the
    use of the Constrained Application Protocol (CoAP) [RFC7252] as
    replacement for HTTP.

  I can't parse the normative text "RECOMMENDS " :-). I believe if normative text is used here then "RECOMMEND" or "RECOMMENDED" should be used. By the way, there are more occurrence of "RECOMMENDS " in this document. The same comment applied for those occurrences .


* Section 2 : I would suggest to drop "we use" from the beginning of last two paragraphs in this section and write those paraphaphs in passive form to harmonize with rest of the section.

* Section 3.1 :
      Introspection is a method for a resource server to query the
      authorization server for the active state and content of a
      received access token.  This is particularly useful in those cases
      where the authorization decisions are very dynamic and/or where
      the received access token itself is an opaque reference rather
      than a self-contained token.  More information about introspection
      in OAuth 2.0 can be found in [RFC7662].

  I got gradually introduced in this document that potentially the client can also use the method to query for more information (Section 5.9) via RS. I think it will be helpful if this is described early that RS and client both can use the introspection offered by AS.

* Section 4 : Figure 1
 
  The use of (optional) here is a bit confusing. The (optional) tag in (B) means it is optional to include refresh token. For (D) and (E) the meaning of (optional) is completely different. The response to the Introspection Request is not optional, is it?.. but that interaction between AS and RS is optional. It might be good to separate the use of "optional" in this figure / or amend the figure in a different way to avoid such confusion.


* Section 5.2 :

      The request has been received on an unprotected channel.

  The definition of "unprotected" would be appropriated here. does this refer to secure communication channel?

* Section 5.10.1. :
  Typo : s/Section Section / Section

[Ballot comment]
Thank you to Stephen Kent for the SECDIR review, and thank you to the authors for responding to it.

** Section 5.3.  Per “The RS sending this response (i.e., RS) uses an internal clock that is only loosely synchronized with the clock of the AS”, a more precise phrase that “loosely synchronized” would be helpful.

** Section 6.2.  It would be worthwhile to clarify the following:

Section 6.2.
(a) Developers MUST ensure that ephemeral credentials … are not leaked to third parties.

(b) An
  adversary in possession of the ephemeral credentials bound to the
  access token will be able to impersonate the client.  Be aware that
  this is a real risk with many constrained environments, since
  adversaries can often easily get physical access to the devices.

(a) is helpful guidance; and independently (b) is a good reminder.  However, the risk of a leak to a third party seems independent of getting physical access.

** Section 6.4.  Per “C therefore MUST determine if an AS is authorized to provide access tokens for a certain RS.”, this is good advice.  Additionally, it should be clarified that the means for a C to determine if the AS has the authority to issue access tokens for a given RS is left to the application and out of scope of this document.

** Fully appreciating that this document is already quite long, consider whether it would be helpful to implementers to add another block of text to explicitly enumerate how this framework alters OAuth.  For example:
==[ snip ]==

This document adapts OAuth v2 to be suitable for the IoT environment.  In particular it differs from the normative requirements of OAuth in the following ways:

*    Use of TLS -- OAuth 2.0 requires the use of TLS both to protect the communication between AS and client when requesting an access token; between client and RS when accessing a resource and between AS and RS if introspection is used.  This framework requires similar security properties, but does not require that they be realized with TLS.  Section 5.

* Cardinality of grant_type parameter -- In client-to-AS requests using OAuth 2.0, the grant_type parameter is required (per [RFC6749]).  In this framework, this parameter is optional.  See Section 5.8.1.

* Encoding of scope parameter – In client-to-AS requests using OAuth 2.0, the scope parameter is string encoded (per [RFC6749]).  In this framework, this parameter may also be encoded as a byte string.  See Section 5.8.1.

* Cardinality of token_type parameter – in AS-to-client responses using OAuth 2.0, the token_type parameter is required (per [RFC 6749]).  In this framework, this parameter is optional.  See Section 5.8.2.

* Access token retention – in OAuth 2.0, the access token is sent with each request to the RS.  In this framework, the RS must be able to store these tokens for later use.  See Section 5.10.1.

==[ end ]==

** Would the first paragraph of Section 7.2 of draft-ietf-ace-dtls-authorize providing caution about the challenges of multiple access tokens be better served by placing it in this document?  Section 7 of draft-ietf-ace-oscore-profile has similar words too.

** Editorial Nits

-- Section 3.1.  Typo.  s/token token/token/

-- Section 5.3. Typo s/nevetheless/nevertheless/

-- Section 6.6. Typo s/loose the current/lose the current/

-- Section 6.6. Typo s/the the/the/

[Ballot comment]
[[ comments ]]

[ section 5.10.3 ]

* It seems to me that making the described expired token list behaviour
  a MUST may be overspecifying things.  Is there some reason it can't be
  downgraded to SHOULD?

  Also: does this described algorithm rely upon all exi values being
  essentially the same?  I was thinking about expires_in values varying
  wildly (for whatever reason) and I wasn't sure how this sequence number
  tracking would work in that case.

[ section 6.6 ]

* I presume another alternative is for the RS to delay (or postpone with
  some error code?) request handling until time synchronization (NTP, NITZ,
  ...) has completed (even if only the time is sync'd/stepped and no other
  parameters are coordinated).


[[ nits ]]

[ section 5.8.1 ]

* "in order allow" -> "in order to allow"

* ", specifically" > probably two separate sentences reads more clearly.
  ". Specifically"

* "}W" -> "}"?

* "can only use to" -> "can only be used to"?

[ section 6.6 ]

* "loose" -> "lose"

[Ballot comment]
Thank you for the work put into this document. I have really appreciated the informative and concise section 3 "overview". The flow and the explanations are really superb: if only all published RFC could have this level of quality ;-)

While I appreciate that the document shepherd was the past Jim Schaad, I find it weird to read a shepherd's review is for the -21 revision while the balloted revision is -38 as I usually rely on those write-ups to get an idea about the WG consensus...
Anyway I am trusting the responsible AD for this I-D.

Side note: due to lack of time, I have skipped the security and IANA considerations sections as I trust the responsible AD.

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

Last very minor/cosmetic comment about this document as well to the oAuth terminology: using "refresh tokens" sounds weird to me, I would have preferred "permanent tokens" or "long-term tokens", but, I am afraid that the train has left the station for many years ;-) And the same applies for "introspection" that usually is done internally and does not require a third party as in oAuth (but this is another train, which has also left the station...).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 3 --
Should references/expansions be added for "HTTP/2, MQTT, BLE and QUIC" ?

-- Section 3.1 --
Suggest to review the order of the definitions, notably popping up "introspection" as it is used by most of the other terms.

-- Section 4 --
Mostly cosmetic, any reason why figure 1 is so far away from its mention in §1 ?

In "ensure that its content cannot be modified, and if needed, that the content is confidentiality protected", I wonder why the confidentiality is only optional ? As far as I understand it, the possession of an access token grants access to a ressource, so, it should be protected against sniffing. What did I miss ?

In "If the AS successfully processes the request from the client" may look ambiguous because processing correctly (per protocol) an invalid credential is also "successfully processed". Suggest to mention something about "positive authentication" ;)

-- Section 5 --
As a non-English native speaker, I cannot see the verb in the second proposition in "For IoT, it cannot be assumed that the client and RS are part of a common key infrastructure, so the AS provisions credentials or associated information to allow mutual authentication.". While I obviously understand the meaning, could it be rephrased ?

-- Section 5.1.1 --
Could the word "unprotected" be better defined in "received on an unprotected channel" ? E.g., is it only about TLS ? Else, I like the implicit lack of trust.

-- Section 5.1.2 --
I must admit that I have failed to understand the semantic of "audience"... Can you either explain its meaning or provide a reference ?

-- Section 5.5 --
In "Since it requires the use of a user agent (i.e., browser)" is it "i.e." or "e.g." ?

-- Section 5.6 --
s/the semantics described below MUST be/the semantics described in this section MUST be/ ?

In "The default name of this endpoint in an url-path is '/token'" should "SHOULD" normative language be used ?

-- Section 5.6.4.1 --
In figure 11, would you mind adding the section ID in addition to RFC 6749 ? I failed to spot them in RFC 6749.

-- Section 5.7.2 --
It is a little unclear to me which profile must be used as 'profile' is optionnial? Should a default or any profile be used ?

-- Section 5.8.1 --
Suggest to use the BCP14 "SHOULD" in the text "The default name of this endpoint in an url-path is '/authz-info'"

-- Section 10.2 --
Is RFC 7049 really an informative reference as CBOR appears as the default encoding ?
     
== NITS ==

s/application layer protocol/application-layer protocol/ ?

Should multi-words message names (e.g.,  AS Request Creation Hints) be enclosed by quotes ?

-- Section 2 --
Please introduce "authz-info" before first use.

-- Section 3.1 --
"PoP" is expanded twice in this section ;-)

"CBOR encoding (CWT) " the "CWT" acronym does not match the expansion :-)

-- Section 4 --

Sometimes "Client" is used and sometimes "client" is used...

s/reference to a specific credential/reference to a specific access credential/ ?

-- Section 5.1.2 --
Can you introduce to "kid" acronym ? It too me a while to understand that it is (probably) key-id... :-)

Unsure whether "nonce: h'e0a156bb3f'," is the usual IETF way to introduce an hexadecimal number.

typo in "5.8.4.  Key Expriation" :-)

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
To: IETF-Announce
CC: ace-chairs@ietf.org, ietf@augustcellars.com, draft-ietf-ace-oauth-authz@ietf.org, Jim Schaad , kaduk@mit.edu, ace@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (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)'
  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.