Tracking: expand GrantCredential across cloud services

[Xuanwo]

Goal

Track service-specific uses of the public GrantCredential / Granter<K> capability introduced by #801 and merged in #803.

This tracker covers operations where an explicit existing service Credential authorizes issuance of another independently usable, bounded, expiring Credential in the same service family. The operation may downscope the source authority or transition into another authority domain; strict permission-subset semantics are service-specific and are not part of the core contract.

Shared contract

Every implementation in this tracker should follow the existing reqsign API pattern:

ProvideCredential<K> + GrantCredential<Credential = K> -> Granter<K>
ProvideCredential<K> + SignRequest<Credential = K>     -> Signer<K>

• Bind stable endpoint/account/role configuration and one typed service-specific grant to the concrete granter before constructing Granter<K>.
• Consume the source through the existing ProvideCredential<K> path; do not change ProvideCredential or add a generic granted-credential provider adapter.
• Return the existing service Credential with exact expiration semantics so it remains directly consumable by Signer<K>.
• Validate the source credential variant and grant before I/O, then reject output that is no longer usable after I/O.
• Cache only source or service-specific intermediary state when required; never cache granted output in core, and partition intermediary caches by authority and source identity.
• Redact source credentials, granted credentials, policies, session keys, and raw credential responses from Debug and errors.
• Use Context I/O and preserve the crate's native/WASM MaybeSend contract.
• Keep existing fixed-configuration ProvideCredential implementations as compatibility APIs. They may share request construction and response parsing with a new granter; migration is not required.

Delivered foundation

• Core GrantCredential and Granter<K>: Add GrantCredential and Granter as a core credential granting capability #801 / feat: add scoped credential granting with Azure user delegation SAS #803
• Azure User Delegation SAS and exact SAS expiration: Track expiration for Azure SAS token credentials #750 / Expose Azure user delegation SAS generation for scoped credential vending #751 / feat: add scoped credential granting with Azure user delegation SAS #803
• Azure Shared Key Service SAS with exact signed expiration: feat(azure): add Service SAS granter #817
• Google server-side Credential Access Boundary exchange: Add GCP Credential Access Boundary downscoped token support #749 / feat: add GCP Credential Access Boundary downscoping #805
• Google client-side Credential Access Boundary tokens: Add client-side GCP Credential Access Boundary token generation #804 / feat: add client-side GCP Credential Access Boundary #808

Service coverage

AWS

• AWS STS AssumeRole — AssumeRoleGrant and AssumeRoleGranter explicitly consume an AWS source credential, reuse shared STS request/response machinery, and preserve AssumeRoleCredentialProvider as the fixed-flow compatibility API: feat(aws): add STS AssumeRole granter #813.
• AWS S3 Access Grants GetDataAccess — S3AccessGrantsGranter binds typed account/Region configuration, target, permission, and privilege semantics and returns an expiration-aware AWS credential: feat(aws): add S3 Access Grants GetDataAccess granter #811.
• AWS S3 Express CreateSession — S3ExpressSessionGranter binds typed directory-bucket, partition, and session-mode configuration while preserving S3ExpressSessionProvider: feat(aws): add S3 Express CreateSession granter #812. Historical protocol testing is tracked in Add test for aws s3 express CreateSession #594.

These checkboxes mean that the public APIs and deterministic protocol coverage are merged into main. All three AWS granters now also have live-service CI paths: AssumeRoleGranter and S3ExpressSessionGranter execute in the gated jobs repaired by #823, while #830 provisions a real S3 Access Grants environment, calls GetDataAccess, and validates the issued credential with STS GetCallerIdentity. The trusted PR run and the post-merge main run both passed these jobs.

Remaining live-cloud acceptance gaps are separate from implementation completion. Real GCP CAB interoperability from #805 / #808 is still unverified, and #817 retains live Azure HNS acceptance for Service SAS o / p permissions.

Remaining service work

• Alibaba Cloud RAM STS AssumeRole — reuse the provider added by feat(aliyun-oss): add assume role credential provider #724 as service-internal machinery, with typed role/policy parameters and an explicit source credential. Aliyun OSS: Credential Chain & Signing Parity #684 tracked broader credential-chain and signing parity.
• Tencent Cloud STS — research and implement the signed GetFederationToken or AssumeRole flow with typed policy/identity parameters. AssumeRoleWithWebIdentity remains a ProvideCredential flow because its source is an external identity token, not an existing Tencent credential.
• Huawei Cloud IAM agency credentials — add a granter only for the explicit source-credential-authorized agency/token issuance flow, with exact temporary AK/SK/security-token expiration.
• Volcengine STS AssumeRole for TOS — first verify the current public protocol, per-issuance authorization controls, and authoritative expiration fields; then implement a granter if the response can satisfy the SigningCredential validity contract. Volcengine TOS credential providers and presign support #752 previously grouped STS, metadata credentials, and presign; only the granting portion belongs here.

Existing issue consolidation

• Add client-side GCP Credential Access Boundary token generation #804 was the canonical implementation issue for client-side GCP CAB and was closed by feat: add client-side GCP Credential Access Boundary #808.
• Tracking: migrate remaining OpenDAL auth to reqsign #685 remains the separate, broader tracker for migrating OpenDAL service authentication into reqsign.
• Document external dynamic credentials using ProvideCredential #748 documents how externally delivered credentials enter the existing ProvideCredential path; it is complementary to issuance, not a duplicate.
• Add test for aws s3 express CreateSession #594, Aliyun OSS: Credential Chain & Signing Parity #684, and Volcengine TOS credential providers and presign support #752 are historical implementation/parity issues whose relevant mechanisms may be reused. They did not deliver the remaining explicit GrantCredential APIs listed above.
• Add GCP Credential Access Boundary downscoped token support #749 and Add client-side GCP Credential Access Boundary token generation #804 were not duplicates: they covered server-side STS exchange and client-issued CAB tokens, respectively; both are now delivered.

No open duplicate issue was found for the remaining Alibaba Cloud, Tencent Cloud, Huawei Cloud, or Volcengine granting work. Add a dedicated child issue when an item enters implementation, link it here, and keep service-specific protocol decisions in that child.

Out of scope

• Web identity, OIDC, Google external account/WIF, IMDS/ECS/GCE metadata, profile/config loading, and default credential chains; these remain ProvideCredential capabilities.
• Presigned requests, POST policies, and other request-bound artifacts; these remain SignRequest capabilities.
• A cross-cloud scope/permission model, a second grant generic on Granter, a generic output envelope, or automatic insertion into default credential chains.
• Rewriting an existing fixed-flow provider solely to use Granter when no explicit issuance API is needed.