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

[Cigdem Sengul <[e-mail]>]

Thanks Ludwig,
I was thinking my suggested wording won't pose a problem either.

I refer to CBOR as even if we describe everything based on JSON,  CBOR is
stated as an option.

--Cigdem

On Wed, Nov 27, 2019 at 1:36 PM Ludwig Seitz <[e-mail]> wrote:

> If you are using JSON-based interactions, I believe that the most
> straightforward way is to refer to RFC6749 for the error messages as you
> currently do. I don't find this confusing or problematic, but YMMV.
>
> /Ludwig
>
> ________________________________________
> From: Cigdem Sengul <[e-mail]>
> Sent: Thursday, November 21, 2019 10:27 AM
> To: Daniel Migault
> Cc: Ludwig Seitz; [e-mail]
> Subject: Re: [Ace] comment on draft-ietf-ace-oauth-authz-26
>
> 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]<mailto:[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]<mailto:[e-mail]>> On Behalf
> Of Ludwig Seitz
> Sent: Thursday, November 21, 2019 10:51 AM
> To: [e-mail]<mailto:[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<
> http://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]<mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/ace
> >
>
>
> --
> Ludwig Seitz, PhD
> Security Lab, RISE
> Phone [phone]
>
> _______________________________________________
> Ace mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ace
>