The quoted section of the RFC refers to the Authorization Endpoint, which is the endpoint through which the transmittion of user credentials is received by the Authorization Server in a way not specified within the OAuth 2.0 spec:
The way in
which the authorization server authenticates the resource owner
(e.g., username and password login, session cookies) is beyond the
scope of this specification.
Most applications display some form of login page at the Authorization Endpoint (either immediately or after redirections), and it is on that login page where credentials are collected; credentials are not collected via GET at the Authorization Endpoint, because the credentials would otherwise end up in the query string, making them accessible to third party javascript running on the client and potentially visible in logs.
POSTing to the Authorization Endpoint is behaviour that is not defined by the RFC beyond stating that a POST may be accepted, but doesn't have to be. You are free to accept credentials in any manner you see fit, as long as you obey the spec-compliant behaviour, which is that a response_type query parameter is provided, and a fragment is not used.
With regard to accepting credentials when POSTing to the endpoint, then - it's up to you. The RFC does not specify how one must specify credentials when interacting with the Authorization Endpoint.
Also, is it expected to respond with a 3xx (we use 303 with GET) redirect or can it also respond with 200 including a Location header?
You should use a 3xx request. The specification requires that the server redirect the user to the redirection endpoint of the client. HTTP 200 with a Location header indicates "I succeeded, and there is some related resource over there". HTTP 3xx indicates "The resource you are looking for is located at this exact location, and you should go there."
As such, we are considering to use either the Authorization header to present the RFC9068 JWT or to present it as a custom parameter in a request body. Using a query parameter is not an option because it exposes the token to third-parties, and our web framework supports end-to-end encryption of the request body.
I assume that the JWT you are referring to would be presented to the Authorization Endpoint in order to start an authorization flow with the Authorization Server. If this is the case, as mentioned above, the RFC does not make any requirements as to how you should implement this; you're free to implement it as you please.
In terms of concealing this information from a third party, the path, query string, headers and body are all protected from third parties when using TLS (which is a requirement of the specification). The only reason to prefer headers and body over path and querystring is to prevent leakage of the token in logs, or to prevent running into the URL character limit. I would personally present the JWT to the Authorization Server in body: the Authorization header is already used with valid OAuth sessions in the form of Bearer tokens. Using the JSON Body better communicates that this is an implementation-specific parameter.
That all being said, what you are describing sounds a lot like the client credential flow, in that you are providing an Authorization Grant, in the form of a JWT, to the end-user. Although one questions what this JWT contains - Usually, a JWT is the result of an Authorization Grant, and is not typically something the client would be able to issue. So, what is in this JWT you wish to send as a proof of authorization to the Authorization Server?
