Proposed Change
Proposed Change
Summary
Expose server-assigned resource identifiers (e.g., tableId) in the loadTable REST response so that clients can use them for resource-level access control without HTTP-layer interception.
Motivation
When a REST catalog backend assigns server-side identifiers to tables (e.g., S3 Tables assigns a tableId used in ARN construction), downstream systems that federate through the Iceberg REST protocol need this identifier for credential vending. Specifically, they need it to construct resource-level IAM policies with table-scoped ARNs.
Today, the tableId is present in the raw HTTP response body but is not surfaced through the RESTCatalog client API. The only way to access it is to wrap the HTTP client and intercept responses before deserialization. This is brittle and breaks across Iceberg library version bumps.
Proposed Change
Include server-provided resource identifiers (such as tableId) in the config map of the LoadTableResponse, or introduce a dedicated field in the response schema for backend-assigned metadata. This would allow REST catalog clients to access the value through the standard API contract without HTTP-layer interception.
Use Case
Apache Polaris (apache/polaris#4052) federates to S3 Tables REST endpoints and needs the tableId to construct arn:aws:s3tables:::table/{tableId} ARNs for scoped IAM session policies during credential vending. Currently worked around via a ConfigCapturingHTTPClient wrapper that intercepts the raw response.
Proposal document
No response
Specifications
Proposed Change
Proposed Change
Summary
Expose server-assigned resource identifiers (e.g.,
tableId) in the loadTable REST response so that clients can use them for resource-level access control without HTTP-layer interception.Motivation
When a REST catalog backend assigns server-side identifiers to tables (e.g., S3 Tables assigns a
tableIdused in ARN construction), downstream systems that federate through the Iceberg REST protocol need this identifier for credential vending. Specifically, they need it to construct resource-level IAM policies with table-scoped ARNs.Today, the
tableIdis present in the raw HTTP response body but is not surfaced through the RESTCatalog client API. The only way to access it is to wrap the HTTP client and intercept responses before deserialization. This is brittle and breaks across Iceberg library version bumps.Proposed Change
Include server-provided resource identifiers (such as
tableId) in theconfigmap of theLoadTableResponse, or introduce a dedicated field in the response schema for backend-assigned metadata. This would allow REST catalog clients to access the value through the standard API contract without HTTP-layer interception.Use Case
Apache Polaris (apache/polaris#4052) federates to S3 Tables REST endpoints and needs the
tableIdto constructarn:aws:s3tables:::table/{tableId}ARNs for scoped IAM session policies during credential vending. Currently worked around via aConfigCapturingHTTPClientwrapper that intercepts the raw response.Proposal document
No response
Specifications