Compendium

Identity / Authentication / Authorization Policy DSLs Family Index

13 min read

Identity / Authentication / Authorization Policy DSLs Family Index

type: language-family-index family: identity-auth-policy languages_catalogued: 28 tags: [language-reference, family-index, identity-auth-policy, oidc, saml, jwt, jose, opa-rego, cedar, iam, zanzibar, webauthn, scim, xacml]

Identity / Authentication / Authorization Policy — Family Index

Family overview

The identity / auth / policy DSL family is the set of textual languages used to (a) assert who someone is (SAML assertions, OIDC ID tokens, JWTs, WebAuthn attestations), (b) describe how an authentication or authorization flow proceeds (OAuth 2.0/2.1 grant types, OAuth PAR, PKCE, DPoP, Rich Authorization Requests), and (c) decide what an authenticated principal is allowed to do (AWS IAM JSON, Azure RBAC, GCP IAM Conditions, OPA Rego, AWS Cedar, XACML, OpenFGA, SpiceDB, Kyverno, Cedar). They share the awkward property of being mostly JSON or XML on the wire rather than purpose-designed surface syntax — but the JSON is so structurally constrained, and the keywords (Effect, Action, Resource, Condition; iss, aud, exp, nbf, sub; <saml:Assertion>, <saml:Subject>, <saml:AttributeStatement>) so semantically loaded, that they function as DSLs in practice. Tooling (linters, formal-verification engines, type checkers, policy simulators) treats them as such.

The arc runs from the SAML XML era (2005–2015) of enterprise SSO — AuthnRequest / Response / Assertion documents signed with XML-DSig, federated via metadata XML — to the OAuth 2 / OIDC / JWT modern era (2012+) that won web and mobile by replacing 50KB of signed XML with a 1KB base64url-encoded JSON token. JWT (RFC 7519, 2015) and the surrounding JOSE family (JWS, JWE, JWA, JWK — RFCs 7515/7516/7518/7517) became the lingua franca of modern identity claims, with OIDC (2014) layering an identity protocol on top of OAuth 2.0 (RFC 6749, 2012). OAuth 2.1 (draft draft-ietf-oauth-v2-1-15, expiring Sept 2026) consolidates a decade of security errata: mandatory PKCE, exact redirect-URI matching, retirement of the implicit and password grants.

In parallel, the cloud IAM diaspora produced three non-interoperable JSON dialects — AWS IAM Statements (Effect/Action/Resource/Condition), Azure RBAC role definitions (actions/notActions/dataActions), and Google Cloud IAM Conditions (CEL expressions) — that together form the most-deployed authorization DSLs on Earth. Then came the policy-as-code wave: OPA Rego (CNCF graduated 2021, OPA v1.0 released early 2025 with cleaned-up syntax), AWS Cedar (open-sourced 2023, formally verified soundness via Lean proof, powers Amazon Verified Permissions), Kyverno (CNCF graduated 16 March 2026), and the Zanzibar lineage (Google’s 2019 paper on Consistent Global Authorization) — instantiated in OpenFGA (CNCF Incubating since 28 Oct 2025) and SpiceDB (Authzed, .zed schema language).

Newer layers stack on top: WebAuthn / Passkeys (W3C Level 3 Candidate Recommendation, 13 Jan 2026) for phishing-resistant credentials with CTAP2/CBOR attestation; DPoP (RFC 9449, 2023) for sender-constrained tokens; Rich Authorization Requests (RFC 9396, 2023) for fine-grained per-transaction authorization; OpenID Federation for trust-anchor-based federation graphs; and CEL as a small embeddable expression DSL that has quietly become the default “policy expression” for K8s ValidatingAdmissionPolicy (GA in K8s 1.30), Tetragon, gRPC server policies, and IAM Conditions.

In our deep library

