Standards watch list

Status: tracking Phase: 1

This page is the inventory behind the standards section. Each standards page covers one specification PermDock implements or targets; this list also covers the ones it only follows. It is the single place to check whether a draft that changed last month affects a PermDock adapter.

How the list is maintained

• The list is reviewed at every release. Each row's "Date and maturity" is checked against the publishing body's index (the OpenID Foundation specifications index, the IETF datatracker, the OpenAPI Initiative specification site, the MCP and A2A specification sites) and updated in the same pull request as the release changeset.
• A row whose "PermDock action" is a concrete change to an adapter, the core or the CLI stays here until that change ships, then keeps a short pointer to the page that documents it.
• A specification gets its own page under standards/ when PermDock implements it, or when it shapes a public API even before code exists (as GNAP and FAPI 2.0 do). The row stays; the page becomes its link.
• Rows never disappear silently. A specification PermDock stops following moves to "Removed rows" with the reason and the release in which it was removed.
• Dates and maturity levels are copied from the publishing body, never inferred. A row without a date means the source index did not give one at the last review.

Status vocabulary for the "PermDock action" column: implements (an adapter or core feature exists or is planned with a phase), 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).

Vocabulary for the "Posture" column, which says what PermDock may do with an unfinished text (ADR 0025): build (PermDock implements the draft's current shape, pinned to a named revision that is written on the standards page and, for documents, into the output; the row names the pin), name (PermDock reserves the public 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; the action column alone applies). A row is built only when PermDock needs the capability in the same phase, the draft is concrete enough to write fixtures against, and a stable twin can carry the same information for consumers that ignore the draft.

Reading the table

The "Date and maturity" column uses each body's own vocabulary, which is not interchangeable:

The "Phase" column is the first phase in which PermDock acts on the row, following the same rule as the Phase line on every standards page. Adapter phases are those of the adapter matrix. A row whose action is tracking has no phase and says so. The "Posture" column applies the vocabulary above; the pin named in a build row is the revision PermDock's output and fixtures follow until a maintainer bumps it.

The list

By PermDock concept

The same rows, grouped by the part of PermDock they touch. This is the view to use when changing one of these concepts: every specification listed under it may constrain the change.

• Subject (principal, actor, binding, memberships). FAPI 2.0, DPoP and mTLS, RFC 8725 and rfc8725bis, RFC 9700, OAuth 2.1 and the IPSIE SL1 profile define what permdock/jwt may accept and which claims reach the principal. RFC 9068 and SCIM define the roles, groups and entitlements claims that become global roles and team memberships, and the AuthZEN claims draft is how a PDP could supply them. WIMSE and the transaction-token drafts define workloads as principals. Web Bot Auth fills actor for plain HTTP. IDA verified_claims and the verifiable-credential specifications are the candidate sources for principal.assurance. The Ephemeral Subject Identifier draft is a reminder that principal.id may not be stable across sessions.
• Delegation (scopes, authorizationDetails, access, chain). RFC 9396 and GNAP define the two structured formats; RAR Metadata and Error Remediation defines how insufficient authorization is reported back; Identity and Authorization Chaining defines chain; Grant Management defines the consent object the delegation came from.
• Decision (granted, denied, approval-required, alternatives). AuthZEN is the wire format; RAR Error Remediation and RFC 6750 (through FAPI 2.0) shape how alternatives is rendered to OAuth clients; MCP and A2A shape how it is rendered to agents.
• Snapshot freshness. SSF, CAEP, RISC and the CAEP Interoperability Profile deliver invalidation events; OpenID Provider Commands is the overlapping alternative; session_expiry from the Enterprise Extensions and the IPSIE SL1 profile bound how long a snapshot may live.
• Catalog and documents. OpenAPI 3.2 and 3.3, Overlay 1.1 (and the pinned 1.2 draft behind --overlay 1.2), Arazzo and the registries define what permdock openapi and permdock collect emit and how x-permdock- extensions are registered; AsyncAPI is tracked as a format a later Overlay revision might target; TypeSpec is a producer whose output the Overlay applies to. RFC 9728 defines the metadata an MCP server publishes about itself.
• 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 and is therefore a possible compile target.
• Audit events. OCSF defines the class a DecisionSink projects decision events onto for SIEMs; CloudEvents defines the envelope when those events leave the process; the OpenTelemetry GenAI conventions define the tool span a decision nests under.
• Trust between services. Transaction tokens carry context inside a domain; Identity Chaining carries it across domains; WIMSE and SPIFFE define the workload identities that become actor; OpenID Federation is the candidate for establishing trust between permdock/pdp and a remote PDP without pairwise configuration.

Review cadence

Each release the maintainer running the release checks, per row: has the maturity changed (draft to implementer's draft, RFC Editor queue to RFC, in development to released); has the publishing body renamed or split the document; does the change touch a PermDock action that has already shipped. A maturity change alone updates the row. A change to a shipped behaviour opens an issue against the adapter page and, if a wire format or security default moves, a decision record. Rows whose action is "checklist" are re-read against the adapter they constrain at the release that ships that adapter. Rows whose posture is "build" are checked against their pin: if the draft moved, 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 in the release that adopts the final shape.

How to propose a row

1. Open an issue titled watch: <spec name> with the canonical URL from the publishing body, the current maturity (final, implementer's draft, RFC, RFC Editor queue, working-group draft, individual draft, in development) and its date.
2. State the relevance in one sentence: which PermDock concept (subject, delegation, decision, snapshot, catalog, adapter) the specification touches.
3. Propose the action using the vocabulary above (implements, consumes, checklist, tracking) and, for anything other than tracking, the phase from the roadmap in which it lands.
4. If the text is unfinished, propose the posture (build, name, track) and, for build, the revision to pin and the stable twin that carries the same information.
5. If the specification changes a wire format or a security default, say so; that row also needs a decision record and the updates listed in AGENTS.md.

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

Removed rows

None yet. When a row is removed it is listed here with the release, the reason (superseded, abandoned by its body, out of scope) and the row that replaces it if any.

A removed row's standards page, if one existed, is kept and marked superseded rather than deleted, following the same append-only rule as decision records.

Sources

• OpenID Foundation specifications index and the modification-ordered listing for OpenID dates and maturity.
• IPSIE Working Group specifications, the SL1 OpenID Connect Profile, the AL1 SCIM Profile and IPSIE Common Requirements.
• FAPI 2.0 Security Profile.
• RFC 9068, RFC 7643, RFC 7644, the IANA JWT claims registry and draft-gazitt-oauth-authzen-claims-00.
• Transaction Tokens, WIMSE architecture and RFC 9635 on the IETF datatracker.
• OpenAPI Specification milestones, Discussion #5304 for Security Profiles, Overlay 1.1.0, Arazzo 1.1.0 and the OpenAPI registries.
• SPIFFE, OCSF schema, CloudEvents and AG-UI.
• Other RFCs and drafts are referenced by number or name.

Related

• Standards: the pages for everything PermDock implements.
• Roadmap: the phases the last column refers to.
• Adapters: adapter phases.
• Threat model and delegation: where the checklist rows are applied.