danielcweeks commented on code in PR #18080:
URL: https://github.com/apache/iceberg/pull/18080#discussion_r4361418141


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -1410,12 +1400,34 @@ paths:
       - $ref: '#/components/parameters/prefix'
       - $ref: '#/components/parameters/namespace'
       - $ref: '#/components/parameters/table'
+      - $ref: '#/components/parameters/data-access'
 
     post:
       tags:
         - Catalog API
       summary: Remotely signs requests to object storage
       operationId: signRequest
+      description: >
+        Signs a request to object storage on the client's behalf.
+
+
+        `RemoteSignResult` reports the mechanism that produced the signature in
+        `signing-mechanism`. With `remote-signing`, `headers` carries the 
signature. With
+        `remote-presigning`, `uri` carries the signature.
+
+
+        On this operation `X-Iceberg-Access-Delegation` lists the access 
delegation mechanisms
+        the client supports for this request: `remote-signing`, 
`remote-presigning`, or both.
+        Other values, such as `vended-credentials`, are not supported on this 
operation and do
+        not count as listed mechanisms. The server SHOULD answer with one of 
the listed
+        mechanisms, and chooses when both are listed. The server SHOULD 
respond with 406, rather
+        than answer with another mechanism, when the header lists no mechanism 
the server
+        implements. For example, `vended-credentials` lists no mechanism, and
+        `vended-credentials,remote-signing` lists only `remote-signing`.

Review Comment:
   I'm not sure this is necessary and it would be good to get confirmation on 
this point.  I believe that pre-signed url and a remote signed url will be 
equally executable by the client.  The response is just taken and executed as 
provided, I think it should work (it's possible the mechanics of the SDK 
prevent this, but conceptually, they should be interchangeable).



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to