singhpk234 commented on code in PR #13810:
URL: https://github.com/apache/iceberg/pull/13810#discussion_r2294844474
##########
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:
IMHO, i understand being explicit would be ideal but i think it would be a
lot of terminology we would be including here, if we include this in the spec,
for example
> Authorization
we only talk of Authentication in IRC, privileges / grants which is what we
will authorize against, requires settling its independent discussion like one
here
[[doc](https://docs.google.com/document/d/1KmIDbPuN6IYF0nWs9ostXIB9F4b8iH3zZO0hjgs1lm4/edit?tab=t.0#heading=h.jgpnl0ksivvu)],.
> as a Trusted Engine identity as determined by the catalog’s trust policy
never the less Trusted Engine as a concept should be defined in IRC first as
well, before we reference here, like what do we mean by this, How does a
catalog understands a compute is trusted, TBH i am unsure if we want to define
it here in the first place, like can my OAuth token wrap this info, can mTLS
tell me this, it need not be a `Policy` necessarily.
Considering the above, I am a bit hesitant in including this gotcha in spec
(i already included this in the proposal), would love you know your thoughts
considering above.
Nevertheless hear others in context of spec definition too.
My POV is this is a context we are passing from the client (just like
any-other context like UA), hey this table is being loaded in the context of
this view, without explicitly stating how a catalog should use it, it implies
that trust needs be there if i were to take a AuthZ decision based on that.
--
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]
