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

[Vladimir Dzhuvinov / Connect2id]

Hi Pieter,








Cheers,

Vladimir


On 16/09/2024 16:40, Pieter Kasselman wrote:

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.

Hi Vladimir

Thanks for reading the draft and raising questions. See responses inline.

Cheers

Pieter

*From:*Vladimir Dzhuvinov / Connect2id <vladi...@connect2id.com>
*Sent:* Friday 13 September 2024 07:50
*To:* oauth@ietf.org
*Subject:* [OAUTH-WG] Re: Call for adoption - First Party Apps





<pk>



</pk>



<pk>



</pk>



<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 tooauth-le...@ietf.org

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. 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. 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 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). 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?

smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org