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.
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?
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?
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 tooauth-le...@ietf.org
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