None of these languages have standalone deep-library notes in /Languages/; they live primarily as JSON or XML on the wire. Cross-references:

  • api-description — most identity DSLs are JSON Schema or XML Schema instances (OIDC ID Token, SCIM, AWS IAM, Cedar, OpenFGA, JWT). The schema infrastructure is catalogued there.
  • notation-spec — XACML 3.0 and SAML 2.0 are formal specifications with EBNF / XML Schema grammars; that family covers grammar formalisms.
  • config-management — Kubernetes admission policies (OPA Gatekeeper, Kyverno, ValidatingAdmissionPolicy) overlap heavily with cluster configuration.
  • build-devops — CI/CD secrets, GitHub OIDC federation, sigstore/cosign keyless signing intersect with this family.
  • logic-and-constraint — Rego is Datalog-flavoured (with sequencing and negation extensions); Cedar’s evaluator is verified in Lean; XACML’s evaluation algebra is logical. Conceptual neighbourhood.
  • graph-log-event-query — relationship-based access control (Zanzibar / OpenFGA / SpiceDB) is graph-shaped; check queries traverse a userset rewrite graph.
  • smart-contract — on-chain access-control patterns (ERC-4337 account abstraction, multisig DSLs) are an adjacent authorization vocabulary.

Tier 3 family table — Identity assertion / token formats

FormatFirst appearedOriginTypeStatus (2026)URL
SAML 2.0 (assertions, metadata, AuthnRequest/Response)2005OASIS Security Services TCXML-based identity assertion + metadata + protocol bindingActive by inertia — still anchors enterprise SSO into legacy SaaS; little new investment but ubiquitoushttps://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
OIDC ID Token (OpenID Connect Core 1.0)2014OpenID Foundation (built on OAuth 2.0)JWT-encoded identity assertion (iss, sub, aud, exp, iat, nonce, auth_time, acr, amr)Dominant — the modern web/mobile identity standardhttps://openid.net/specs/openid-connect-core-1_0.html
JWT (RFC 7519)2015IETF JOSE WGCompact, URL-safe JSON claims-set token; three base64url-encoded parts joined by .Ubiquitous — the modern token format across web, mobile, service-to-servicehttps://datatracker.ietf.org/doc/html/rfc7519
JWS (RFC 7515)2015IETF JOSE WGJSON-based signature container; the “S” in JWT-signedActivehttps://datatracker.ietf.org/doc/html/rfc7515
JWE (RFC 7516)2015IETF JOSE WGJSON-based encryption containerActive but used less than JWS in practicehttps://datatracker.ietf.org/doc/html/rfc7516
JWK / JWK Set (RFC 7517)2015IETF JOSE WGJSON representation of cryptographic keys; the jwks_uri endpoint formatUbiquitous (every OIDC issuer publishes a JWK Set)https://datatracker.ietf.org/doc/html/rfc7517
JWA (RFC 7518)2015IETF JOSE WGJSON Web Algorithms — the alg/enc value registry (RS256, ES256, EdDSA, etc.)Active; algorithm registry continues to grow (post-quantum candidates being registered)https://datatracker.ietf.org/doc/html/rfc7518
JWS Detached Payload (RFC 7515 §A.5 / Appendix F)2015IETF JOSE WGSignature mode where the payload is transmitted out-of-band (e.g. HTTP Message Signatures)Active, niche; used by FAPI 2.0 and HTTP Signatureshttps://datatracker.ietf.org/doc/html/rfc7515#appendix-F
SCIM 2.0 (RFC 7643/7644)2015IETF SCIM WG (originally Salesforce/Ping)JSON schema for users, groups, enterprise extensions; CRUD over HTTP for identity provisioningActive, the de facto identity-provisioning protocol (Okta, Microsoft, Google all support it)https://datatracker.ietf.org/doc/html/rfc7643
WebAuthn / FIDO2 (W3C, Level 3)L1 2019, L2 2021, L3 Candidate Recommendation 13 Jan 2026W3C Web Authentication WG + FIDO AllianceJSON+CBOR public-key credential format; CTAP2 attestation between authenticator and platformVery active; passkey rollout dominant in 2024–2026https://www.w3.org/TR/webauthn-3/
WebAuthn CTAP2 attestation (CBOR)2018FIDO AllianceCBOR-encoded attestation statement returned by authenticatorsActive (passkey adoption)https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-errata-20220621.html

Tier 3 family table — OAuth flow vocabulary, federation, and token-binding

