[Ace] comment on draft-ietf-ace-oauth-authz-26

[Daniel Migault <[e-mail]>]

Hi,

This only concerns potential clarification of the text.

While reviewing mqtt-profile draft I raised an issue regarding the
reference for Oauth [RFC6749] while the remaining of the document
references draft-ietf-ace-oauth-authz [1]. My reading of
draft-ietf-ace-oauth-authz section 5.6.3
<https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-26#section-5.6.3>. was
the same of the one of mqtt-profile coauthors, that is error mandates the
use of CBOR. Discussing this with others it seems a mis interpretation of
draft-ietf-ace-oauth-authz section 5.6.3
<https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-26#section-5.6.3>
[2].

I believe that is nice this is a mis-interpretation, but I would recommend
that the text makes it more explicit the use of JSON is permitted. This
seems to me a request to clarify the text.

Yours,
Daniel

[1]
"""

   In the case of an error, the AS returns error responses for HTTP-
   based interactions as ASCII codes in JSON content, as defined in
   Section 5.2 of RFC 6749
<https://tools.ietf.org/html/rfc6749#section-5.2> [RFC6749
<https://tools.ietf.org/html/rfc6749>].

"""

[2]
"""

5.6.3 <https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-26#section-5.6.3>.
Error Response

   The error responses for CoAP-based interactions with the AS are
   generally equivalent to the ones for HTTP-based interactions as
   defined in Section 5.2 of [RFC6749]
<https://tools.ietf.org/html/rfc6749#section-5.2>, with the following
exceptions:

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

   o  A response code equivalent to the CoAP code 4.00 (Bad Request)
      MUST be used for all error responses, except for invalid_client
      where a response code equivalent to the CoAP code 4.01
      (Unauthorized) MAY be used under the same conditions as specified
      in Section 5.2 of [RFC6749]
<https://tools.ietf.org/html/rfc6749#section-5.2>.

   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.

   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.

   o  The error code (i.e., value of the "error" parameter) MUST be
      abbreviated as specified in Figure 10, when a CBOR encoding is
      used.           /------------------------+-------------\

           | Name                   | CBOR Values |
           |------------------------+-------------|
           | invalid_request        |      1      |
           | invalid_client         |      2      |
           | invalid_grant          |      3      |
           | unauthorized_client    |      4      |
           | unsupported_grant_type |      5      |
           | invalid_scope          |      6      |
           | unsupported_pop_key    |      7      |
           | incompatible_profiles  |      8      |
           \------------------------+-------------/

           Figure 10: CBOR abbreviations for common error codes

   In addition to the error responses defined in OAuth 2.0, the
   following behavior MUST be implemented by the AS:

   o  If the client submits an asymmetric key in the token request that
      the RS cannot process, the AS MUST reject that request with a
      response code equivalent to the CoAP code 4.00 (Bad Request)
      including the error code "unsupported_pop_key" defined in
      Figure 10.

   o  If the client and the RS it has requested an access token for do
      not share a common profile, the AS MUST reject that request with a
      response code equivalent to the CoAP code 4.00 (Bad Request)
      including the error code "incompatible_profiles" defined in
      Figure 10.

"""