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. """
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