FormatFirst appearedOriginTypeStatus (2026)URL
OAuth 2.0 (RFC 6749) — grant flows2012IETF OAuth WGVocabulary of authorization-code, implicit, password, client-credentials grants; not strictly a textual DSL but a state-machine spec referenced by name everywhereActive, but several grants now retiredhttps://datatracker.ietf.org/doc/html/rfc6749
OAuth 2.1 (draft-ietf-oauth-v2-1-15)Draft, expires Sept 2026IETF OAuth WGConsolidates OAuth 2.0 + a decade of security errata; mandatory PKCE; removes implicit + password grants; exact redirect-URI matchingStable in practice, not yet final RFC; major IdPs already conformhttps://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/
OAuth PKCE (RFC 7636)2015IETFProof Key for Code Exchange — code_verifier/code_challenge pair to bind the auth code to its requesterMandatory in OAuth 2.1 and most modern profileshttps://datatracker.ietf.org/doc/html/rfc7636
OAuth PAR (RFC 9126)2021IETFPushed Authorization Requests — push the request payload to the AS over a back-channel before redirectActive, FAPI 2.0 mandates ithttps://datatracker.ietf.org/doc/html/rfc9126
OAuth 2.0 Rich Authorization Requests / RAR (RFC 9396)2023IETFJSON authorization_details array describing fine-grained authorization scope (e.g., “transfer €100 from account X to Y”) — replaces the limited scope string for high-stakes grantsActive, used in PSD2 / open-bankinghttps://datatracker.ietf.org/doc/html/rfc9396
DPoP (RFC 9449)2023IETFDemonstrating Proof of Possession — sender-constrained access tokens via a DPoP JWT header that proves possession of the keyActive, growing adoptionhttps://datatracker.ietf.org/doc/html/rfc9449
OpenID Federation 1.02024 (Final spec)OpenID FoundationTrust-anchor / Trust-Mark / Entity-Statement JSON DSL describing federation graphs of IdPs, RPs, and intermediatesActive, central to EU eID / EUDI Wallet rollouthttps://openid.net/specs/openid-federation-1_0.html

Tier 3 family table — Cloud IAM policy languages

FormatFirst appearedOriginTypeStatus (2026)URL
AWS IAM JSON policy language2010Amazon Web ServicesJSON policy with Statement[] of {Effect, Action, Resource, Condition, Principal}; condition keys + operators form a sub-DSLThe most-deployed authorization DSL on Earth — every AWS account uses it; thousands of action verbs across hundreds of serviceshttps://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html
AWS Service Control Policies (SCPs)2017AWS OrganizationsVariant of IAM JSON applied at the org/OU/account hierarchy; deny-only effectiveActive, foundational for multi-account governancehttps://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html
Azure AD / Entra ID claim-rules language~2014 (AD FS rule language origins)MicrosoftCustom rule DSL (c:[Type == "..."] => issue(Type = "...")) for claim transformation; superseded in Entra ID by claims-mapping policy JSONActive in AD FS / Entra ID hybrid deploymentshttps://learn.microsoft.com/en-us/entra/identity-platform/saml-claims-customization
Azure RBAC role definitions2017Microsoft AzureJSON with actions/notActions/dataActions/notDataActions on resource-provider operation stringsUbiquitous in Azurehttps://learn.microsoft.com/en-us/azure/role-based-access-control/role-definitions
Google Cloud IAM Conditions (CEL)2020Google CloudCEL expressions attached to IAM bindings (request.time < timestamp(...), resource.name.startsWith(...))Active, expandinghttps://cloud.google.com/iam/docs/conditions-overview
CEL — Common Expression Language2018 (open-sourced)GoogleSmall typed expression language; protobuf-typed; designed for embeddingVery active; ubiquitous in 2025–2026 cloud-native stack — IAM Conditions, K8s ValidatingAdmissionPolicy (GA in K8s 1.30, Apr 2024), CRD validation, Tetragon, gRPC, Envoyhttps://github.com/google/cel-spec

Tier 3 family table — Modern policy-as-code

