[OAUTH-WG] Re: First party apps review notes

[Dean Saxe <[e-mail]>]

This morning I opened issues 114 - 124 to cover the items below.
https://github.com/oauth-wg/oauth-first-party-apps/issues

-dhs
--
Dean H. Saxe, CIDPRO <https://idpro.org/cidpro/>
Principal Engineer
Office of the CTO
Beyond Identity
[e-mail]




On Nov 6, 2024 at 11:40:43 AM, Dean Saxe <[e-mail]>
wrote:

> Following the discussion at the second OAuth WG meeting at IETF121, I
> reviewed draft-parecki-oauth-first-party-apps-02.  (N.B. This was the doc I
> had on my Kindle when I started the review.  Aaron confirmed that the doc
> is the same as draft-ietf-oauth-first-party-apps-00, the latest doc just
> represents a naming change.)
>
> I have a few comments on the draft below.  I will file issues/PRs in
> GitHub for any comments that warrant an issue or PR (though it may take me
> a few days…).
>
>
>    - The draft notes multiple times that the new endpoint and the
>    protocol are only for first party apps and not third party apps, yet in 1.1
>    it states, “[…] the authorization server SHOULD take measures to prevent
>    use by third party applications.”  I believe the SHOULD should be changed
>    to a MUST.
>    - Sections 3.2 and 3.3 both use the language “re-authorization of the
>    user is required” when the AS responds with an error to presentation of a
>    refresh token (3.2) or the RS requires step up per RFC9470 (3.3).  In both
>    of these cases, re-authorization is required, however, I believe that the
>    requirement is actually re-authentication of the user in order to
>    re-authorize them.  I suggest changing both instances to re-authorization.
>    - Section 4.1 identifies that it is out of scope to define how to
>    handle a parameter that has no meaning in this use cases.  The draft can be
>    more explicit and state that these parameters MAY be ignored since they are
>    irrelavant.
>    - 5.2.2 defines an error_uri.  This seems unnecessary - and is defined
>    as optional - since this is only usable by first party apps. This can be
>    removed from the draft since first party app developers will have no need
>    for this data.
>    - 5.3.1 specifies the auth_session as a random string or JWE.  The
>    draft should specify the minimum length of this random string, e.g. >16
>    bytes, to avoid collisions.
>    - 5.3.1 mandates the auth_session is bound to the device, yet offers
>    no guidance on how to do so.
>    - 6.1 states that the token endpoint response MAY include the auth_session
>    parameter.  This is required for messages returned from the AS, I am
>    unclear why it is not required when a token endpoint response is returned.
>    6.2 has the same issue.
>    - 9.1 explicitly states that the draft is not prescriptive about how
>    the “first partyness” of the app is determined.  Given the risk of the use
>    of third party apps with this protocol, the draft should aim to be
>    prescriptive regarding how “first partyness” is assessed.  Similarly, the
>    draft should be more direct in the text that SPAs SHOULD NOT be used as
>    first party apps due to the challenges they present. 9.8 identifies SPAs at
>    NOT RECOMMENDED.
>    - Appendix A.1 step 4, the user is prompted for their activation
>    secret before the client can sign the challenge.
>    - Appendix A.1 step 4 change “platform authenticator” to “passkey”.
>    The passkey may reside in a platform authenticator, a first or third party
>    passkey provider, or on a hardware key.
>
>
> I hope the authors find these comments helpful.
> -dhs
>
> --
> Dean H. Saxe, CIDPRO <https://idpro.org/cidpro/>
> Principal Engineer
> Office of the CTO
> Beyond Identity
> [e-mail]
>
>
>