History

Changes from the recovered proposal

The first draft imported A1-A17, terminology and both appendices from the recovered proposal. Recovered originals remain unchanged in the source inventory. The import was reproducible, rejected an unexpected source hash and applied only the corrections listed here, plus Markdown formatting and explicit implementation-status notes.

• The reference implementation introduced an explicitly bounded operational HTTP surface in operations.md, operational errors in errors.json and generated health, readiness and problem schemas. These are not a replacement for the proposal's A8 recipient error registry.
• The reference implementation's server takes its key from a local key file of exactly 32 bytes, readable only by its own user, or, in tests only, from a key held in one process's memory. It reports ready only when that key provider and its database both work and its signing keys exist, and it refuses to start in production; accepting a local key file in production will require an explicit acknowledgement of local key custody. This is stricter than an always-ready development placeholder; it avoids suggesting that a process can protect real records before its keys are under deliberate custody.
• migrate applies the reference implementation's database migrations as a dedicated role and creates its job queues, and serve and work refuse a database role with any attribute beyond login, a membership of any role, the right to create in the database or any schema or to make temporary tables, ownership of any object, a grant outside the service's own schemas, a parameter privilege or settings of its own; the grants inside the service's own schemas are the ones its migrations make, and are not read at start. work runs the job runner, whose job payloads carry identifiers only; no job is defined yet. ctl offers help, the creation of a new key file, the listing and rotation of the provider's signing keys, and the verification of a partition's owner log, which reads its events and the signing keys, decrypts no record, and records an operator_action in each log it read. None of these gives an operator any access to records.
• Where the reference implementation is hosted does not change the recipient wire protocol.

Scope grammar implementation clarifications

The scope grammar implementation covers A6.3 parsing independently of the remaining entry schemas. Duplicate reads with the same declaration mode collapse to their highest level as required by the backlog. Mixed declaration modes for one domain are rejected until their semantics are resolved. Bounds, exact space separators, case handling, duplicate-purpose rejection and safe validation errors are documented and checked as SCOPE-01 to SCOPE-09. The generated token schema is explicitly insufficient for whole-grant validation. No recipient endpoint, OAuth mapping or complete SDK is added.

Normative import corrections

The identifier subset adds the prefixes required by the service design and explicitly requires canonical upper-case ULID bodies with valid 128-bit bounds. It does not change public/pairwise handles or invent the remaining entry shapes. Generation requires a positive explicit timestamp because the pinned library treats zero as ambient time. These clarifications have ID-01 to ID-05 checks, including a separately bundled browser run.

The current MCP transport standard requires Mcp-Name for tools/call, resources/read and prompts/get; it is not a blanket requirement on every method. This clarifies the shorthand in the service design. Exact source links and verification are in the dependency record. Existing illustrative JSON examples remain draft illustrations; their full generated equivalents arrive with the corresponding implementation.

All imported requirements are pending the executable checks described in conformance status. Unresolved source ambiguities are listed separately; this import does not decide them silently. No internal hostname appears in these public contracts.

21 September 2026: consent, temporary context and reciprocity

A scope review added an addendum on consent, temporary context and reciprocity. Its text is now in A6.7 and the other sections listed under the edition 1.0-draft-1 restructure below. Grants and temporal attributes already existed; the additions clarify purpose separation, temporary override precedence and reciprocal contribution. The historical source files remain unchanged. The reproducible import adds advertising to A6.3 and links the overriding addendum from A4, A6, A11 and A17.

The scope schema, manifest, token schema and examples now include the explicit advertising purpose; SCOPE-10 checks that it grants no implicit read, proposal or persistence capability and cannot combine purposes. No authorisation server, recipient integration, temporal compiler or portability endpoint is introduced. Read/Contribute are capability descriptions mapped to existing Core/Write requirements, not renamed protocol identifiers or issued certifications. No breaking URL or wire-version change is made.

Full draft publication, 21 September 2026

Document 0.2-draft resolves S1 to S4 and every item in the source ambiguity register. Historical corrections above describe earlier stages; the current numbered chapters supersede conflicting original examples. The original source hash remains checked; versioned editorial Markdown sources generate the revised chapters reproducibly.

The draft now includes typed contracts, a 27-key closed vocabulary, recipient OpenAPI/MCP definitions, examples and stable conformance requirements. Recipient IDs, temporary-context state, grants and export shapes change within an unreleased wire draft under ADR 0002. No existing recipient runtime is migrated. Unknown candidate keys and reserved extensions are explicitly excluded rather than published as incomplete wire formats.