FormatFirst appearedOriginTypeStatus (2026)URL
OPA Rego2016Styra (Tim Hinrichs, Torin Sandall) → CNCFDatalog-flavoured logic language with rule sequencing, negation-as-failure, partial evaluation; OPA is CNCF graduated (Aug 2021); OPA v1.0 released early 2025, dropping import rego.v1 requirement (if/contains now default keywords)Dominant policy-as-code language; heavy use in K8s admission, Terraform sentinels, CI policyhttps://www.openpolicyagent.org/docs/
OPA Gatekeeper ConstraintTemplate2019Microsoft + Google + StyraKubernetes admission DSL: a ConstraintTemplate CRD wraps a Rego module, then Constraint instances apply it to scopesActive, the canonical “Rego on K8s”https://open-policy-agent.github.io/gatekeeper/
Kyverno (YAML policies)2019Nirmata → CNCFYAML-native K8s policy engine — pattern matching, mutation, validation, generation, image verification, JMESPath + CEL for expressions; CNCF graduated 16 March 2026; latest release Kyverno 1.18 (May 2026) adopts CEL HTTP librariesVery active, the alternative to Rego in K8s admissionhttps://kyverno.io/
Cedar (AWS)2023 (open-sourced May 2023)AWSPurpose-designed authorization DSL with PARC model (Principal, Action, Resource, Context); formally verified evaluator (Lean proof of soundness); powers Amazon Verified Permissions; April 2026 added policy-store aliases + named policiesVery active, fast-growing alternative to Regohttps://docs.cedarpolicy.com/
XACML 3.02013 (OASIS Standard); Errata 01 in 2017; XACML 4.0 CSD-01 published Feb 2026OASIS XACML TCXML-based ABAC policy language; <PolicySet>/<Policy>/<Rule> with combining algorithms; comprehensive but verboseLegacy-but-alive in EU government, finance, defence; losing ground to JSON-based modern alternatives; XACML 4.0 modernisation underwayhttps://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html
XACML JSON Profile 1.12017OASISJSON encoding of XACML request/response (not full policy)Niche, mostly used by AuthzForcehttps://docs.oasis-open.org/xacml/xacml-json-http/v1.1/xacml-json-http-v1.1.html
Polar (Oso)2020Oso Inc.Declarative policy language inspired by Prolog + RBAC patterns; legacy oso OSS library deprecated by Oso Sept 2024; Polar lives on inside Oso Cloud (commercial)Status changed: OSS deprecated; commercially active inside Oso Cloud onlyhttps://www.osohq.com/docs/reference/polar/introduction
OpenFGA (FGA modeling language)2022 (Auth0 FGA → CNCF)Auth0 → Okta → CNCFZanzibar-style relationship DSL — type definitions with relations referencing other types; check / list-objects / list-users APIs; CNCF Incubating since 28 Oct 2025 (was Sandbox from Sept 2022)Very active, advancinghttps://openfga.dev/docs/modeling/getting-started
SpiceDB schema (.zed)2021Authzed (Jake Moshenko, Jimmy Zelinskie)Zanzibar implementation; .zed schema files define definition blocks with relation and permission (with +, &, -, arrow -> operators)Very active, the open-source Zanzibar with the strongest production track record (alongside OpenFGA)https://authzed.com/docs/spicedb/concepts/schema
NIST NGAC (Next-Generation Access Control)2014 (INCITS), continued NIST developmentUS NIST / INCITS CS1Graph-based attribute access control; policy elements as a directed graph; alternative to ABAC/XACMLEmerging US government standard; NIST SP 800-178/-205 reference architecturehttps://csrc.nist.gov/projects/policy-machine
GA4GH DUO (Data Use Ontology)2021 (v1.0)Global Alliance for Genomics and HealthControlled-vocabulary OWL ontology of biomedical-data-use restrictions (DUO:0000007 disease specific research, etc.)Active, embedded in dbGaP, EGA, Federated EGAhttps://github.com/EBISPOT/DUO
Row-level security (PostgreSQL CREATE POLICY)2016 (PostgreSQL 9.5)PostgreSQL Global Development GroupSQL CREATE POLICY ... USING (...) WITH CHECK (...) per-row predicate; adjacent to but inside SQL (sql)Active, the per-row authorization mechanism in modern apps (Supabase popularised it)https://www.postgresql.org/docs/current/sql-createpolicy.html

