Construct a POST /access/v1/evaluation request and evaluate it against the in-memory PDP. All cryptographic operations run in Go/WASM — no server involved.

The same authorization policy yields different decisions depending on the strength of the subject's authentication. A passkey (WebAuthn L4) unlocks actions that an anonymous caller or API key cannot perform — without changing the policy, just the subject type.

The webauthn subject type that unlocked the PERMIT decision above comes from a specific registration ceremony. AuthZEN does not define how that credential is created — it only consumes the subject type. Here is what happens on the authentication side to produce a credential the PDP can trust at tier 4.

const credential = await navigator.credentials.create({
  publicKey: {
    rp:      { name: "authzen-poc.example", id: "authzen-poc.example" },
    user:    { id: new Uint8Array(16),         // opaque user handle
               name: "alice@example.com", displayName: "Alice" },
    challenge:        crypto.getRandomValues(new Uint8Array(32)),  // from RP — binds ceremony
    pubKeyCredParams: [{ type: "public-key", alg: -7 }],  // -7 = ES256 (COSE)
    authenticatorSelection: {
      residentKey:      "required",    // device-bound credential → tier 4
      userVerification: "required"     // biometric or PIN mandatory
    },
    attestation: "none"                     // no device attestation needed here
  }
});

// What you get back:
credential.id                           // base64url credential ID — store this
credential.response.attestationObject   // CBOR: authData + credentialPublicKey
credential.response.clientDataJSON      // challenge echo + origin (JSON)

Edit the in-memory PDP rules. Changes immediately affect evaluations in all tabs. Rules are evaluated by priority (higher = first); ties broken by position (later wins). No match → default deny.

Export the current rules to OpenFGA DSL or OPA Rego. Open the respective playground tab to run them interactively.

AuthZEN §5.2: a single request carries a shared Subject plus an array of (Resource, Action) pairs. The PDP evaluates each independently and returns an array of decisions. Useful for permission checks across multiple resources in one round-trip.

Implements the mapping defined in draft-gazitt-oauth-authzen-token-exchange-00

When an Authorization Server receives an RFC 8693 Token Exchange request, it must decide whether to issue the requested token. This simulation shows how the AS constructs an AuthZEN evaluation request from the exchange parameters and calls the PDP to get its decision — replacing the "local policy" black box with a standard API call.

openfga.dev/docs/interacting/authzen  ·  play.fga.dev  ·  OpenFGA DSL schema 1.1

OpenFGA exposes a built-in AuthZEN-compatible endpoint at POST /stores/{id}/access/v1/evaluation. The same five-tuple request you send to this PoC's in-memory PDP can be sent directly to OpenFGA — the difference is the backend evaluates using a relationship graph (Google Zanzibar model) rather than glob rules.

The current InMemoryPDP rules are exported as an OpenFGA DSL model and YAML tuple set. Copy both into play.fga.dev to run the same evaluations in OpenFGA.

play.openpolicyagent.org  ·  Rego v1 language reference

OPA evaluates AuthZEN five-tuple requests as Rego policy input. The generated policy accepts the same { subject, resource, action } structure and returns decision := true/false. Use the OPA playground to test the generated policy interactively.

Lambda Authorizers are a natural PEP — AuthZEN standardises exactly what happens inside that function.

AuthZEN defines the API contract, not the deployment topology. Choose your resilience pattern.

Adding a synchronous AuthZEN call to the critical path has cost. Here are the mitigation patterns.

Last checked: 2026-08-07  ·  standards-baseline.json  ·  standards-tracker.yml