Thanks Rifaat, I've published a version -00 to datatracker and it is awaiting approval from the chairs.
Aaron On Mon, Oct 7, 2024 at 12:23 PM Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com> wrote: > 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 >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
