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
