sungwy commented on code in PR #13810:
URL: https://github.com/apache/iceberg/pull/13810#discussion_r2296566696
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -960,6 +960,15 @@ paths:
schema:
type: string
enum: [ all, refs ]
+ - in: query
+ name: referenced-by
+ description:
+ The fully qualified name of the view (i.e namespace name and view
name) that referenced the table.
+
+ nested namespaces are separated by a unit separator (`0x1F`) byte.
Review Comment:
Thanks for the thoughtful feedback, Prashant. I really appreciate you
walking me through your reasoning :)
You’ve raised some excellent points, and I agree with you on the following:
- It’s not a great idea to introduce brand new concepts like “Trusted
Engine” or “authorization” ad-hoc inside an OpenAPI parameter description.
- The spec shouldn’t dictate how a catalog establishes trust, or which
authorization mechanism is in use. That’s catalog-specific and rightly out of
scope.
That said, I do think there’s value in giving implementers clearer security
guidance in the REST Catalog Spec to help them implement endpoints safely. Both
your proposal here and the [FGAC
RFC](https://docs.google.com/document/d/108Y0E8XsZi91x-UY0_aHLEbmXDNmxmS5BnDjunEKvTM/edit?tab=t.0#heading=h.87f6fmhmyr1n)
lean heavily on the concept of trust between a client/engine and the catalog.
For example, in the FGAC proposal, exposing row-filters or column masks
securely depends on the assumption that the client is trusted to apply them
faithfully and not leak security context. Without such a notion of trust, it
becomes much harder to avoid threats like privilege escalation or
confused-deputy problems.
What are your thoughts on introducing the concept of “trust” in the [REST
Catalog Spec documentation](https://iceberg.apache.org/rest-catalog-spec/)? The
focus would be on defining the expected security traits of a trusted Iceberg
client (e.g., that it will only use metadata and security context for their
intended purpose, and not provide a general pathway for escalation), without
prescribing how catalogs establish that trust. Once we have the concept agreed
on by the community, perhaps we could reference it in the OPEN API yaml to
provide a stronger security guideline.
I'm curious to hear your thoughts on this suggestion. If it sounds
reasonable, I'd be open to drafting a documentation PR, and starting a
discussion on the mailing list to get feedback from the wider community.
--
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]