Public documentation cleanup

The public standard presents protocol requirements, design principles, interpretation notes and versioning guidance. No wire format, consent rule, vocabulary key or conformance requirement changes.

International privacy deployment requirements

A16.1 retains the informative legal mapping. A16.2 to A16.8 require deployment-specific evidence for legal applicability, sensitive-data limits, international flows, rights and retention, opt-outs and child safeguards, and accountable operation, including granted regulatory permits and their continuing validity. PRIVACY-01 to PRIVACY-06 apply to every claimed provider or recipient capability. Unsupported operations remain disabled; passing protocol checks is not legal certification. A10 permits shorter lawful or necessary purge-status retention independently of an owner request, and A18 explicitly applies the local advertising checks. No wire format or vocabulary changes. Operational implementation and evidence remain pending.

Pure compiler clarifications, 24 September 2026

The first compiler makes A4.5's field-right checks reproducible with a bounded value / value.<member> dependency notation; unsupported paths are withheld. A5.2 defines confidence filtering for exact declarations and null confidence, and permits conservative inclusion after selection-group changes while requiring baseline/dependency restoration. Request output filters do not grant input rights. These clarify the unreleased draft without changing wire object shapes, vocabulary keys or capability claims. The compiler's internal snapshot and owner-only receipt references are not new recipient contracts. Fractional UTC boundaries are compared without truncating to milliseconds.

Approved pilot vocabulary 1.1, 24 September 2026

Adds agent.always_do, agent.explanation_depth and communication.spelling with the reviewed definitions in Appendix A. Every key records its introduction version. The 27 original keys retain their semantics; the catalogue now has 30 keys in 17 domains. Compiler disclosure of new keys requires both stored grant approval and recipient support for vocabulary 1.1, defaulting missing evidence to 1.0. No wire envelope shape or protocol version changes. VOCAB-1.1-01 to VOCAB-1.1-09 and the full compiler properties cover the addition; runtime negotiation and consent persistence remain pending.

Edition 1.0-draft-1 restructure, 4 October 2026

Edition 1.0-draft-1 restructures the 0.2-draft text without changing a requirement. The core chapters move to core/, A12, A13 and continuous connectors to core/reserved/, the MCP and REST transport detail of A7 and A8 to the bindings B3 and B4, and the vocabulary to vocabulary/. A18 is folded section by section: A18.1 becomes A6.7, A18.2 becomes A4.6, A18.3 becomes A14.5 and A18.4 becomes A17.5; the unnumbered change-process page becomes A17.4. Every section's new location is in section-map.json. The operational HTTP surface and the app shell describe the reference implementation rather than the standard and move to its design documentation. The core text is now maintained by hand; the recovered proposal stays hash-locked and the editorial import pipeline is retired. The document version, held once in packages/schema, becomes 1.0-draft-1 in the schema identifiers embedded in the OpenAPI document and the MCP tool definitions, the OpenAPI version, the conformance manifest, and the capability-claim and discovery schemas; the wire version stays 1.0. Capability claims and discovery documents stating 0.2-draft no longer validate; no implementation had published one. The operational health and readiness schemas and the operational error examples stay generated into spec/ as informative artefacts of the reference server, governed by its design documentation. The conformance manifest gains a pending_phase for every check and lists the SCOPE, ID and VOCAB-1.1 families it previously cited only in text. The vocabulary document gains the documentation group media (viewing, reading, music), which adds no key or permission.

Reserved chapters as placeholders, 4 October 2026

The version 1 rules A12 and A13 stated move into the normative core, with their check ids unchanged: registries and trust evidence to A2.1, client standing and safety or medical purposes to A6.8, and self-declaration and experimental emergency cards to A17.6. core/reserved/ now holds informative placeholders for A12, A13 and continuous connectors, which carry no requirements. No requirement changes. handle_moved stays removed (B4.3).

PDPP binding body, 4 October 2026

The body of B1 binds read grants to PDPP Core v0.1.0 at commit 8f79a48. Disclosure levels become statically declared derived streams, one per domain and level, with a .declared variant; restrictions PDPP cannot express travel in a second RFC 9396 detail; contribution grants and PDPP owner tokens are outside the binding; and the deviations from a strict reading of PDPP Core are listed as B1-D1 to B1-D8. No requirement of the core changes and no generated contract changes. The binding's new wire values (the detail type, purpose codes, stream names and record shape, identifier derivations, the autonym_lifecycle token kind, Autonym-Read-Id and a pdpp receipt surface) are draft text until they are generated from the schema package. The reasons for adopting PDPP Core, and what is taken from it, are in its adoption record.

