AUTH ARCHITECTURE

Does: authenticate operators accessing framework services, maintain operator-to-CDR ownership mappings, provide API key management for Terms Enforcement API consumers, integrate with third-party identity providers. Does not: replace domain-specific authentication (platform-specific logins, CMO member portals), store rights data (that belongs in the Rights Registry), or make rights determinations.

Integration 1 — Rights Registry (operator identity for CDR ownership). Integration 2 — CDR Portal (authenticated operator dashboard). Integration 3 — Terms Enforcement API (API key issuance and rate limiting). Integration 4 — Generator (authenticated vs anonymous generation). Integration 5 — Certification system (candidate identity for certificate issuance).

Operator profile (legal entity name, jurisdiction, contact), authentication credentials (delegated to identity provider), API keys (for programmatic access), operator-to-CDR mappings (which CDRs this operator administers), and certification records (which certifications this operator holds).

Lawful basis: legitimate interests (Article 6(1)(f)) for operator authentication; contract performance (Article 6(1)(b)) for certified operators. Data minimisation: auth system holds only what is necessary for authentication and operator-CDR mapping. Right to erasure: operator account deletion cascades to CDR ownership mappings but does not delete the CDRs themselves (rights declarations persist independently of operator identity).

Decision 1 — Build vs integrate: whether to build a bespoke auth system or integrate with an existing identity provider (Auth0, Clerk, Supabase Auth, Firebase Auth). Decision 2 — Identity provider selection: if integrating, which provider. Both decisions are governance matters for the trustees. The specification documents what the auth system must do regardless of the build/integrate choice.