[OAUTH-WG] Re: Call for adoption - First Party Apps

[Vladimir Dzhuvinov / Connect2id <[e-mail]>]

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 <[e-mail]>
> *Sent:* Friday 13 September 2024 07:50
> *To:* [e-mail]
> *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 [e-mail]
>
>     To unsubscribe send an email [e-mail]
>