>
>
> 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".
There are many w
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
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
___
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 wrote:
> Hi Francis,
>
> Am 08.04.20 um 23:59 schrieb Francis Pouatcha:
>
> As a replacement of RFC 6749 I am missing a "Direct Grant" with the sa
Hi Francis,
Am 08.04.20 um 23:59 schrieb Francis Pouatcha:
> 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
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 wrote:
> Hello Aaron,
>
> Deprecating Resource Owner Password Credentials Flow (Direct Grant)
> without re
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
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 consolid
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