Review amendments, 5 October 2026

The grant model belongs to the core: A1.3 and A6 now say that Open Personal Context Core stays meaningful without PDPP, and that B1 is the normative 1.0 grant binding, not a dependency of the model; the PDPP and OAuth adoption records say the same. A9 adds the key lifecycle that keeps receipts verifiable after a key rotation: key IDs are never reused, retired keys sign nothing new and stay published with their retirement date, and retention and compaction keep everything an old receipt needs. A5.4 verifiers reject a signature made after the key's retirement. Two checks join the Core provider profile, KEY-01 and LOG-02, both pending runtime evidence; the retirement-date member is defined when the key-publication contract is generated. A10 states that an acknowledgement proves only the recipient's signed attestation of the outcome it reports, never that every copy has gone. No wire format changes.

Error registry for 1.0, 5 October 2026

The error registry now covers the whole 1.0 specification and replaces the proposal's A8 error list. Each registered code carries its urn:autonym:error:<code> type, status, title and the sections whose text raises it, and each of those sections names the code: A5.2 the grant, domain and disclosure-failure codes; A6 the capability, sender-proof, advertising and client-standing codes; A8 and A14 the proposal, value, idempotency and contribution codes; and A15.3 and B4 the operational codes. client_suspended (403) is added for the A6.8 rule that a suspended or disabled client cannot read. A14.3 now states the refusal that the A4.2 prohibitions on observing and inferring sensitive keys require: for a special-category or safety-critical key only a user_supplied event is accepted, as a protected proposal, and any other event fails safety_write_forbidden or inference_forbidden. level_exceeded is removed because no section raises it: A5.2 caps a requested level at the grant's ceiling instead of refusing the request. A later version that refuses such a request registers a code with the text that raises it. The registry also lists, without registering them, the OAuth codes and the PDPP Core section 8 codes that the text cites, including blob_not_found on the PDPP endpoints (B1.7, B1.9). B3.4 maps every registered code to one MCP error form. The status and title of every remaining code are unchanged.

PDPP conformance table, 5 October 2026

B1.10 now states, item by item, how the binding meets each Authorization Server and Resource Server requirement of PDPP Core section 9 at commit 8f79a48, so the published binding stands on its own. It previously relied on a table in a design document, and B1 no longer links to that document. No requirement changes.

Signed-object contract, 6 October 2026

A5.4 now settles the bytes every detached signature covers and how they are verified. Receipts, purge acknowledgements and exports use the same method as disclosures, and each signed object names its signed time. A key ID is the RFC 7638 SHA-256 thumbprint of its public key, so one key ID cannot name two keys. The provider's key set at the discovery jwks_uri follows the new key-set.json: ES256 P-256 signing keys only, no private members. A retired key carries the JWK parameter exp that OpenID Federation 1.0 registers, in whole seconds, and a verifier rejects any object signed at or after it; a key carrying another lifetime member is not used. This makes the A9 key lifecycle, previously pending a published retirement member, a complete contract. Verification parses the received text strictly before canonicalisation, refusing repeated member names and non-I-JSON (lone surrogates, noncharacters and numbers with more magnitude or precision than a binary64 value provides), and refuses any protected header member other than alg, kid and typ. Every instant a provider writes into a signed or hashed object has one canonical spelling, without trailing fractional zeros and without losing precision.

A receipt now names its provider, the issuer URL discovery publishes, inside the signed bytes, and a verifier rejects one whose provider is not the trusted issuer. A9 defines the receipt's canonical request: the validated context request with max_level, declared_only and min_confidence always written out, its lists sorted without repeats and since in the canonical spelling; the receipt's request member now requires those defaults. A10 says the acknowledgement signature covers the RFC 8785 canonical JSON of the acknowledgement without proof, by the A5.4 method, and that the purge token's kid and iat follow A5.4. A verifier also recomputes a receipt's hash, refuses a disclosure issued more than 60 seconds ahead of its own clock, and accepts key coordinates and key IDs only in canonical base64url; a provider's signing key appears in no other provider's key set, and a published exp never changes. A receipt carried in an export is checked against the export's verified origin_host, and a verifier refuses an object that its schema would rewrite rather than return a value that was not signed. These are wire changes before the 1.0 wire release: receipts gain a required provider, and proof.kid, exported public keys and receipt requests are stricter, and the media example is re-signed under thumbprint key IDs.

