Hi Roman,
thanks for the detailed review and your valuable feedback!
I think you raise one important point in particular that I'd like to
discuss on the list:
Am 19.12.23 um 00:08 schrieb Roman Danyliw:
** I struggled to understand what was mandatory in the mix of RFC2119 keywords.
(a) Section 1 says “Nonetheless, it is RECOMMENDED that implementers upgrade
their implementations and ecosystems when feasible.”
(b) Section 3 says “OAuth MUST ensure that the authorization of the resource
owner (RO) (with a user agent) at the authorization server (AS) and the
subsequent usage of the access token at the resource server (RS) is protected
at least against the following attackers:”
(c) Section 3 later says “Implementers MUST take into account all possible
types of attackers in the environment in which their OAuth implementations
are expected to run.”
(b) and (c) seem to be making strong statements mandatory requirements for
high-level threats. However, (a) seems to suggest that conformance is only
recommended.
Let's ignore (b) here since the sentence is worded a bit strangely and
I'll fix that independently of this discussion. (We can't really say
"OAuth MUST..." — what does that even mean?)
The context for (a) are these two paragraphs:
/This document provides updated security recommendations to address
these challenges. It does not supplant the security advice given in
[RFC6749
<https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-24.html#RFC6749>],
[RFC6750
<https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-24.html#RFC6750>],
and [RFC6819
<https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-24.html#RFC6819>],
but complements those documents./
/This document introduces new requirements beyond those defined in
existing specifications such as OAuth 2.0 [RFC6749
<https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-24.html#RFC6749>]
and OpenID Connect [OpenID.Core
<https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-24.html#OpenID.Core>]
and deprecates some modes of operation that are deemed less secure or
even insecure. Naturally, not all existing ecosystems and
implementations are compatible with the new requirements and following
the best practices described in this document may break
interoperability. Nonetheless, it is RECOMMENDED that implementers
upgrade their implementations and ecosystems when feasible./
My understanding of the relationship of (a) to the rest of the document
is roughly this: Since we're releasing this BCP now, most ecoystems will
not be compliant to all of the normative requirements immediately.
Therefore, an upgrade is RECOMMENDED. To be compliant, one must
implement all the normative requirements described in the document.
I do, however, see how this can read like a contradiction and would
therefore suggest to change the sentence in (a) to something like
"Nonetheless, implementers need to upgrade their implementations and
ecosystems to be compliant to this document/BCP/..."
What do you and others think?
-Daniel
--
Please use my new email address:m...@danielfett.de
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
