Field to include temporary bearer token or object storage credentials?

[jdries]

Context
For secure asset hrefs returned by openEO API, we currently use presigned urls, which allows exchanging STAC metadata and the data it points to between systems.
For the ZARR format, this does not work, because ZARR is a directory rather than a file, and presigned urls point to files rather than directories.

Request
Can a (secured) API that returns STAC metadata, include a (temporarily valid) token in the metadata, via this extension?
More specifically:

• a bearer token for schemes with type 'http'
• temporary object storage crecentials , for 's3' scheme

[jamesfisher-geo]

In terms of configuring bearer auth with authentication extension I think it would be as simple as including key for the following auth:scheme in the auth:refs of the ZARR asset.

{
    "bearer_auth": {
        "type": "http",
        "description": "Requires bearer token authentication",
        "scheme": "bearer",
        "bearerFormat": "JWT",
    }
}

Or you can include the authorization link for login

{
    "bearer_auth": {
        "type": "http",
        "description": "Requires bearer token authentication",
        "scheme": "bearer",
        "bearerFormat": "JWT",
        "flows": {
            "authorizationUrl": "https://example.authorization.endpoint/authorize",
            "scopes": {
                "read:asset": "scope for permission to read asset"
            }
        },
    }
}

Accessing the data is another challenge and would require implementation on the client or server side. The idea was put out in stac-auth-proxy #11 to automatically generate signed URLs. But for multi-file data it would need to authenticate to whatever server is being used

[jdries]

bearer token would indeed be an option, is it also possible to add an optional 'token' property in which a temporarily valid token can be provided by the API providing the STAC metadata? (openEO in our case.)

[m-mohr]

Might be related to #44 as well.

[jdries]

I don't think token exchange (worked on in #44) solves the problem, because it still implies that some token needs to be obtained, so it's not equivalent to signed url's which allow anonymous access.