Normative statement audit, 6 October 2026

Every sentence of the normative pages that carries MUST, MUST NOT, SHOULD or SHOULD NOT, every requirement they state in the imperative, and every sentence that uses a lower-case must or should, now has an entry in statements.json naming the checks that test it or the reason no suite can. RFC 8174 gives the lower-case forms no normative force, but the text often uses them for requirements, so they are audited too; their wording is unchanged. The items of the A5.4 rejection list count as imperatives, and some requirements stated without a modal, such as the key, key-set and instant rules of A5.4, the canonical request of A9 and the acknowledgement bytes of A10, also have hand-chosen declarative entries; nothing requires one for every such sentence. Nine checks join the conformance manifest for requirements no check covered, all pending runtime evidence: WIRE-01 (A1.1 and A4.1, unknown members, keys and values outside a key's closed schema), HANDLE-01 (A3.2, public handles), MIGRATE-01 (A3.4 and B4.3, migration), INFER-01 (A4.2 and A14.3, keys that cannot be observed or inferred), OAUTH-01 (A6.1 and A6.3, metadata, registration and the code flow), FETCH-01 (A15.3, A3.3 and A6.1, retrieval of supplied URLs), ENCRYPT-01 (A11.2, the optional encrypted export), BINDING-01 (the requirements of B1 itself) and WILDCARD-01 (the A15.1 recommendation). The Core provider profile gains WIRE-01, OAUTH-01, FETCH-01 and INFER-01, and Portable gains MIGRATE-01. The Read and Contribute recipient profiles gain WIRE-01 and FETCH-01, because both are shared security requirements. HANDLE-01, ENCRYPT-01 and BINDING-01 are the checks of three new optional features, public-handles, encrypted-export and pdpp-binding, which A17.1 now names beside advertising; WILDCARD-01, a recommendation, belongs to no profile. A5 now also cites TEMP-02 and LOG-02, A6 the SCOPE checks of its scope grammar and DISC-01, A4 and B4 WIRE-01, A10 KEY-01, and A11 KEY-01 and LOG-02. The PDPP, OAuth and JWE adoption records name the new checks that apply to them.

The audit tightened four passages of A4 without changing behaviour:

• A4.3 says that instants compare by the time they denote, at full fractional precision, not by their bytes.
• A4.4 says that overlays apply only to the baseline that is eligible and selected for its key, and that selection counts only that baseline's eligible enabled overlays, so a selection on an ineligible or disabled overlay neither wins nor counts against another. It also says that the overlay is chosen from the record before the grant and request apply, so a winning overlay that they withhold is omitted and the baseline it replaces is never disclosed in its place.
• A4.5 says how its limit of 256 dependency references is counted: every reference traversed from the disclosed entry, along every path and without de-duplication, so an input reached by several paths, or named more than once, counts each time it is reached, together with its own references. The text previously said "more than 256 total dependencies" and did not say how a shared input counts. This is the stricter reading: an implementation that counted distinct inputs would accept graphs this rule withholds, never the reverse.
• A4.6 no longer reads as contradicting A4.4 when a single eligible enabled overlay has no selection: that overlay applies. Among several eligible enabled overlays, the baseline is used until exactly one of them is selected.

The reference compiler already behaves this way, and its TEMP-01 to TEMP-03 tests pin each reading. No wire format, vocabulary key or error code changes.

Published test vectors, 6 October 2026

conformance/vectors/ publishes informative test vectors for the A5.4 signed objects: synthetic provider and recipient keys with their private parts, one provider key retired with exp; RFC 8785 canonical JSON with its UTF-8 bytes and SHA-256; signed disclosures; a receipt chain across a key rotation with its canonical requests; a purge instruction token and acknowledgement; and the signed objects a verifier must reject. The provider key set in keys.json is also the example of key-set.json. The media worked example is re-signed with the vector keys and no longer carries keys of its own. The conformance manifest gains an optional vectors member listing the vector files that evidence a check. No requirement changes.

Contract checks in A17.2, 6 October 2026

A17.2's description of the reference repository's contract checks now also names the compiler's example and property tests, the library verifier for A5.4 detached signatures, the published test vectors, checked by the repository's tests with that verifier and independently by a second verifier written from the specification text alone, and the statement audit. The sentence that follows says "These checks" instead of "They". No requirement changes: the A17.2 sentences that use a modal or the imperative are unchanged, and runtime checks remain pending.

Integration evidence in the conformance manifest, 7 October 2026

A check's runtime_evidence may now be integration as well as library or pending: the reference implementation's integration tests, which run its provider against real storage, cover every duty the check's requirement places on a provider that one provider's own tests can show, while a verifier's part keeps the evidence of its own tests and vectors. A17.2 and the conformance README say what it shows and what it does not: that the reference provider meets those duties, not that another implementation does. The README also says that neither library nor integration evidence is gathered from a running service, what pending_phase names for a check with integration evidence (the phase whose tests supplied it), and which parts of KEY-01 its integration evidence leaves to a verifier's tests, to a running service or to other providers; it covers a provider whose issuer changes, whose earlier retired keys stay published. KEY-01 records it, from the tests of the reference key store against a real database, and the README defines the -STORE test-name suffix for such tests. The README also says what one provider's tests cannot show of a key never being shared between providers. PAIR-01 stays pending: its last requirement, that no canonical identifier escapes, needs a running read path, so tests of a store alone cannot cover it. No requirement, schema or wire format changes.

Medical alert example, 6 October 2026

In the vocabulary, the L1 and L2 example renderings of health.medical_alert repeated the agent.never_do example text. Each free-text key's L1 and L2 example is now its own example, so the medical alert shows its synthetic example at L1, L2 and L3. No key, value schema, supported level, renderer operation, flag, label or explanation changes, and a compiler never uses an example.

Entry limit per partition, 7 October 2026

A4.1 now bounds a partition at 10,000 entries that have not been deleted, which bounds what one read compiles: the reference compiler takes at most 10,000 entries in one read, and without a bound a partition past it could no longer be read at all. A write that would add another entry fails with the new registered code entry_limit_reached (409, "Entry limit reached") and changes nothing; a new version of an existing entry, and a deletion, are not refused by it. The proposal set no such limit. No other code's status or title changes, and no schema changes beyond the registry, the Problem Details union and their generated examples.

No agent operation adds an entry in this version: a contribution is acknowledged as a proposal whatever the partition holds, and only the person's own operations, such as accepting a proposal in the first-party app or an import, meet the limit. B3.4 therefore lists entry_limit_reached in a row of its own, of codes no agent operation raises, rather than with the refusals of an agent's request, so a contributor never learns how many entries a partition holds. A11.1 adds each partition's entry limit to what an importer validates before changing the destination, and PORT-01's requirement now includes it.

Tombstone versions, 8 October 2026

A4.1 now fixes a tombstone's version: one more than the last version of the entry it deletes, so no ID and version name both an entry version and a tombstone, and two exports either side of a deletion never give one (id, version) two meanings, which A11.1's rejection of differing duplicates relies on. An earlier version keeps the status it was written with: a new version never changes an earlier one. The proposal left a tombstone's version unstated.

Handle authority, 8 October 2026

A3.2 now says that an IP address is never a handle's authority, and neither is a name whose last label is all digits or 0x followed by hexadecimal digits, since URL parsers read such a name as an IPv4 address. The proposal allowed the DNS name of the host, which names such as example.1 and foo.0xab can be. A3.2 also says that the handle pattern in the published schemas checks only the syntax of the authority's labels, so it accepts such names. No schema or example changes: tightening the published pattern would change a wire format, and is not made here.

Authorisation contract, 14 October 2026

Every access token is now bound to its client's DPoP key, for every client class and every resource. The proposal and D19 let an assistant, an unverified one included, use Bearer tokens, and A6.3 required DPoP only for service and connector clients; A2, A6.3, A15.1 and B4.1 now say that no class uses Bearer tokens, and the OpenAPI document no longer has its EligibleAssistantBearer security scheme. A token request without a valid proof fails RFC 9449 invalid_dpop_proof, a proof is accepted only once and within 60 seconds of its iat, and a resource keeps dpop_required and dpop_invalid. The MCP record says how this departs from the Bearer usage MCP specifies.

A2 assigns every class from registration evidence: a client on the operator's assistant allowlist is assistant, any other public client assistant_unverified and a confidential client that authenticates with a registered key service. Previously only a public MCP client was assistant_unverified, and every other unknown client was service. A6.1 replaces the root protected-resource metadata document with one path-specific document for each resource, because the root document's resource would be the origin, which is not an audience, and says which registration metadata a provider accepts (client-metadata.json, client-metadata-document.json): inline ES256 keys, and no jwks_uri, sector_identifier_uri, software statement, client secret or member the schema does not list. A6.2 gives each capability scope its meaning, gives every grant one audience, defines a continuous grant and defines the contribution request, an RFC 9396 detail of type urn:autonym:authorization-details:contribute (contribution-detail.json). A6.3 names the access token's claims (access-token-claims.json), signed with ES256 only, ends a grant whose authorisation code or refresh token is used a second time, and lists the OAuth error codes its endpoints answer; the A6.6 lifecycle token's claims are in lifecycle-token-claims.json. A6.5 says that an access token ends with its grant and is not revoked on its own. A6.8 widens suspension from reads to every recipient action except the purge routes, and to the delegations of a suspended client; a deregistration revokes the client's grants. A9 defines the content of grant_created, grant_revoked, grant_expired, read_not_modified and operator_action, including how an operator_action says what it concerned, which A9 previously left to supplementary contracts that did not exist. The scope grammar publishes the purpose codes urn:autonym:purpose:<category> and the capability meanings, which scopes.json now carries too.

The error registry registers five codes for the person's own first-party requests (A15.3): session_required (401, "Sign-in is required"), csrf_invalid (403, "Request could not be verified"), reauthentication_required (403, "Recent sign-in is required"), signup_unavailable (403, "Sign-up is not available") and sign_in_failed (400, "Sign-in failed"); B3.4 lists them with the codes no agent operation raises. The registry also lists the OAuth codes A6 now cites, and rate_limited names A6.1, whose registration endpoint answers it in RFC 7591's error form. A2 gives each class's grant kinds, capability scopes and longest grant in a table, and leaves autonym:persist and autonym:delegate for an assistant or service client to the provider's policy. A client is assistant by its redirect URIs only when the allowlist names every one of them, and a client that registers or publishes a loopback redirect URI is never assistant, by either path; every client that is not assistant and not classified by the operator is shown as unverified at consent, whatever its class. A6.1 states the rules between registration members, accepts the A6.4 token exchange and grant offer in grant_types, the grant offer only from a client that authenticates with private_key_jwt, and refuses application_type, a Client Identifier URL with a percent-encoded dot segment or a host that URL parsers read as an IPv4 address, a port outside 1 to 65535, and in display text control, bidirectional, default-ignorable and interlinear annotation characters and any character outside the Basic Multilingual Plane. A6.2 makes a contribution detail's allow_confirmation true exactly when autonym:confirm is requested. A6.3 applies the loopback-port exception only to a client whose redirect URIs are all loopback URIs, requires a resource's DPoP proof to be signed by the token's cnf.jkt key, and answers invalid_token only for a token that fails verification. A6.4 binds the token exchange's proof to the subject token's key and names only a confidential recipient, which redeems the offer with private_key_jwt. A6.5 ends the grant whose refresh token its client revokes, with a DPoP proof by the token's key from a public client, and A9 records that revocation with the client as actor. A6.6's lifecycle token carries sub, the client's ID, as RFC 9068 section 2.2 requires of every JWT access token, and its scope. A9 splits an action on a client with more than 32 grants in one partition over several operator_action events. The scope marker of scopes.json becomes grammar-and-meanings, because the file now carries the meanings issuance applies. The requirements of OAUTH-01, LOG-01, CONSENT-01 and DELEGATE-01 in the conformance manifest now name the A2, A6.4, A6.5, A6.6, A6.8 and A9 rules their statements cite, and no check is loosened. B1-D4 and the PDPP record say that no client uses Bearer tokens, and a reused refresh token in B1.10 revokes the grant; the rest of B1's DPoP wording follows with the PDPP binding's own change, and where it differs, A6 wins. The example client key is no longer the published recipient test key, whose private part anyone can read.

These are wire changes before the 1.0 wire release, inside the unreleased wire draft that ADR 0002 allows to change: the OpenAPI security schemes, the error registry, the Problem Details union and scopes.json change, and five schemas are added, with examples in authorisation.json. The test vectors do not change.

References to other standards and projects describe intended technical alignment only and do not imply endorsement or partnership.