I'd rather we not use 'password' as an example of additional data the client can post to the AS as part of the authorization challenge endpoint. I really think this endpoint should mirror the /authorization endpoint with the purpose of supporting native authentication flows. Adding additional data in this POST seems like it adds to the complexity for Authorization Servers to implement which may limit adoption.
We could use 'username' as an example as it can be passed in the "login_hint" parameter (at least in OIDC). I don't see any harm in the first response of the AS as an error asking for additional information. For example, the first response may be a passkey challenge as the user doesn't even have a password.
I'd rather we not use 'password' as an example of additional data the client can post to the AS as part of the authorization challenge endpoint. I really think this endpoint should mirror the /authorization endpoint with the purpose of supporting native authentication flows. Adding additional data in this POST seems like it adds to the complexity for Authorization Servers to implement which may limit adoption.
We could use 'username' as an example as it can be passed in the "login_hint" parameter (at least in OIDC). I don't see any harm in the first response of the AS as an error asking for additional information. For example, the first response may be a passkey challenge as the user doesn't even have a password.