Let's remove the oauth2 tag for now until we figure out how to move forward there. That makes sense to me.
On Fri, Jun 21, 2024 at 9:30 AM Dmitri Bourlatchkov <dmitri.bourlatch...@dremio.com.invalid> wrote: > Hi Eduard, > > The capabilities PR looks good to me overall. I have a concern with the > "oauth2" tag name though. > > I also commented [1] in GH but the comment appears to be closed by default > :) > > I believe the term "oauth2" is confusing in this context with respect to > RFC 6749 [2] as discussed in depth on another thread [3] > > The functionality behind the /tokens endpoint is quite specific to the > Iceberg REST spec and as the other discussion highlights, there are > concerns with respect to OAuth2 interoperability with other OAuth2 servers. > > What do you think about using a different tag name for it, for example > "local-tokens" or "auth-tokens"? > > Thanks, > Dmitri. > > [1] > https://github.com/apache/iceberg/pull/9940/files/15c769a52b85ac4deff5659978c7ffa7802612b0#r1649173934 > [2] https://www.rfc-editor.org/rfc/rfc6749 > [3] https://lists.apache.org/thread/twk84xx7v0xy5q5tfd9x5torgr82vv50 > > On Thu, Jun 20, 2024 at 7:28 AM Eduard Tudenhoefner < > etudenhoef...@apache.org> wrote: > >> Hey everyone, >> >> I'd like to bring up the discussion around describing REST server >> capabilities via the */config* endpoint. >> There is PR #9940 <https://github.com/apache/iceberg/pull/9940> that >> describes the OpenAPI spec changes. >> >> Mainly we'd like to have a *capabilities* field in the *ConfigResponse* that >> allows servers to indicate to clients which capabilities are being >> supported. >> >> So far we have the following capabilities: >> >> - tables >> - views >> - remote-signing >> - vended-credentials >> - multi-table-commit >> - register-table >> - table-metrics >> - oauth2 >> >> >> The general idea behind a capability is that if e.g. a server supports >> *views*, then that server must implement all endpoints grouped under >> that capability. >> It's worth noting that the */config* endpoint is currently being >> implicit (meaning that every REST server would have to implement it). >> >> One discussion point that came up during review is how we want to handle >> capabilities and backwards compatibility and what the default capability >> would be, since older servers don't know anything about *capabilities* (in >> such a case we could assume that the default capabilities would be >> *oauth2* / *tables*). >> >> Are there any other capabilities that we'd like to include in the list? >> >> Eduard >> > -- Ryan Blue Databricks
