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 dean.s...@beyondidentity.com On Nov 6, 2024 at 11:40:43 AM, Dean Saxe <dean.s...@beyondidentity.com> 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 > dean.s...@beyondidentity.com > > >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
