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

[Daniel Migault <[e-mail]>]

Thank you Ludwig and Cigdem,

I would effectively prefer to have one reference, i.e ace-oauth-authz. I
also reviewed the text from ace-oauth-authz and it seems fine. I also guess
the text from Cigdem is better, however, ace-oauth-authz provides
exceptions for CBOR and CoAP.

OLD
"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]"

NEW
"As described in [ace-oauth-authz] the error responses for HTTP/JSON-based
interactions with AS follow RFC6749. When CBOR or CoAP is used, the
interactions MUST implement [ace-oauth-authz]"

Yours,
Daniel

On Thu, Nov 21, 2019 at 5:27 PM Cigdem Sengul <[e-mail]>
wrote:

> 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=
> [e-mail]> 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 <[e-mail]> On Behalf Of Ludwig Seitz
>> Sent: Thursday, November 21, 2019 10:51 AM
>> To: [e-mail]
>> 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
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/ace
>> >
>>
>>
>> --
>> Ludwig Seitz, PhD
>> Security Lab, RISE
>> Phone [phone]
>>
>> _______________________________________________
>> Ace mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ace
>>
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace
>