What would you like to be improved?

The registerTable endpoint (POST /v1/{prefix}/namespaces/{namespace}/register) does not accept the X-Iceberg-Access-Delegation header and never vends credentials in its response. In contrast, createTable and loadTable both accept this header and pass isCredentialVending to the IcebergRequestContext, which triggers credential injection into the LoadTableResponse.

In the registerTable method (IcebergNamespaceOperations.java#L299-L323):

• No @HeaderParam(X_ICEBERG_ACCESS_DELEGATION) parameter
• IcebergRequestContext is constructed without isCredentialVending
• The response is returned via IcebergRESTUtils.ok() instead of buildResponseWithETag()

The Iceberg REST spec defines the data-access (X-Iceberg-Access-Delegation) header as a parameter on the registerTable endpoint, and the response uses the same LoadTableResult schema that includes config and storage-credentials fields for credential vending.

This means clients that register a table and immediately attempt to read its data cannot use vended credentials from the registration response — they must make a separate loadTable call.

How should we improve?

• Add @HeaderParam(X_ICEBERG_ACCESS_DELEGATION) String accessDelegation to the registerTable method
• Pass isCredentialVending to IcebergRequestContext so credential injection is triggered
• Return the response with ETag via buildResponseWithETag() for consistency with createTable/loadTable