Notable threads

  • The SAML → OIDC succession. SAML 2.0 (2005) won enterprise SSO and is still mandatory for integrating into legacy SaaS in 2026. OIDC + JWT (2014–2015) won everything new — web, mobile, IoT, machine-to-machine. The interesting thing is that both stacks still ship in production identity products: every IdP (Okta, Entra ID, Auth0, Ping, Keycloak) supports both, because customer demand is bimodal. SAML is unlikely to be deprecated this decade purely because the long tail of enterprise SaaS hasn’t migrated and won’t migrate without a forcing function.

  • OPA Rego’s CNCF graduation (Aug 2021) and v1.0 syntax cleanup. OPA was the second policy-as-code engine to graduate CNCF (after Kyverno did so in March 2026). Rego is Datalog with sequencing, which is unusual — pure Datalog is order-insensitive but Rego adds sequenced statements within a rule body, partial evaluation for “what-if” queries, and negation-as-failure. OPA v1.0 (2025) was a deliberate breaking-change release that promoted if and contains to default keywords (previously requiring import rego.v1), broke long-deprecated APIs, and reset the v0 baggage that had accumulated since 2016. The migration tool (opa fmt --rego-v1) automates most of it.

  • Cedar’s verified-safe pitch. AWS published Cedar with a Lean-checked proof of soundness for the evaluator (you can run lake build in cedar-spec and reproduce the proof). That makes Cedar genuinely the first widely-deployed mainstream policy language with a formal soundness proof, a milestone analogous to CompCert for C compilers. AWS uses this as a differentiator against Rego: “Cedar is provably correct; Rego is not.” Rego counters with maturity, ecosystem, and the broader CNCF moat. Both are growing.

  • The Zanzibar lineage. Google’s 2019 USENIX ATC paper “Zanzibar: Google’s Consistent, Global Authorization System” described how Google centralises authorization for Drive, YouTube, Cloud, Maps, etc. behind a relationship-graph model with userset rewrites and zookies for snapshot-consistent reads. OpenFGA (originally Auth0 FGA, donated to CNCF Sept 2022; CNCF Incubating since 28 Oct 2025) and SpiceDB (Authzed) both implement the paper. Both treat authorization as a graph-traversal problem: “does there exist a path from user:alice to document:budget#viewer?” This is the modern alternative to RBAC (too coarse) and ABAC (too implicit-policy-heavy).

  • WebAuthn / Passkeys becoming mainstream. WebAuthn L2 was a W3C Recommendation in April 2021; L3 reached Candidate Recommendation on 13 January 2026, with a target Recommendation date of February 2026 or later. Apple, Google, and Microsoft completed mainstream passkey rollout in 2024–2025; passkeys are now the default on consumer accounts at most major IdPs. CTAP2 + CBOR attestation is the underlying wire format. DPoP (RFC 9449, 2023) modernised proof-of-possession for OAuth tokens, replacing the never-quite-shipped Token Binding (RFCs 8471–8473).

  • AWS IAM as the most-deployed policy DSL on Earth. Despite being JSON, AWS IAM is unambiguously a DSL: hundreds of action verbs, hundreds of condition keys, special vars (${aws:PrincipalTag/...}), policy variables, NotAction/NotResource inversions, principal-element shapes per scenario (resource-based, role-trust, KMS key, S3 bucket). Every AWS account has IAM policies; cumulatively this is billions of policies in production, more than every other policy DSL combined.

  • CEL as the new universal embeddable expression DSL. Google CEL is in GCP IAM Conditions, Kubernetes ValidatingAdmissionPolicy (GA in K8s 1.30, April 2024), CRD validation rules, Tetragon, gRPC server policies, Envoy, and Kyverno 1.18 (May 2026). It has effectively become the small expression DSL that K8s and Google-cloud projects standardise on, in the same role JavaScript played for browsers — small enough to embed everywhere, expressive enough to write nontrivial conditions.

  • The XACML survival pattern. XACML 3.0 (2013) is still alive in EU government, healthcare, and finance — partly because regulators wrote it into RFPs in 2014 and have never re-tendered, partly because no JSON successor offers XACML’s full PEP/PDP/PIP/PAP architecture. XACML 4.0 Committee Specification Draft 01 was published in February 2026, an attempt at modernisation with simplified syntax and JSON encodings. Whether that revives the standard or simply documents its decline is unclear.

  • The Oso pivot (Sept 2024). Oso (the OSS authorization library with Polar policies) was the most-promising pre-Cedar/pre-OpenFGA challenger. The legacy oso OSS library was deprecated September 2024 in favour of Oso Cloud (commercial SaaS that still uses Polar internally). This is a meaningful data point: the standalone “policy library” model was harder to monetise than the Zanzibar-style centralised service or the AWS-managed “Verified Permissions” model. OPA / Rego avoids this by having Styra Inc. behind it for commercial backing while remaining a CNCF graduated project.

Citations

Graph View