Subject: [OAUTH-WG] Direct Grant missing in draft-parecki-oauth-v2-1

From: Francis Pouatcha <[email-masked]>
Date: Wed, 8 Apr 2020 17:59:01 -0400

As a replacement of RFC 6749 I am missing a "Direct Grant" with the same
simplicity as the "Resource Owner Password Credentials" grant of RFC 6749.

The reason is that browser redirects are too complex and most of the time
badly implemented by small teams. For the sake of having SMEs use oAuth 2.1
with their limited development capacities, I suggest keeping the
simple "Resource
Owner Password Credentials" with an OTP replacing the permanent password.

We also have sample implementations working on the market with OTP
based "Resource
Owner Password Credentials" with full compatibility to RFC 6749.

-- 
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/

---

From: Aaron Parecki <[email-masked]>
Date: Wed, 8 Apr 2020 15:03:12 -0700

Hi Francis,

The Resource Owner Password Credentials grant is being deprecated in the
OAuth 2.0 Security BCP:

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.4

> The resource owner password credentials grant MUST NOT be used.

As this OAuth 2.1 draft is meant to consolidate the best practices across
the existing OAuth 2.0 documents, and is explicitly not intended to define
any new behavior that is not already in an adopted document, we can't
accept your suggestion of adding a new OTP-based grant in this document.

----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

On Wed, Apr 8, 2020 at 2:59 PM Francis Pouatcha <[email-masked]> wrote:

> with their limited development capacities, I suggest keeping the simple "Resource
> We also have sample implementations working on the market with OTP based "Resource

---

From: Francis Pouatcha <[email-masked]>
Date: Wed, 8 Apr 2020 18:25:36 -0400

Hello Aaron,

Deprecating Resource Owner Password Credentials Flow (Direct Grant) without
replacement might make a strict oAuth 2.1 server (with no backward
compatibility to oAuth2.0) unusable for a good part of "First Party"
applications on the market. These are application environments where the
operator of the AS is the same one deploying the mobile App using Direct
Grant.

Not sure it is a good idea to limit scope oAuth 2.1 on existing
functionality of oAuth 2.0 unless we are planning an oAuth 3.0 soon.
-- 
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/

On Wed, Apr 8, 2020 at 6:03 PM Aaron Parecki <[email-masked]> wrote:

>> We also have sample implementations working on the market with OTP based
>> "Resource Owner Password Credentials" with full compatibility to RFC
>> 6749.
>>
>> --
>> Francis Pouatcha

---

From: Dick Hardt <[email-masked]>
Date: Wed, 8 Apr 2020 17:09:45 -0700

Francis

We had a long discussion on this topic earlier this year:

https://mailarchive.ietf.org/arch/msg/oauth/mG6tkmXSOxwakC0184snKCGxfSE/

On Wed, Apr 8, 2020 at 3:25 PM Francis Pouatcha <[email-masked]> wrote:

> Hello Aaron,
>
> Deprecating Resource Owner Password Credentials Flow (Direct Grant)
> without replacement might make a strict oAuth 2.1 server (with no backward
>>> As a replacement of RFC 6749 I am missing a "Direct Grant" with the
>>> same simplicity as the "Resource Owner Password Credentials" grant of RFC
>>> 6749.
>>>
>>> The reason is that browser redirects are too complex and most of the
>>> time badly implemented by small teams. For the sake of having SMEs use
>>> oAuth 2.1 with their limited development capacities, I suggest keeping the
>>> simple "Resource Owner Password Credentials" with an OTP replacing the
>>> permanent password.
>>>

---

From: Daniel Fett <[email-masked]>
Date: Thu, 9 Apr 2020 09:25:37 +0200

Hi Francis,

Am 08.04.20 um 23:59 schrieb Francis Pouatcha:
> same simplicity as the "Resource Owner Password Credentials" grant of
> RFC 6749.
>
> oAuth 2.1 with their limited development capacities, I suggest keeping
> the simple "Resource Owner Password Credentials" with an OTP replacing
> the permanent password.

How does the Client get the OTP in that case?

-Daniel

---

From: Rob Otto <[email-masked]>
Date: Thu, 9 Apr 2020 08:55:48 +0100

I'd imagine you have to pre-register each client and then use HOTP or TOTP
to generate one-time passcodes.

On Thu, 9 Apr 2020 at 08:25, Daniel Fett <[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
<https://www.pingidentity.com>
<https://www.pingidentity.com>
Rob Otto
EMEA Field CTO/Solutions Architect
[email-masked]

c: +44 (0) 777 135 6092
Connect with us: 
<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
[image:
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter
logo] <https://twitter.com/pingidentity> 
<https://www.facebook.com/pingidentitypage> 
<https://www.youtube.com/user/PingIdentityTV> 
<https://www.pingidentity.com/en/blog.html>
<https://www.google.com/url?q=https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/faqs/en/consumer-attitudes-post-breach-era-3375.pdf?id%3Db6322a80-f285-11e3-ac10-0800200c9a66&source=gmail&ust=1541693608526000&usg=AFQjCNGBl5cPHCUAVKGZ_NnpuFj5PHGSUQ>
<https://www.pingidentity.com/en/events/d/identify-2019.html>
<https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/Misc/en/3464-consumersurvey-execsummary.pdf>
<https://www.pingidentity.com/en/events/e/rsa.html>
<https://www.pingidentity.com/en/events/e/rsa.html>
<https://www.pingidentity.com/en/lp/e/enabling-work-from-home-with-MFA.html>
*If you’re not a current customer, click here
<https://www.pingidentity.com/en/lp/e/work-from-home-sso-mfa.html?utm_source=Email&utm_campaign=WF-COVID19-New-EMSIG>
for
a more relevant offer.*

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Daniel Fett <[email-masked]>
Date: Thu, 9 Apr 2020 10:09:13 +0200

Am 09.04.20 um 09:55 schrieb Rob Otto:
> I'd imagine you have to pre-register each client and then use HOTP or
> TOTP to generate one-time passcodes. 
>

I can come up with a couple of other ways as well, but I'm interested to
hear what Francis sees "in the wild".

-Daniel

---

From: Justin Richer <[email-masked]>
Date: Thu, 9 Apr 2020 07:30:32 -0400

We’ve looked at this with XYZ, and one of the patterns that’s possible with the backchannel-first flow is to have the server send a challenge back to the client which the client can then respond to, for example by signing it with a FIDO style device key. Depending on the system, the client could identify the user in the first request or the credential could carry the identification directly. You need an “extra” round trip compared to OAuth2 style flows, but it makes life a whole lot simpler for this kind of user authn.

 — Justin

> On Apr 9, 2020, at 4:09 AM, Daniel Fett <[email-masked]> wrote:
> 
> 
>> I'd imagine you have to pre-register each client and then use HOTP or TOTP to generate one-time passcodes. 
>> 
> 
> I can come up with a couple of other ways as well, but I'm interested to hear what Francis sees "in the wild".
> 
> -Daniel
>