This is derived from a thread in #2836 (comment) and from @plusplusjiajia's original implementation on #2838. There's three issues I see with the freshly introduced iceberg::catalog::session::Credential type:
- the naming of
Credential already exists in the context of credential vending (see iceberg_catalog_rest::StorageCredential - but in Java it's plain Credential). A new Credential concept meaning "any sensitive string" conflicts with it
- use cases exist for a sensitive string type outside of catalog credentials, like FileIO properties (e.g.
s3.session-token): iceberg::catalog is the wrong place to share it
- The existing (and analogous)
iceberg::encryption::SensitiveBytes type is located somewhere completely different, making it non-obvious that both exists and share semantics
This is derived from a thread in #2836 (comment) and from @plusplusjiajia's original implementation on #2838. There's three issues I see with the freshly introduced
iceberg::catalog::session::Credentialtype:Credentialalready exists in the context of credential vending (seeiceberg_catalog_rest::StorageCredential- but in Java it's plainCredential). A newCredentialconcept meaning "any sensitive string" conflicts with its3.session-token):iceberg::catalogis the wrong place to share iticeberg::encryption::SensitiveBytestype is located somewhere completely different, making it non-obvious that both exists and share semantics