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

From: Daniel Migault <[email-masked]>
Date: Thu, 21 Nov 2019 10:29:04 +0800

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.

"""

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 21 Nov 2019 03:51:28 +0100

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

>     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
> 
> 
> 
>     defined inSection 5.2 of [RFC6749]  <https://tools.ietf.org/html/rfc6749#section-5.2>, with the following exceptions:
> 
>        inSection 5.2 of [RFC6749]  <https://tools.ietf.org/html/rfc6749#section-5.2>.
> 
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
> 

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

---

From: Daniel Migault <[email-masked]>
Date: Thu, 21 Nov 2019 03:06:29 +0000

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 <[email-masked]> On Behalf Of Ludwig Seitz
Sent: Thursday, November 21, 2019 10:51 AM
To: [email-masked]
Subject: Re: [Ace] comment on draft-ietf-ace-oauth-authz-26

> permitted. This seems to me a request to clarify the text.

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.

/Ludwig

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

---

From: Cigdem Sengul <[email-masked]>
Date: Thu, 21 Nov 2019 09:27:10 +0000

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=
[email-masked]> 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
>
> > <https://tools..
> ietf.org/html/draft-ietf-ace-oauth-authz-26#section-5.6.3>.
> 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.
>
> >     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
> >
> >
> >
> >     defined inSection 5.2 of [RFC6749]  <
> https://tools.ietf.org/html/rfc6749#section-5.2>, with the following
> exceptions:
> >
> >        inSection 5.2 of [RFC6749]  <
> https://tools.ietf.org/html/rfc6749#section-5.2>.
> >

---

From: Daniel Migault <[email-masked]>
Date: Sat, 23 Nov 2019 14:49:10 +0800

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

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 <[email-masked]>
wrote:

> Hello,
>
> Ludwig, I agree that the current draft describes specifically for when
> CBOR is used.
> of [RFC6749] <https://tools.ietf.org/html/rfc6749#section-5.2> as you
> have indicated also in the ace-oauth-authz document.
>
>> 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.
>>
>> https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-26#section-5.6.3>
>> [2].
>> >
>> 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.
>>
>> >        response code equivalent to the CoAP code 4..00 (Bad Request)
>> >        response code equivalent to the CoAP code 4..00 (Bad Request)

---

From: Jim Schaad <[email-masked]>
Date: Sun, 24 Nov 2019 20:23:43 -0800

Daniel,

I don’t understand why you want to follow a different specification for the error interactions in this case.  I don’t see any reason not to following [ace-oauth-authz] but using JSON for the errors.

Jim

From: Ace <[email-masked]> On Behalf Of Daniel Migault
Sent: Friday, November 22, 2019 10:49 PM
To: Cigdem Sengul <[email-masked]>
Cc: [email-masked]; Ludwig Seitz <[email-masked]>; Daniel Migault <daniel.migault=[email-masked]>
Subject: Re: [Ace] comment on draft-ietf-ace-oauth-authz-26

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 <[email-masked] <mailto:[email-masked]> > 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  <https://tools.ietf.org/html/rfc6749#section-5.2> Section 5.2 of [RFC6749] 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. 

"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=[email-masked] <mailto:[email-masked]> > wrote:

Hi Ludwig, 

Thanks!
Daniel 

-----Original Message-----
From: Ace <[email-masked] <mailto:[email-masked]> > On Behalf Of Ludwig Seitz
Sent: Thursday, November 21, 2019 10:51 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: Re: [Ace] comment on draft-ietf-ace-oauth-authz-26

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

/Ludwig

>        response code equivalent to the CoAP code 4...00 (Bad Request)
>        response code equivalent to the CoAP code 4...00 (Bad Request)
> [email-masked] <mailto:[email-masked]> 

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

_______________________________________________
Ace mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/ace

_______________________________________________
Ace mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/ace

---

From: Daniel Migault <[email-masked]>
Date: Mon, 25 Nov 2019 14:41:10 +0000

Hi Jim,

I think that was the point I was raising and my understanding is that the text we follow is [ace-oauth-authz]. Are you suggesting to completely remove 6749 completely, or is there any text you would prefer ?

Yours,
Daniel

From: Jim Schaad <[email-masked]>
Sent: Sunday, November 24, 2019 11:24 PM
To: Daniel Migault <[email-masked]>; 'Cigdem Sengul' <[email-masked]>
Cc: [email-masked]; 'Ludwig Seitz' <[email-masked]>
Subject: RE: [Ace] comment on draft-ietf-ace-oauth-authz-26

Daniel,

Jim

From: Ace <[email-masked]<mailto:[email-masked]>> On Behalf Of Daniel Migault
Sent: Friday, November 22, 2019 10:49 PM
To: Cigdem Sengul <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Ludwig Seitz <[email-masked]<mailto:[email-masked]>>; Daniel Migault <daniel.migault=[email-masked]<mailto:daniel.migault=[email-masked]>>
Subject: Re: [Ace] comment on draft-ietf-ace-oauth-authz-26

OLD

NEW

Yours,
Daniel

On Thu, Nov 21, 2019 at 5:27 PM Cigdem Sengul <[email-masked]<mailto:[email-masked]>> 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.

Would that help?

Thanks,
--Cigdem

On Thu, Nov 21, 2019 at 3:06 AM Daniel Migault <daniel.migault=[email-masked]<mailto:[email-masked]>> wrote:
Hi Ludwig,

Thanks!
Daniel

-----Original Message-----
From: Ace <[email-masked]<mailto:[email-masked]>> On Behalf Of Ludwig Seitz
Sent: Thursday, November 21, 2019 10:51 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ace] comment on draft-ietf-ace-oauth-authz-26

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

/Ludwig

>        inSection 5.2 of [RFC6749]  <https://tools.ietf.org/html/rfc6749#section-5.2>..
>
> [email-masked]<mailto:[email-masked]>

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

_______________________________________________
Ace mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ace

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 27 Nov 2019 13:36:04 +0000

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 <[email-masked]>
Sent: Thursday, November 21, 2019 10:27 AM
To: Daniel Migault
Cc: Ludwig Seitz; [email-masked]
Subject: Re: [Ace] comment on draft-ietf-ace-oauth-authz-26

Hello,

Would that help?

Thanks,
--Cigdem

Thanks!
Daniel

-----Original Message-----
From: Ace <[email-masked]<mailto:[email-masked]>> On Behalf Of Ludwig Seitz
Sent: Thursday, November 21, 2019 10:51 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ace] comment on draft-ietf-ace-oauth-authz-26

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

/Ludwig

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

---

From: Cigdem Sengul <[email-masked]>
Date: Wed, 27 Nov 2019 15:00:16 +0000

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 <[email-masked]> 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
>
> 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
> [email-masked]<mailto:[email-masked]>>
> wrote:
> Hi Ludwig,
>
> 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>>.

---

From: Daniel Migault <[email-masked]>
Date: Wed, 27 Nov 2019 16:03:18 +0000

Hi, 

Just for clarification, as the one starting the thread, I believe that it is clear that  draft-ietf-ace-oauth-authz-26 has no issue and can be moved forward. 

Yours, 
Daniel

-----Original Message-----
From: Ludwig Seitz <[email-masked]> 
Sent: Wednesday, November 27, 2019 8:36 AM
To: Cigdem Sengul <[email-masked]>; Daniel Migault <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ace] comment on draft-ietf-ace-oauth-authz-26

/Ludwig

Hello,

Would that help?

Thanks,
--Cigdem

On Thu, Nov 21, 2019 at 3:06 AM Daniel Migault <daniel.migault=[email-masked]<mailto:[email-masked]>> wrote:
Hi Ludwig,

Thanks!
Daniel

-----Original Message-----
From: Ace <[email-masked]<mailto:[email-masked]>> On Behalf Of Ludwig Seitz
Sent: Thursday, November 21, 2019 10:51 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ace] comment on draft-ietf-ace-oauth-authz-26

/Ludwig

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