Problem
OpenTDF does not clearly document how the platform relates to OpenID Connect (OIDC). A reader can come away unclear about which concerns OpenTDF owns versus those owned by an OIDC identity provider, and how identity tokens and claims participate in authorization decisions.
Proposed documentation
Add an architecture/concepts section that explains:
- OpenTDF is not an identity provider and does not replace OIDC.
- OIDC provides authentication and identity claims; OpenTDF consumes/verifies trusted identity context for policy decisions.
- Where an OIDC provider fits in a typical OpenTDF deployment.
- How token issuer, audience, signing keys/JWKS, and claims relate to OpenTDF configuration.
- The boundary between authentication, authorization/policy, and protected-data access.
- A small request-flow diagram and a concrete configuration/example flow.
- Links to the relevant platform configuration and SDK documentation.
Acceptance criteria
- A new user can explain the division of responsibility between OpenTDF and an OIDC provider.
- The documentation includes an end-to-end conceptual flow from sign-in through protected-data access.
- Terminology is consistent across architecture, configuration, and SDK docs.
- Existing OIDC-related documentation is linked rather than duplicated where possible.
Problem
OpenTDF does not clearly document how the platform relates to OpenID Connect (OIDC). A reader can come away unclear about which concerns OpenTDF owns versus those owned by an OIDC identity provider, and how identity tokens and claims participate in authorization decisions.
Proposed documentation
Add an architecture/concepts section that explains:
Acceptance criteria