Re: [OAUTH-WG] Language in the security BCP for cases where raw U/P is unavoidable

Nat Sakimura <> Wed, 24 July 2019 18:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 90B3312034D for <>; Wed, 24 Jul 2019 11:52:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id boLETFwkkTTX for <>; Wed, 24 Jul 2019 11:52:20 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D5B0A120141 for <>; Wed, 24 Jul 2019 11:52:19 -0700 (PDT)
Received: by with SMTP id s3so42731814wms.2 for <>; Wed, 24 Jul 2019 11:52:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=TzGh9XWQQ8hjuyZLwqbmpgVygU6XCmI4sj7ILxl2KvA=; b=WUPD4NO2yX44DTHq6K9e63sK56jefsnblqCjD5Kk6trqWR8WiMVADWwWsp3jUALc34 LZOqsdxNu3sqeBqJqmrj6enMIry9fBNhw3yaZfVbAZc8OynHgvS5OCqA/F6iUYVs/G36 OgiS0KE8vin3hWKzSWC0W3xDn1OS56j5D/KTcgM6dxdJ2+o8hiu0Djd6Qge0sYeDFmIe rix/KGJcjoznRUZH+oVh7at8LrqKZ1U73fKxpLmOGcKWTPrqpYH96w1rLMUSv2jVVqVF rVmJswYwV6mMf2uqiu0L5RI/q420LEYX/g9MEB1aKpd5H8jPaDkVl3kSLzslAIsyq3uM +rNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=TzGh9XWQQ8hjuyZLwqbmpgVygU6XCmI4sj7ILxl2KvA=; b=mYkTeEydGuaYZVS5vPMT1LGyKAUch3CECADytM6VeUge8mhPO4DvRV1gDA0e4K0RuK DOsk/VJgggrJdVZhpL94UKP/HtttPBJZAbgDLhmlQPbqNiyog1JPzohEgXWJHXkcpaR4 wJZYQNHwk32vLCMWhfp92Y/J9YzK/PqyYQGb1BVQgdvFQPNiQZgJoXSSDoolFqN0jhRi teezbKZ5K4uG+LxQ4clOqRvvNQEtrZB1rwk55cQ3BDESYGDENExncBN3YzriR0HM+XK8 3g/TjQ3CgZUb9qF5FgYfRQZTIZi9Pa9Mn+/Ond628bgORvoWtzk0cDFXEeC0q+JktWbY Tmww==
X-Gm-Message-State: APjAAAWee0cn+vtUwEjg0ZWqpPFF7i2LEDzJaLqKdD8wi0Y/4Xz/M5y9 SyhCChH+hDkic0TCwwrx8QG9ZwqoP5DSV3jgEzA=
X-Google-Smtp-Source: APXvYqwaSVbr383ji5H7ljEOwC2daS4MHz151nuBnTDZJy0uPD12hdIsL5Hbt2j4LAVVM5mDB/+dRvqFYXhftlf1Ngg=
X-Received: by 2002:a1c:1a4c:: with SMTP id a73mr14091999wma.109.1563994337772; Wed, 24 Jul 2019 11:52:17 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Nat Sakimura <>
Date: Wed, 24 Jul 2019 14:52:06 -0400
Message-ID: <>
Cc: IETF oauth WG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [OAUTH-WG] Language in the security BCP for cases where raw U/P is unavoidable
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Jul 2019 18:52:23 -0000

As the time was running out, I did not make any comment but I actually
had two comments on this topic.

1) I agree with Vittorio that pushing people away from OAuth is a
slippery slope. Having said that, I have no good solution either. At
least, I feel that ROPC is not the right solution anyways.

2) ROPC is a good flow for migrating a password storing app to OAuth
as depicted in . So, completely denying
it is a touch too much. It should very narrowly constrain its



On Wed, Jul 24, 2019 at 11:33 AM Vittorio Bertocci
<>; wrote:
> During Daniel's security BCP presentation yesterday, I commented that although I support deprecating ROPG, I also believe we should acknowledge scenarios where U/P use is unavoidable and give clear actionable guidance to developers.
> Daniel observed that not every scenario is prone to be addressed via OAuth2, and invited me to suggest some language to add to clarifying that.
> Here's the proposed language:
>> Please note: there are scenarios, such as legacy script languages, apps using connections strings and similar, where the direct use of username and password is required to maintain backward compatibility. Addressing those scenarios is outside of the scope of the OAuth2 authorization framework.
> As a side note: I worry a bit that giving explicit license to people to ignore OAuth2 for that particular scenario might provide a bit of slippery slope/broken window effect where developers won't use standard solutions in other scenarios as well. At the same time, if we don;t want to tackle that particular class of scenarios, I think it's fair of us to be explicit about it.
> _______________________________________________
> OAuth mailing list

Nat Sakimura (=nat)
Chairman, OpenID Foundation