A1. Scope, status and layering
Status: normative. Document version 1.0-draft-1.
Autonym specifies a person-controlled context record, explicit recipient grants, progressive disclosure, accountable reads and portable records. It is provider-independent: a compatible recipient implements this protocol rather than an integration unique to one host.
This is document 1.0-draft-1, specifying proposed wire version 1.0. It is a complete publication of the current draft scope, open to interoperability review. It is not a ratified standard, a released server, a certification or a promise that an integration exists. The implementation and conformance status distinguishes executable contract checks from missing service behaviour.
RFC 2119 and RFC 8174 capitalised MUST, MUST NOT, SHOULD and MAY identify requirements. Requirements apply to the capabilities an implementation claims, with the shared security requirements applying to every capability. Every normative section maps to the stable checks in the conformance manifest. Pending runtime checks mean unverified implementation, not permission to ignore a requirement.
A1.1 Normative material
The normative publication consists of the core chapters A1 to A11 and A14 to A17 in core/, the normative bindings in bindings/, the core vocabulary, JSON Schemas, OpenAPI, MCP tool definitions and conformance requirements. A12, A13 and continuous connectors are informative placeholders in core/reserved/ for capabilities reserved for 2.0; they carry no requirements, and the version 1 rules A12 and A13 used to state now live in A2.1, A6.8 and A17.6. The consent, temporary-context and reciprocity requirements first published as A18 are folded into A4, A6, A14 and A17. Prose defines cross-object and stateful invariants which JSON Schema cannot express. An implementation MUST satisfy both. Synthetic examples are informative; their illustrative signature bytes are not cryptographic test vectors.
Unknown fields at a defined wire boundary MUST be rejected. Keys absent from the released core vocabulary MUST be rejected unless a separately versioned future extension is negotiated; there is no permissive arbitrary-JSON entry lane.
A1.2 Layers and release boundary
- The record model and vocabulary describe what is stored and the approved renderings.
- The compiler intersects the current stored grant, request, vocabulary and temporal selection.
- OAuth, DPoP and discovery establish recipient authority and protected-resource audiences.
- REST and MCP carry the same objects and use the same counted read transaction.
- Receipts, revocation, purge and portability describe the lifecycle after disclosure.
Vocabulary 1.1 contains 30 keys across all 17 proposed domains, retaining the original 27 keys from vocabulary 1.0. This intentionally bounds the first interoperable release. Keys outside this vocabulary require a later specification. Version 1 defines Core, Write, Portable and Delegated provider capabilities and Read, Contribute and Reciprocal recipient capabilities.
Credential presentations, recipient registries, guardian/duress operation and emergency cards are reserved extensions outside v1 conformance. Their chapters state the boundary and safety requirements for future work. Implementations MUST NOT advertise those reserved capabilities as conforming v1 features. Person-facing management UI and private management API routing are implementation choices; portable entries and owner-visible rights remain normative. The public recipient API is fully described in A8 and B4.
A1.3 Existing standards
Autonym uses OAuth metadata and token formats, PKCE, DPoP, JSON Schema, JSON Web Signatures, JSON Canonicalization Scheme, Problem Details and MCP. It does not invent replacement cryptography or claim clinical, legal or identity certification from use of those standards. Links to primary specifications appear with the relevant contracts.
The grant model is defined here and in A6, independently of any one authorisation protocol. Open Personal Context Core stays meaningful without PDPP: B1 is the normative 1.0 grant binding, not a dependency of the model. A provider that does not offer B1 still implements every core requirement, and a change to PDPP changes B1, not the core.
Checks: all applicable conformance requirements, particularly CLAIM-01 and WIRE-01.
References to other standards and projects describe intended technical alignment only and do not imply endorsement or partnership.