All, Based on the responses received on the mailing list, we believe that there is enough support for this document to become a WG document.
Authors, Feel free to submit a -00 version at your convenience. Regards, Rifaat & Hannes On Tue, Sep 17, 2024 at 4:55 AM Vladimir Dzhuvinov / Connect2id < vladi...@connect2id.com> wrote: > Hi Pieter, > > Thanks for your responses. I'm writing to state my support for the > adoption of this draft. > > I'm starting to see it as a meaningful evolution of the deprecated > password grant. I read the arguments to stay focused on the browser-based > code flow. Browser APIs have evolved over the course of OAuth 2.0, but the > reality is that devs and architects do not see them as ideal in all > situations and the password grant is still being used and considered. This > improved sped for 1st party apps should make it easier to have solutions > that are standard and interoperable. > > About the auth techniques, I would like to ask you and the other authors > working on the spec to consider defining parameters for the ones that are > most likely to see use in practice, in the coming years. I'm asking you > this because my past experience with profiles is that when they do appear, > it may be too late. The JWT profile for access tokens - RFC 9068 - comes to > mind. It was published 9 years after the bearer token RFC. > > Cheers, > > Vladimir > > > On 16/09/2024 16:40, Pieter Kasselman wrote: > > Hi Vladimir > > > > Thanks for reading the draft and raising questions. See responses inline. > > > > Cheers > > > > Pieter > > > > *From:* Vladimir Dzhuvinov / Connect2id <vladi...@connect2id.com> > <vladi...@connect2id.com> > *Sent:* Friday 13 September 2024 07:50 > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Re: Call for adoption - First Party Apps > > > > I read the proposed spec and it's evident substantial work has gone into > it. Congratulations for this. > > How does the 1st party flow compare to the (deprecated in OAuth 2.1) > password grant? People with existing 1st party apps that rely on the > password grant or consider using it are going to look for a discussion on > this. > > <pk> > > The first party flow is meant to provide a framework to allow for multiple > authentication factors to enable MFA type scenarios where there is a first > party trust relationship between the application gathering the credentials > and the authorization server. It provides a pathway from single factor > authentication methods to stronger MFA and ultimately phishing resistant > authentication methods. > > </pk> > > > > In terms of security properties (leaving aside the design to support > factors other than user password and the support for interaction), does it > offer advantages? In the simple case (no interaction), do developers have a > reason to choose the 1st party flow when the password grant only needs a > single call to the token endpoint? > > <pk> > > The main advantage is the ability to step up to MFA (or even to require a > web redirect to collect credentials on the web if the authorization server > deems the risk of a “first party” flow excessive). > > </pk> > > > > The password grant has been subjected to (non-standard) customisations to > support challenges, for example to be able to ask the user for an OTP after > the password is verified. The 1st party flow takes such scenarios into > account, but appears to have taken the framework approach, leaving it up to > developers to complete the definition of the flow for the factors an AS is > required to use / combine. Is it envisioned for the 1st party flow spec to > get complemented with profiles or is it expected developers / deployments > to take care of this? > > <pk> > > We expect there will be profiles for popular authentication techniques. > > </pk> > > > > Vladimir Dzhuvinov > > On 03/09/2024 13:46, Rifaat Shekh-Yusef wrote: > > All, > > As per the discussion in Vancouver, this is a call for adoption for the > First Party Apps draft: > https://datatracker.ietf.org/doc/draft-parecki-oauth-first-party-apps/ > > Please, reply on the mailing list and let us know if you are in favor or > against adopting this draft as WG document, by *Sep 17th*. > > Regards, > Rifaat & Hannes > > > > _______________________________________________ > > OAuth mailing list -- oauth@ietf.org > > To unsubscribe send an email to oauth-le...@ietf.org > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
