Background
Some storage systems receive temporary, scoped credentials from an external control plane instead of from the machine-level default credential chain. For example, a catalog or namespace service may authorize access to a table and return short-lived credentials that are restricted to that table's object-store prefix.
This is different from the default credential chain. Default providers describe machine or runtime identity. External dynamic credentials are object/user/request scoped and should take precedence only when the application explicitly wires them in.
Current conclusion
Do not add a new DynamicCredentialProvider abstraction.
reqsign-core::ProvideCredential already has the right shape:
pub trait ProvideCredential {
type Credential;
fn provide_credential(
&self,
ctx: &Context,
) -> impl Future<Output = Result<Option<Self::Credential>>> + MaybeSend;
}Each service already has a typed Credential, and Signer already reloads cached credentials when SigningCredential::is_valid() returns false. External dynamic credentials can therefore be represented by ordinary service-level ProvideCredential implementations.
Usage pattern
Applications should put their external provider in front of the default chain explicitly:
let provider = reqsign_aws_v4::DefaultCredentialProvider::new()
.push_front(my_catalog_or_namespace_provider);The external provider should return the service's typed credential directly, for example:
reqsign_aws_v4::Credentialreqsign_google::Credentialreqsign_azure_storage::Credential
If downstream systems receive generic maps from a catalog, namespace, or secret manager, each service crate may add small convenience adapters. Those map shapes should not become part of reqsign-core.
Tracking issues
Non-goals
- Do not add a global
reqsign_core::DynamicCredentialProvider.
- Do not add catalog or namespace authorization logic to reqsign.
- Do not add external dynamic providers to default credential chains automatically.
- Do not bake Lance/object_store
storage_options field names into core APIs.
Background
Some storage systems receive temporary, scoped credentials from an external control plane instead of from the machine-level default credential chain. For example, a catalog or namespace service may authorize access to a table and return short-lived credentials that are restricted to that table's object-store prefix.
This is different from the default credential chain. Default providers describe machine or runtime identity. External dynamic credentials are object/user/request scoped and should take precedence only when the application explicitly wires them in.
Current conclusion
Do not add a new
DynamicCredentialProviderabstraction.reqsign-core::ProvideCredentialalready has the right shape:Each service already has a typed
Credential, andSigneralready reloads cached credentials whenSigningCredential::is_valid()returns false. External dynamic credentials can therefore be represented by ordinary service-levelProvideCredentialimplementations.Usage pattern
Applications should put their external provider in front of the default chain explicitly:
The external provider should return the service's typed credential directly, for example:
reqsign_aws_v4::Credentialreqsign_google::Credentialreqsign_azure_storage::CredentialIf downstream systems receive generic maps from a catalog, namespace, or secret manager, each service crate may add small convenience adapters. Those map shapes should not become part of
reqsign-core.Tracking issues
Non-goals
reqsign_core::DynamicCredentialProvider.storage_optionsfield names into core APIs.