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

From: Vittorio Bertocci <[email-masked]>
Date: Wed, 24 Jul 2019 08:32:42 -0700

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
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-3.4
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.

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 24 Jul 2019 14:52:06 -0400

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 https://youtu.be/zuVuhl_Axbs . So, completely denying
it is a touch too much. It should very narrowly constrain its
applicability.

Cheers,

Nat

On Wed, Jul 24, 2019 at 11:33 AM Vittorio Bertocci
<vittorio.bertocci=[email-masked]> 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 https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-3.4 clarifying that.
>> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en