nastra commented on code in PR #10722:
URL: https://github.com/apache/iceberg/pull/10722#discussion_r1758556272


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -3129,6 +3204,11 @@ components:
          - `s3.secret-access-key`: secret for credentials that provide access 
to data in S3 
          - `s3.session-token`: if present, this value should be used for as 
the session token 
          - `s3.remote-signing-enabled`: if `true` remote signing should be 
performed as described in the `s3-signer-open-api.yaml` specification
+
+        ## Credentials
+
+        Credentials for ADLS / GCS / S3 are provided through the `credentials` 
field. Clients should first check whether the
+        respective credentials exist in the `credentials` field before 
checking the `config` for credentials.

Review Comment:
   I mean technically we could design the spec/impl in a way that would allow a 
server to sent back credentials for multiple providers (one credential per 
provider) in a single response. So rather than having
   ```
   // inside LoadTableResult / LoadViewResult
   "credentials" : {
       "type" : "gcs",
       "token" : "gcsToken",
       "expires-at-ms" : 1000
     }
   ```
   
   we could have 
   ```
   // inside LoadTableResult / LoadViewResult
   "credentials" : {
     "s3": {
       "access-key-id" : "keyId",
       "secret-access-key" : "accessKey",
       "session-token" : "sessionToken",
       "expires-at-ms" : 1000
     },
     "gcs": {
       "token" : "gcsToken",
       "expires-at-ms" : 1000
     },
     // no adls credentials as that provider isn't used for that table
   } 
   ```
   
   Also I agree that we most likely don't want to push the mapping to the 
client. Is that what you guys had in mind?



-- 
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: issues-unsubscr...@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org
For additional commands, e-mail: issues-h...@iceberg.apache.org

Reply via email to