Hi, Thank you both.
It appears the current spec could be improved. As per Dan's reply, it seems we could: 1) Explicitly call out that paths can be dynamically created by the server and passed in the load table response. 2) Explicitly define a well-defined resource path with the necessary parameters. Which approach do we prefer? Option 1 is probably better, as there might not be a default path that suits all catalogs. In any case, I'm happy to provide a PR once we have an agreement. Thanks, Alex On Fri, Jan 9, 2026 at 12:48 PM Steve Loughran <[email protected]> wrote: > > > We've done that for a while for all s3a access in cloudera's products using > kerberos principals as the identities. S3A code has all the hooks underneath > (delegation token plugin point mainly), though the AWS SDK causes some > problems as it occasionally likes to do its own thing. Let's just say "it's a > regression point". > > the service needs to cache a lot > to assist this, you can strip out some of the headers (date? range? I forget) > so there's no need to recalculate signatures when these change > > steve > > > On Thu, 8 Jan 2026 at 20:15, Daniel Weeks <[email protected]> wrote: >> >> Alex, >> >> Customization was included in the reference implementation, but I don't >> think it's clearly reflected in the spec, so I don't believe it would be >> fully spec compliant currently. >> >> I believe most implementations of the signer are using request >> identity/authorization information to sign for specific paths, but without >> having the ability to associate the path with the owning resource, it can be >> difficult to check the authorization. >> >> We probably need to evolve the spec (either by explicitly calling out that >> paths can be dynamically created by the server and passed in the load table >> bundle) or by explicitly defining a well defined resource path with the >> necessary parameters if that information is necessary. >> >> I think Christian may have more context on an approach to addressing the >> signer behavior, so I would love to have his input here. >> >> -Dan >> >> >> >> On Thu, Jan 8, 2026 at 10:24 AM Alexandre Dutra <[email protected]> wrote: >>> >>> Hi all, >>> >>> We are currently integrating S3 remote signing into Apache Polaris [1]. >>> >>> A key topic of discussion [2] is the signer endpoint, which is defined >>> as "v1/aws/s3/sign" in s3-signer-open-api.yaml [3]. >>> >>> The main concern with the default value is its rigidity and lack of >>> path parameters for important elements like namespace, table, and >>> potentially a general-purpose prefix. >>> >>> This leads to my two questions regarding this endpoint: >>> >>> 1. Customization: is it spec-compliant to customize this endpoint's >>> path? My understanding, based on the commit introducing the feature >>> [4], is that it is. >>> >>> 2. Scope: should it be treated as a top-level endpoint (similar to the >>> config endpoint), or is it better considered an internal >>> implementation detail of the signer client? (This is important to >>> Polaris because top-level endpoints require higher evolution >>> guarantees.) >>> >>> I would love to hear from the community, especially those involved in >>> the S3 remote signing implementation! >>> >>> Thanks, >>> Alex >>> >>> [1]: https://github.com/apache/polaris/pull/2280 >>> [2]: https://lists.apache.org/thread/8qgv9ccyhhybokmckvf20r8hl1ng74xs >>> [3]: >>> https://github.com/apache/iceberg/blob/main/aws/src/main/resources/s3-signer-open-api.yaml#L61 >>> [4]: >>> https://github.com/apache/iceberg/commit/80766723588985c4592ffb336a76eabc046d01a9
