# Standards watch list

Source: https://permdock.com/docs/standards/watch-list

Every specification PermDock follows, its maturity, why it matters for a permissions library, what PermDock does about it, and its draft posture.

Status: tracking

This page is the inventory behind the [standards](/docs/standards) section. Each standards page covers one specification PermDock implements or that shapes a public API; this list also covers the ones it only follows. It is the one place to check whether a draft that changed last month affects an adapter.

## How the list is maintained [#how-the-list-is-maintained]

* Each row's maturity is checked at every release against the publishing body's index (the OpenID Foundation specifications index, the IETF datatracker, the OpenAPI Initiative, the MCP and A2A sites) and updated in the release pull request. Dates and maturity are copied from the body, never inferred.
* A row stays when its specification gets a standards page; the page becomes its link.
* A row with a concrete action keeps a pointer to the page that documents it.

**Action** vocabulary: **implements** (an adapter or core feature exists or is planned), **consumes** (PermDock reads what the spec produces, without a dedicated adapter), **checklist** (the spec constrains how an adapter is written), **tracking** (followed, no code planned).

**Posture** vocabulary for unfinished texts: **build** (PermDock implements the draft's current shape, pinned to a named revision written on the standards page and, for documents, into the output), **name** (PermDock reserves the identifiers the specification will need, so adopting it later renames nothing, and emits or consumes nothing from the draft), **track** (followed, no identifier depends on it), **stable** (the text is Final, an RFC or Released). A row is built only when the capability is needed now, the draft is concrete enough for fixtures, and a stable twin can carry the same information for consumers that ignore the draft.

## Maturity terms [#maturity-terms]

| Term | Body | Meaning for PermDock |
| --- | --- | --- |
| Final | OpenID Foundation | Stable; implement and, where a programme exists, certify |
| Implementer's draft | OpenID Foundation | Stable enough to build against with small changes expected; implemented only when the feature is needed now |
| RFC | IETF | Stable; referenced by number |
| RFC Editor queue | IETF | Approved; content final, number not yet assigned |
| WG draft | IETF | Adopted by a working group; designed against, but no wire format is fixed on it |
| Individual draft | IETF | Not adopted; tracking only |
| Released | OpenAPI Initiative, MCP, A2A | A versioned specification is published |
| In development | OpenAPI Initiative | On a development branch; emitted only behind an experimental target with a build posture |
| Draft Community Group Report | W3C | Incubation that may change without notice; built only with a pinned date |
| Development | OpenTelemetry | Semantic conventions whose names may change; copied names are pinned |

## The list [#the-list]

| Spec | Body | Date and maturity | Relevance | PermDock action | Posture |
| --- | --- | --- | --- | --- | --- |
| [Authorization API 1.0 (AuthZEN)](/docs/standards/authzen) | OpenID Foundation | Final, Jan 2026; certification levels Basic, Batch, Search, Discovery | Wire format between PEPs and PDPs | Implements: the decision endpoint, `permdock/authzen`, `permdock/pdp` | stable |
| [Shared Signals Framework 1.0, CAEP 1.0, RISC 1.0](/docs/standards/shared-signals-caep) | OpenID Foundation | Final, Sep 2025 | Session revocation and credential-change events | Implements: `permdock/ssf` receiver invalidating snapshots | stable |
| CAEP Interoperability Profile 1.0 | OpenID Foundation (Shared Signals WG) | Implementer's draft, Jul 2026 | Which CAEP events and delivery a receiver must support | Checklist for the [`ssf` adapter](/docs/adapters/ssf) | name |
| [OpenID Connect Core 1.0, Discovery 1.0](/docs/standards/openid-connect) | OpenID Foundation | Final (Core errata set 2, Dec 2023; ISO/IEC 26131:2024) | ID token claims, subject identifier types, the Discovery document | Implements: `discovery` and `accept` in `permdock/jwt`; `principal.issuer`, `principal.assurance`, `subject.session` | stable |
| [OpenID Connect Back-Channel Logout 1.0](/docs/standards/openid-connect) | OpenID Foundation | Final | `logout_token` sent when the OP session ends | Implements: a revocation input to `permdock/ssf` next to CAEP `session-revoked` | stable |
| RFC 9470 OAuth 2.0 Step Up Authentication Challenge | IETF OAuth WG | RFC, Sep 2023 | `insufficient_user_authentication` with `acr_values` and `max_age` | Implements: the HTTP rendering of an `insufficient-user-authentication` denial ([OpenID Connect](/docs/standards/openid-connect)) | stable |
| OpenID Federation 1.0 | OpenID Foundation | Final, Feb 2026 | Trust between parties without pairwise configuration | Tracking: trust between `permdock/pdp` and a remote PDP | track |
| OpenID Connect Enterprise Extensions (`session_expiry`) | OpenID Foundation | Draft, Sep 2025 | When the IdP session ends | Consumes: `session_expiry` as an upper bound on snapshot staleness | name |
| OpenID Provider Commands | OpenID Foundation | Draft, Sep 2025 | IdP-initiated lifecycle commands (deprovision, revoke) | Tracking: overlaps CAEP for invalidation | track |
| IPSIE Common Requirements 1.0 | OpenID Foundation (IPSIE WG) | Draft 00, Aug 2025 | Session Lifecycle SL1-SL3, Account Lifecycle AL1-AL3 | Checklist for provider adapters | name |
| IPSIE SL1 OpenID Connect Profile | OpenID Foundation (IPSIE WG) | Draft 00, Apr 2025 | `iss` in responses, PKCE, RFC 8414, `acr` / `amr` / `auth_time` / `session_expiry`, DPoP SHOULD | Checklist: which claims provider adapters expose | name |
| IPSIE AL1 SCIM 2.0 Profile | OpenID Foundation (IPSIE WG) | Draft | RFC 7523 JWT bearer authentication and attribute requirements for SCIM | Checklist for [`permdock/scim`](/docs/adapters/scim): `verifier` accepts the RFC 7523 bearer; attributes compared once the profile reaches implementer's draft | name |
| OpenID4VP 1.0, OpenID4VCI 1.0 | OpenID Foundation | Final, Jul 2025 and Sep 2025 | Verifiable credential presentation and issuance | Tracking: verified attributes as `principal` inputs | stable |
| OpenID Connect for Identity Assurance 1.0 (`verified_claims`) | OpenID Foundation | Final with errata, Jul 2026 | Claims carrying assurance level and evidence | Implements: `verified_claims` mapped into `principal.assurance.verified` by `permdock/jwt` ([OpenID Connect](/docs/standards/openid-connect)) | stable |
| OpenID Connect Ephemeral Subject Identifier | OpenID Foundation | Draft, Jul 2026 | Per-transaction subject identifiers | Checklist: audit events must not assume a stable `principal.id` | name |
| OpenID Connect Key Binding | OpenID Foundation | Draft, Aug 2026 | Binding ID tokens to client keys | Tracking: `permdock/jwt` `sender` once stable | track |
| Grant Management for OAuth 2.0 | OpenID Foundation (FAPI WG) | Implementer's draft | Grants as manageable consent objects | Tracking: `grant_id` in audit, revoked grants as invalidation | track |
| [FAPI 2.0 Security Profile](/docs/standards/fapi-2) | OpenID Foundation (FAPI WG) | Final | Resource-server and cryptography requirements | Implements: `permdock/jwt` `profile: 'fapi2'`; `x-permdock-securityProfile` | stable |
| RFC 9700 OAuth 2.0 Security Best Current Practice | IETF OAuth WG | RFC, Jan 2025 | Baseline security for resource servers | Checklist for `permdock/jwt` defaults and the [threat model](/docs/security/threat-model) | stable |
| [RFC 7515-7519 (JWS, JWE, JWK, JWA, JWT), RFC 8037](/docs/standards/jose) | IETF JOSE WG | RFCs, May 2015 and Jan 2017 | Token, signature, key and algorithm formats | Implements: verification through `TokenVerifier`; JWS-signed snapshots, approval tokens and decision exports through `TokenSigner` | stable |
| RFC 8725 JWT BCP and rfc8725bis | IETF OAuth WG | RFC; bis in the RFC Editor queue, Aug 2026 | Algorithm allow-lists, `typ`, `kid`, key confusion | Checklist for `permdock/jwt` ([JOSE](/docs/standards/jose)) | name |
| [RFC 9864 Fully-Specified Algorithms](/docs/standards/jose) | IETF JOSE WG | RFC, 2025 | `Ed25519` and `Ed448` as JWS `alg`; polymorphic `EdDSA` deprecated | Implements: `Ed25519` in the allow-lists; `permdock doctor` warns on `EdDSA` | stable |
| draft-ietf-jose-deprecate-none-rsa15 | IETF JOSE WG | WG draft, 2026 | Deprecates `none` and `RSA1_5` | Checklist: `permdock/jwt` already refuses both | name |
| [RFC 9068 `roles`, `groups`, `entitlements` claims](/docs/standards/jwt-authorization-claims) | IETF OAuth WG | RFC, Oct 2021; claims registered at IANA | Role and group material on access tokens, SCIM encoding | Implements: the default claim mapping into `principal.roles` and team memberships | stable |
| [RFC 7643 / 7644 SCIM 2.0, RFC 9865 cursor pagination](/docs/standards/scim) | IETF SCIM WG | RFCs, Sep 2015; RFC 9865, 2025 | `User` and `Group` provisioning | Implements: `permdock/scim` writing a `DirectoryStore`, `directoryMembershipSource`, the PermDock roles extension | stable |
| OAuth AuthZEN Claims (draft-gazitt-oauth-authzen-claims) | IETF (individual draft) | Draft 00, 2026 | An authorization server obtaining `roles` / `groups` / `entitlements` from a PDP's Resource Search | Tracking: `permdock/authzen` `/search/resource` as a claim source | track |
| RFC 9396 Rich Authorization Requests | IETF OAuth WG | RFC | Structured `authorization_details` | Implements: `delegation.authorizationDetails`, one type per permission | stable |
| OAuth 2.0 RAR Metadata and Error Remediation | IETF OAuth WG | Draft, Aug 2026 | RAR type metadata and structured remediation | Implements: `Decision.alternatives` in the remediation shape ([delegation](/docs/security/delegation)) | build (pinned: draft-ietf-oauth-rar-metadata-remediation, Aug 2026 revision) |
| OAuth Identity and Authorization Chaining Across Domains | IETF OAuth WG | RFC Editor queue, Jul 2026 | Identity and authorization across trust domains | Implements: `delegation.chain` verification | name |
| Agent Delegation Chain (draft-asor-wimse-agent-delegation-chain); Credential Delegation Protocol (draft-sweeney-wimse-credential-delegation); OAuth for AI agents on behalf of a user (draft-oauth-ai-agents-on-behalf-of-user) | IETF (individual drafts) | Drafts, 2026 | Monotonic attenuation across multi-hop agent chains as RAR; composing RFC 8693, DPoP, RAR and CIBA; `requested_actor` and `actor_token` | Tracking: inputs to `delegation.chain` and the `actor` mapping ([OAuth for agents](/docs/standards/oauth-agent-delegation)) | track |
| Transaction Tokens | IETF OAuth WG | WG draft rev 11, Jul 2026 | Identity and authorization context through a call chain in one domain | Consumes: snapshot id and decision id in `azd`, subject re-derived from `sub_id` and `azd` ([delegation](/docs/security/delegation)) | name |
| Transaction Tokens for Agents; Cross-domain Transaction Tokens; Transaction Tokens BCP | IETF (individual drafts) | Drafts, May to Jul 2026 | Agent and cross-domain extensions | Tracking with the transaction-token row | track |
| WIMSE architecture | IETF WIMSE WG | WG draft 08, Jul 2026 | Workload identity and context propagation | Checklist: workloads as service principals ([subject](/docs/concepts/subject)) | name |
| GNAP (RFC 9635) | IETF | RFC, Oct 2024 | Successor negotiation protocol; `access` rights array | Consumes: `delegation.access` next to `authorizationDetails`; no client (see [GNAP](#gnap) below) | stable (RFC); OpenAPI scheme: name |
| RFC 9767 GNAP Resource Server Connections | IETF | RFC, 2025 | Token model with a JWT mapping, introspection with an `access` array, RS discovery | Implements: the `access` claim and `subjectFromIntrospection` in `permdock/jwt` | stable |
| OAuth 2.1 | IETF OAuth WG | Draft | OAuth 2.0 consolidated, PKCE required, no implicit or password grants | Checklist: MCP servers are OAuth 2.1 resource servers; `permdock/jwt` defaults follow it | name |
| RFC 9449 DPoP, RFC 8705 mTLS | IETF OAuth WG | RFCs | Sender-constrained tokens | Implements: `permdock/jwt` `sender: 'dpop'` or `'mtls'` | stable |
| RFC 9728 Protected Resource Metadata | IETF OAuth WG | RFC | Discovery document a resource server publishes | Consumes: required by [MCP authorization](/docs/standards/mcp-authorization) | stable |
| [RateLimit header fields](/docs/standards/ratelimit-headers) | IETF | WG draft, `-11`, May 2026 | Tells a client how long to back off after an exhausted `limit` grant | Implements: `429` with `Retry-After`, `RateLimit` and `RateLimit-Policy` in HTTP adapters | build (`draft-ietf-httpapi-ratelimit-headers-11`) |
| [Web Bot Auth](/docs/standards/web-bot-auth) (RFC 9421, Signature-Agent) | IETF | Drafts | Verified identity for automated HTTP clients | Implements: the verified signer becomes `actor` in HTTP adapters | build (`draft-meunier-webbotauth-httpsig-protocol-02`) |
| [OpenAPI 3.2](/docs/standards/openapi) | OpenAPI Initiative | Released Sep 2025 | Device flow, `oauth2MetadataUrl`, `deprecated` schemes, URI-referenced schemes | Implements: the default `permdock openapi` target | stable |
| [OpenAPI 3.3](/docs/standards/openapi) | OpenAPI Initiative | In development (`v3.3-dev` is still the 3.2 text; Security Profiles in Discussion #5304) | Security Profiles, security configuration updates, Standardized API Features | Implements: `--target 3.3` emits the pinned draft with `x-permdock-securityProfile` as twin and the pin in `x-permdock-catalog.drafts` | build (pinned: Discussion #5304 expanded design notes, Sep 2026) |
| [OpenAPI Overlay 1.1](/docs/standards/openapi-overlay) | OpenAPI Initiative | Released Jan 2026 | Repeatable document transformations | Implements: `permdock openapi --format overlay` | stable |
| Overlay 1.2 | OpenAPI Initiative | In development (`v1.2-dev` text complete) | Reusable actions (`components.actions`, `$ref`) | Implements: `--overlay 1.2` emits one reusable action per permission set; 1.1.0 stays the default ([Overlay](/docs/standards/openapi-overlay)) | build (pinned: `v1.2-dev` at `edd4adea`, Aug 2026) |
| [Arazzo 1.1](/docs/standards/arazzo) | OpenAPI Initiative | Released May 2026 | Multi-step API workflows | Consumes: the permissions a workflow needs, step by step | stable |
| AsyncAPI 3 | AsyncAPI Initiative | Released | Event-driven API descriptions; an Arazzo 1.1 source type | Tracking: no emitter; if needed, the same Overlay engine pointed at an AsyncAPI document | track |
| [OpenAPI registries](/docs/standards/openapi-registry) | OpenAPI Initiative | Living registries | Extension and namespace registration | Implements: register the `x-permdock-` namespace | stable |
| [A2A 1.0](/docs/standards/a2a) | Linux Foundation | 1.0 | Agent Card `securitySchemes` and `securityRequirements`, signed cards, per-caller extended cards | Implements: `permdock/a2a` | stable |
| [MCP authorization](/docs/standards/mcp-authorization) | Model Context Protocol | Spec 2026-07-28 | OAuth 2.1 resource servers, `scopeChallenge` step-up with SEP-2350 scope accumulation, Enterprise-Managed Authorization (ID-JAG via RFC 8693 and RFC 7523), Client ID Metadata Documents, RFC 9207 `iss` validation | Implements: `permdock/mcp` | stable |
| [WebMCP](/docs/standards/webmcp) | W3C Web Machine Learning CG | Draft Community Group Report; `document.modelContext` in Chrome 150 | Page-registered tools, `tools` Permissions-Policy, `readOnlyHint`, `AbortSignal` unregistration | Implements: `permdock/webmcp` | build (pinned on the [WebMCP adapter](/docs/adapters/webmcp)) |
| [AGENTS.md, Agent Skills, llms.txt](/docs/standards/agent-docs-standards) | Agentic AI Foundation (Linux Foundation) for AGENTS.md and Skills; community for llms.txt | Governed since Dec 2025 | Instructions and skills formats agents already read | Implements: shipped `permdock` and `permdock-*` skills, `AGENTS.md`, `llms.txt` | stable |
| OWASP Top 10 for Agentic Applications | OWASP GenAI project | Released Dec 2025 | ASI02 Tool Misuse, ASI03 Identity and Privilege Abuse; per-tool least-privilege profiles, human-in-the-loop gates, "Least Agency" | Checklist: the [OWASP agentic mapping](/docs/security/owasp-agentic) | stable |
| SPIFFE / SPIRE | CNCF | Graduated; SVID formats stable | Workload identity documents | Consumes: a verified SVID as `actor` material | stable |
| OCSF | Linux Foundation | Schema 1.x released | Vendor-neutral event schema SIEMs ingest | Consumes: `toOcsf`, a projection of decision events onto OCSF 1.3.0 Authorize Session ([audit](/docs/concepts/audit-and-observability)) | stable |
| CloudEvents 1.0 | CNCF | Released | Common event envelope | Consumes: the envelope for decision events leaving a `DecisionSink` ([wire formats](/docs/concepts/wire-formats)) | stable |
| AG-UI | CopilotKit (open protocol) | Released, evolving | Agent-to-UI event stream with human-in-the-loop events | Tracking: where `approval-required` surfaces in a chat UI ([ecosystem index](/docs/research/ecosystem-index)) | track |
| TypeSpec | Microsoft (open source) | 1.0 GA, 2025 | Design-first language emitting OpenAPI 3.0 to 3.2 | Consumes: the Overlay applies to the emitted document ([OpenAPI adapter](/docs/adapters/openapi)) | stable |
| Cedar | AWS (Apache-2.0); used by Amazon Verified Permissions and AgentCore Policy | Language 4.x | Permit and forbid with `when`, deny-overrides-permit | Tracking: a compile target is considered and not scheduled ([landscape](/docs/research/landscape)) | track |
| OpenFeature | CNCF (incubating) | Specification 0.9.0, Jul 2026 | Vendor-neutral flag evaluation API | Consumes: how `subject` or `context` reads a flag ([policies](/docs/concepts/policies)) | track |
| Supabase capability matrix (`supabase/sdk` `packages/capability-matrix`) | Supabase | `capability-matrix-v1.12.0`, Sep 2026; conformance-vector schema in review ([PR #30](https://github.com/supabase/sdk/pull/30)) | Three-segment capability ids shared by every Supabase client SDK; a `{ feature, cases }` vector shape | Consumes: capability ids in the Supabase manifest's `requires`; `supabaseClaimVectors` follows the vector shape ([Supabase](/docs/adapters/supabase)) | name |
| `@supabase/server/mcp` | Supabase | Alpha, unreleased: [PR #146](https://github.com/supabase/server/pull/146) (`1.7.0-beta.0`), tracking `@modelcontextprotocol/server` 2.x | `generateTools` builds MCP tools from the PostgREST OpenAPI description the caller sees, under the caller's role and RLS | Nothing built against the draft. Planned: a recipe that filters the generated tools through `permdock/mcp` once it ships ([roadmap](/docs/roadmap)) | track |
| Splinter lints | Supabase | CalVer releases; 2026.09.1, Sep 2026 | The advisor rules Supabase applies to every project's schema | Checklist: generated RLS raises no WARN or ERROR lint ([Postgres RLS](/docs/standards/postgres-rls#splinter-supautils-and-pg_jsonschema)) | stable |
| OpenTelemetry GenAI semantic conventions | OpenTelemetry (CNCF) | Development; `execute_tool` and `gen_ai.tool.*` not yet stable | Span names and attributes for agent tool calls | Consumes: `permdock.decide` nests under `execute_tool` and copies `gen_ai.tool.name` and `gen_ai.tool.call.id` ([OpenTelemetry adapter](/docs/adapters/otel)) | build (pinned: semantic conventions 1.37.0) |
| AP2, Visa Trusted Agent Protocol, Stripe Agentic Commerce Protocol | Google, Visa, Stripe | Published protocols, 2025-2026 | Signed payment intents for agents | Tracking: adjacent context for signed-intent constraints, not a PermDock surface | track |
| EU AI Act traceability obligations | European Union | Regulation in force; high-risk obligations may be delayed | Record-keeping for AI systems | Tracking: a reason decision audit trails matter ([audit](/docs/concepts/audit-and-observability)) | track |

## By PermDock concept [#by-permdock-concept]

The same rows grouped by the part of PermDock they touch; every specification under a concept may constrain a change to it.

* **Subject (`principal`, `actor`, `binding`, `memberships`).** OpenID Connect Core and Discovery define identity claims and key discovery; the JOSE RFCs, RFC 8725 and its bis, RFC 9864, FAPI 2.0, DPoP, mTLS, RFC 9700, OAuth 2.1 and IPSIE SL1 define what `permdock/jwt` accepts; RFC 9470 defines the assurance denial. RFC 9068 and SCIM define the claims that become roles and team memberships; the AuthZEN claims draft is how a PDP could supply them. WIMSE, SPIFFE and transaction tokens define workloads as principals; Web Bot Auth fills `actor` for plain HTTP. IDA `verified_claims` and verifiable credentials feed `principal.assurance`. The Ephemeral Subject Identifier draft means `principal.id` may not be stable across sessions.
* **Delegation (`scopes`, `authorizationDetails`, `access`, `chain`).** RFC 9396 and GNAP define the structured formats; RAR Error Remediation defines how insufficient authorization is reported; Identity Chaining and the agent-delegation drafts define `chain`; Grant Management defines the consent object.
* **Decision.** AuthZEN is the wire format; RAR Error Remediation and RFC 6750 shape how `alternatives` reaches OAuth clients; MCP, A2A and WebMCP shape how it reaches agents; the OWASP agentic list names the risks.
* **Snapshot freshness.** SSF, CAEP, RISC and the CAEP Interoperability Profile deliver invalidation; Back-Channel Logout is a second input; OpenID Provider Commands overlaps; JOSE defines the signed-snapshot envelope; `session_expiry` and IPSIE SL1 bound snapshot lifetime.
* **Catalog and documents.** OpenAPI 3.2 and 3.3, Overlay 1.1 and the pinned 1.2 draft, Arazzo and the registries define what `permdock openapi` and `permdock collect` emit; AsyncAPI is tracked; TypeSpec is a producer. RFC 9728 defines what an MCP server publishes about itself. AGENTS.md and Agent Skills define the shipped skills.
* **Policy inputs.** OpenFeature defines how a flag is read before it selects a role; Cedar is the one external policy language whose combining rule matches PermDock's.
* **Audit events.** OCSF, CloudEvents and the OpenTelemetry GenAI conventions; the EU AI Act is a reason to keep them.
* **Trust between services.** Transaction tokens inside a domain, Identity Chaining across domains, WIMSE and SPIFFE for workload identity, OpenID Federation between `permdock/pdp` and a remote PDP.

## GNAP [#gnap]

[RFC 9635](https://datatracker.ietf.org/doc/html/rfc9635) defines one grant negotiation in place of OAuth's family of grant types. What a permissions library cares about is the `access` rights array (section 8): objects with a required `type` and optional `actions`, `locations`, `datatypes`, `identifier` and `privileges`, or plain reference strings like scopes. Fields inside one object form a cross-product; objects across the array are a union. The structure is deliberately analogous to RFC 9396 `authorization_details`, so PermDock's RAR support covers most of it, and the two bodies converging on `type` plus `actions` plus `identifier` validates the permission leaf shape.

PermDock consumes GNAP material and ships no client:

* `delegation.access` accepts the array next to `scopes` and `authorizationDetails`. The three are unioned into one delegated set, then intersected with the principal's grants, so an `access` object never adds a grant, an unknown `type` contributes nothing, and a malformed object denies the permissions it names ([delegation](/docs/security/delegation)). `type` is the catalog's stable resource URI, `actions` are action keys, `identifier` is a resource-id constraint, reference strings match `permission.scope`, and `locations`, `datatypes` and `privileges` are recorded in audit only.
* [RFC 9767](https://www.rfc-editor.org/rfc/rfc9767.html) defines how a resource server reads GNAP tokens. [`permdock/jwt`](/docs/adapters/jwt) maps an `access` claim in `jwt-signed` tokens onto `delegation.access`, and `subjectFromIntrospection` maps an introspection response (`sub`, `iss`, `instance_id` as `actor.id`, `access`, `key` as `binding`); an inactive answer is the anonymous subject.
* GNAP interaction (`redirect`, `user_code`, `app`) and continuation are the same state as `approval-required` and a retried check with the approval `token`, one layer down.
* In OpenAPI the posture is **name**: `scheme.type: 'gnap'` is reserved and emits nothing, and the community `x-gnap` extension is never written ([OpenAPI 3.2 and 3.3](/docs/standards/openapi)).

Triggers for moving GNAP from tracking to planned: a major identity vendor shipping a GNAP authorization server, MCP or A2A adopting GNAP, or a `v3.3-dev` pull request defining a GNAP security scheme (funded work toward one is under way). Today the one production deployment is the Interledger Foundation's Open Payments API.

## Review cadence [#review-cadence]

At each release the maintainer checks every row: has the maturity changed, has the body renamed or split the document, does the change touch existing behaviour. A maturity change alone updates the row. A change to existing behaviour opens an issue against the adapter page and, if a wire format or security default moves, updates the owning page's Why section and the rows listed in `.agents/rules/change-checklist.mdc`. Checklist rows are re-read against their adapter whenever it changes. Build rows are checked against their pin: the maintainer either bumps the pin (standards page, output, fixtures, changeset) or records why the old revision is kept; a build row whose text reaches Final, RFC or Released loses its pin and becomes stable.

## How to propose a row [#how-to-propose-a-row]

1. Open an issue titled `watch: <spec name>` with the canonical URL, the current maturity and its date.
2. State in one sentence which PermDock concept the specification touches.
3. Propose the action (implements, consumes, checklist, tracking).
4. For an unfinished text, propose the posture and, for build, the revision to pin and the stable twin.
5. Say whether it changes a wire format or a security default; if it does, update the owning page's Why section and the rows listed in `.agents/rules/change-checklist.mdc`.

Rows are added by pull request against this page. A row that reaches "implements" gets its own standards page in the same pull request as the code.

## Sources [#sources]

* [OpenID Foundation specifications index](https://openid.net/developers/specs/); [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html), [Discovery 1.0](https://openid.net/specs/openid-connect-discovery-1_0.html), [Back-Channel Logout 1.0](https://openid.net/specs/openid-connect-backchannel-1_0.html), [AuthZEN 1.0](https://openid.net/specs/authorization-api-1_0.html), [FAPI 2.0](https://openid.net/specs/fapi-security-profile-2_0-final.html).
* [IPSIE Working Group specifications](https://openid.net/wg/ipsie/specifications/), the [SL1 profile](https://openid.github.io/ipsie-openid-sl1/draft-openid-ipsie-sl1-profile.html), the [AL1 SCIM profile](https://openid.github.io/ipsie-scim-al1/draft-ipsie-scim-al1-profile.html), [Common Requirements](https://openid.net/specs/ipsie-common-requirements-1_0-00.html).
* [RFC 7515](https://www.rfc-editor.org/rfc/rfc7515.html) to [RFC 7519](https://www.rfc-editor.org/rfc/rfc7519.html), [RFC 8037](https://www.rfc-editor.org/rfc/rfc8037.html), [RFC 9068](https://www.rfc-editor.org/rfc/rfc9068.html), [RFC 7643](https://www.rfc-editor.org/rfc/rfc7643.html), [RFC 7644](https://www.rfc-editor.org/rfc/rfc7644.html), [RFC 9470](https://www.rfc-editor.org/rfc/rfc9470.html), [RFC 9635](https://datatracker.ietf.org/doc/html/rfc9635), [RFC 9767](https://www.rfc-editor.org/rfc/rfc9767.html), [RFC 9864](https://www.rfc-editor.org/rfc/rfc9864.html), and the [IANA JOSE](https://www.iana.org/assignments/jose/jose.xhtml) and [JWT claims](https://www.iana.org/assignments/jwt/jwt.xhtml) registries.
* [Transaction Tokens](https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/), [WIMSE architecture](https://datatracker.ietf.org/doc/html/draft-ietf-wimse-arch), [Agent Delegation Chain](https://datatracker.ietf.org/doc/html/draft-asor-wimse-agent-delegation-chain-00), [Credential Delegation Protocol](https://datatracker.ietf.org/doc/draft-sweeney-wimse-credential-delegation/), [OAuth for AI agents on behalf of a user](https://datatracker.ietf.org/doc/html/draft-oauth-ai-agents-on-behalf-of-user-02), [draft-ietf-jose-deprecate-none-rsa15](https://datatracker.ietf.org/doc/draft-ietf-jose-deprecate-none-rsa15/), [draft-gazitt-oauth-authzen-claims-00](https://www.ietf.org/archive/id/draft-gazitt-oauth-authzen-claims-00.txt).
* [OpenAPI milestones](https://github.com/OAI/OpenAPI-Specification/milestones), [Discussion #5304](https://github.com/OAI/OpenAPI-Specification/discussions/5304), [Overlay 1.1.0](https://spec.openapis.org/overlay/v1.1.0.html), [Arazzo 1.1.0](https://spec.openapis.org/arazzo/v1.1.0.html), [OpenAPI registries](https://spec.openapis.org/registry/).
* [MCP specification 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization), [A2A specification](https://a2a-protocol.org/latest/specification/), [WebMCP in Chrome](https://developer.chrome.com/docs/ai/webmcp), [OWASP Top 10 for Agentic Applications](https://genai.owasp.org/download/52117).
* [SPIFFE](https://spiffe.io/docs/latest/spiffe-about/overview/), [OCSF](https://schema.ocsf.io/), [CloudEvents](https://cloudevents.io/), [AG-UI](https://docs.ag-ui.com/).

## Related [#related]

* [Standards](/docs/standards): the pages for everything PermDock implements.
* [Roadmap](/docs/roadmap) and [adapters](/docs/adapters).
* [Threat model](/docs/security/threat-model) and [delegation](/docs/security/delegation): where the checklist rows are applied.