Hello, Ludwig, I agree that the current draft describes specifically for when CBOR is used. When CBOR is not used, I have read it as it will act similar to Section 5.2 of [RFC6749] <https://tools.ietf.org/html/rfc6749#section-5.2> as you have indicated also in the ace-oauth-authz document.
Therefore, instead of an indirect reference to RFC6749 by referencing ace-oauth-authz, we used a direct reference to explain what the error response should be. Is this problematic? or confusing? I can reword in mqtt_tls draft something like: "As described in [ace-oauth-authz] the error responses for JSON-based interactions with AS follow RFC6749. When CBOR is used, the interactions MUST implement [ace-oauth-authz]" Would that help? Thanks, --Cigdem On Thu, Nov 21, 2019 at 3:06 AM Daniel Migault <daniel.migault= 40ericsson....@dmarc.ietf.org> wrote: > Hi Ludwig, > > Thanks for the feed back. I was raising the issue before it got forgotten. > , and I must say I did not checked whether it had been addressed or not, as > I did not remember this had been raised for the ace-oauth-authz document. > > What you are saying is that the draft has been updated already. I will > have a closer look at it, and ask mqtt-profile to confirm the current text > is fine. > > Thanks! > Daniel > > -----Original Message----- > From: Ace <ace-boun...@ietf.org> On Behalf Of Ludwig Seitz > Sent: Thursday, November 21, 2019 10:51 AM > To: ace@ietf.org > Subject: Re: [Ace] comment on draft-ietf-ace-oauth-authz-26 > > 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 > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
