Exploring Authorization Endpoint Flows, PAR, and redirect_to_web Interaction type

Hello,
I am trying to understand Authorization Endpoint flows and the relationship between the Pushed Authorization Request (PAR) mechanism and the redirect_to_web interaction type.

From my understanding - PAR vs redirect to web

• PAR focuses on making a POST to /par which responds with request_uri to which Wallet is supposed to redirect for user authorization
• redirect_to_web is an interaction instruction that focuses on Wallet performing initial interaction request and getting the response with request_uri to which Wallet is expected to redirect for user authorization.

Functionally, both seem to result in the Wallet redirecting the user to a web-based authorization endpoint, which makes them appear similar from a Wallet UX perspective.

I wanted to check:

• Is this distinction (PAR vs redirect_to_web interaction ) expected to remain separate?
• Are there any discussions or plans to align or merge these concepts in future revisions, or is the current separation considered important for clarity and extensibility?
• I would also like to confirm the use of the authorization_endpoint as mentioned in RFC 6749 & RFC 8414 for obtaining an authorization_code. Could this requirement change in the future? Is it always mandatory for an Issuer (Authorization Server) to support the authorization_endpoint, even if it expects authorization to occur via user interaction (such as an interactive_authorization_endpoint)? If so, are there specific scenarios—such as when a missing_interaction_type error is returned by the Issuer—where the Wallet may fall back to using the authorization_endpoint for authorization?

Start by comparing the /par, redirect_to_web, authorization_endpoint, and interactive_authorization_endpoint flows with the cited RFC 6749 and RFC 8414 sections. Done means documenting whether these concepts remain separate, whether authorization_endpoint is mandatory, and how missing_interaction_type affects fallback behavior.