Your proposal sounds good to me. Am 28. Dez. 2023, 10:25 +0100 schrieb Daniel Fett <fett=40danielfett...@dmarc.ietf.org>: > 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], > [RFC6750], and [RFC6819], but complements those documents. > This document introduces new requirements beyond those defined in existing > specifications such as OAuth 2.0 [RFC6749] and OpenID Connect [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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
