Ideas on providing authorization to access inputs

Description

I would like to gather ideas on how process inputs could be defined during execution to support authorization to access remote URL or S3 buckets.

When a process is protected by some policy enforcement point, the usual approach is to send HTTP Authorization or Set-Cookie headers to grant access. However, after the POST /processes/{id}/execution request was authorized, the inputs defined in the execution body could themselves be href to other locations that also require authorization, and which doesn't necessarily match the same HTTP authorization used to POST the execution. An obvious example would be a protected S3 bucket with files that would almost certainly have different access credentials than the server running the OGC API - Processes service.

One quick fix approach could be to employ additionalParameters in the corresponding input that requires this kind of authorization. The necessary structure of additional parameters is not obvious (nor standardized) however, considering there are also multiple ways to define authorizations (basic, bearer token, cookies, etc.). There is no clear way how those parameters should be defined and handled to form some HTTP Authorization header when requesting the file.
https://github.com/opengeospatial/ogcapi-processes/blob/bfaf8f087f554eba7b3d3ebe05a6eb138bf06d84/openapi/schemas/processes-core/descriptionType.yaml#L15-L23

Open Questions

1. Would additionalParameters be the best strategy?
2. If so, could OGC API - Processes provide recommendations and OpenAPI schema definitions on the expected formats?
3. Has anybody used this additionalParameters approach to confirm it is viable?
4. Otherwise, what other alternative would be possible, and what are the tradeoffs of their advantages/disadvantages?

Start with openapi/schemas/processes-core/descriptionType.yaml at the linked definition, then review how POST /processes/{id}/execution represents href inputs and additionalParameters. The issue asks for alternatives, authorization formats, schema recommendations, and tradeoffs, but does not define an implementation target or tests; done would require an agreed approach and explicit scope.