On 21/11/2019 03:29, Daniel Migault wrote:
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


I would be happy to add more clarification, but I'm currently at a loss of what that would be. Most of the bullets you cited already modify the MUSTs with "...when CBOR is used" or something similar to the same effect. The idea was to express: You can use the vanilla OAuth interactions based on JSON, but if you use CBOR then do it as specified here.

I am happy to take suggestions.

/Ludwig

[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 inSection 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
       inSection 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
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace



--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Reply via email to