Hello Daniel,
I am interpreting them as they are saying the same thing. Am I reading the
following correctly?
RFC 6749 defines the conditions under 401 can be returned:
The authorization server responds with an HTTP 400 (Bad Request)
status code (unless specified otherwise)
invalid_client
Client authentication failed (e.g., unknown client, no
client authentication included, or unsupported
authentication method). The authorization server MAY
return an HTTP 401 (Unauthorized) status code to indicate
which HTTP authentication schemes are supported. If the
client attempted to authenticate via the "Authorization"
request header field, the authorization server MUST
respond with an HTTP 401 (Unauthorized) status code and
include the "WWW-Authenticate" response header field
matching the authentication scheme used by the client.
ietf-ace-oauth-authz says it follows the same conditions for 4.01
defined in RFC6749.
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>.
Thanks,
--Cigdem
On Wed, Nov 27, 2019 at 4:10 PM Daniel Migault <[email protected]>
wrote:
> Hi,
>
> Changing the thread name.
>
> If I were using CoAP/JSON, I think 6749 and ace-oauth-authz may have
> different error 4.00/4.01.
>
> My interpretation is that I would recommend ace-oauth-authz would result
> in implementation sending 4.00 and 4.01 while 6749 would always send 4.00.
> As a result, I would rather recommend ace-oauth-authz. Am I missing
> something ?
>
> Yours,
> Daniel
>
> -----Original Message-----
> From: Daniel Migault
> Sent: Wednesday, November 27, 2019 11:03 AM
> To: Ludwig Seitz <[email protected]>; Cigdem Sengul <
> [email protected]>
> Cc: [email protected]
> Subject: RE: [Ace] comment on draft-ietf-ace-oauth-authz-26
>
> 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 protected]>
> Sent: Wednesday, November 27, 2019 8:36 AM
> To: Cigdem Sengul <[email protected]>; Daniel Migault <
> [email protected]>
> Cc: [email protected]
> Subject: Re: [Ace] comment on draft-ietf-ace-oauth-authz-26
>
> 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 protected]>
> Sent: Thursday, November 21, 2019 10:27 AM
> To: Daniel Migault
> Cc: Ludwig Seitz; [email protected]
> 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=
> [email protected]<mailto:[email protected]>>
> 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 <[email protected]<mailto:[email protected]>> On Behalf
> Of Ludwig Seitz
> Sent: Thursday, November 21, 2019 10:51 AM
> To: [email protected]<mailto:[email protected]>
> 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
> > [email protected]<mailto:[email protected]>
> > https://www.ietf.org/mailman/listinfo/ace
> >
>
>
> --
> Ludwig Seitz, PhD
> Security Lab, RISE
> Phone +46(0)70-349 92 51
>
> _______________________________________________
> Ace mailing list
> [email protected]<mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/ace
>
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
