Compliance Checklist

This page is a self-audit you can walk by hand. It is not the complete obligation set, and it is not the thing a conformance claim is made against.

What is authoritative

A conformance claim is made against a profile and a set of declared capabilities. Those live in the repository, not here:

What you need	Where it actually lives
Which conformance categories exist	`conformance/v1/manifest.json`
Which of them a conforming sender or receiver MUST satisfy	`specs/ink-conformance-profile.md`
The per-requirement implementation matrix	`specs/ink-compliance-checklist.md`
The normative specs in full	`specs/`

If anything on this page disagrees with those, they win. Where an item below needs a number, a window or a byte cap, this page links to the spec that carries it rather than restating it, because a restated number is a second source that goes stale quietly.

What this page covers

The sections below cover the core wire surface: identity and keys, transport authentication, the intent envelope, encryption of confidential payloads, connections and the optional receipt and audit exchanges. That was the whole protocol once. It is now a subset, and the next section says what the subset leaves out.

Identity and keys

MUST Publish an Agent Card with a top-level publicKeyMultibase (the base signing key, a multibase string starting with z).
MAY Publish keys.signing (Ed25519) and keys.encryption (X25519) key sets for rotation. The keys object is optional. Each entry carries keyId, algorithm, publicKeyMultibase, status (active / retired / revoked) and validity timestamps.
MUST Serve the Agent Card at the versioned discovery path, GET <base>/ink/v1/<agentId>/agent.json. That path is the discovery surface. /.well-known/ink/agent.json MAY be served as an alias for the same document, and nothing may depend on it, reach for it first or fall back to it. See Discovery and ink-agent-card-discovery-fetch.md.
MUST Ensure Agent Card endpoint, inboxEndpoint and each capabilities.thirdPartyAudit.services[].endpoint pass the isInkEndpointUrl grammar; reject an inboxEndpoint that differs from endpoint when both are present. The grammar is in Agent Card.
MUST Apply the key-rotation authority rule: active and retired keys verify within their validity windows; revoked keys never verify, including for historical artifacts.
MUST Document the PDS trust level the implementation operates at.

Transport authentication

MUST Verify Ed25519 signatures on every inbound INK message using the sender’s signing key. The signature base binds a fixed ink/0.1 first-line domain separator, HTTP method, request path, recipient DID, JCS-canonical body and timestamp. The first line is the literal ink/0.1 for every request regardless of the envelope protocol. See Authentication.
MUST Parse the Authorization header under the exact grammar, rejecting stray whitespace, an embedded CR or LF, trailing data and unknown parameters.
MUST Enforce replay protection on every inbound message: reject a stale or future-dated timestamp and reject a duplicate nonce, recording the nonce only after every other check has passed. The freshness window is normative and lives in Replay Protection; take it from there, not from an example.
MUST Canonicalize signed bodies under RFC 8785 with the safe-integer number profile. See Canonicalization.
MUST Apply all four raw-text rules to a signed body before parsing, rejecting on the first failure: raw bytes that are not valid UTF-8, a lone UTF-16 surrogate escape, a number literal outside the IEEE-754 double range, and an object member name written with an escape sequence. Pinned by the signed-body-utf8, jcs-string-safety and signed-body-member-name conformance categories. See Canonicalization.
MUST Return structured error responses for all failure cases, using the codes verbatim. See Error Codes.
MUST Include a valid protocol in every outbound message. ink/0.2 is scoped to the intent envelope and its body-signature domain negotiation, sent only to a receiver that advertises it. The Agent Card, handshake, receipt, audit-query-response and encrypted outer envelope stay ink/0.1; their frozen schemas reject ink/0.2. See Versioning.

Intents and resolutions

MUST Accept a POST with a valid INK message envelope at the inbound endpoint published on the Agent Card. INK reserves no inbound path: the path you serve is byte-for-byte the path component of the published endpoint, because PATH sits inside the frozen signature base. See Authentication.
MUST Implement HITL escalation for any intent where autonomyPolicy.maxAutonomyLevel is not full. See Autonomy.
MUST Store resolutions as local application data with export support.

Encryption

Capability-gated. Required when the implementation sends or accepts encrypted payloads, which includes every implementation that handles a confidential intent.

MUST Encrypt the payloads of the intents the protocol marks confidential, using the InkEncryptedEnvelope wire format, and reject those intents in plaintext. The list of confidential intents is in Encryption. Rejecting them in plaintext is mandatory even for an implementation that never decrypts.
MUST Order the receive path as verify signature, then decrypt, then check the inner identity claims against the outer envelope. See Encryption.
MUST Enforce the same binding at seal time. A conformant sealer refuses to encrypt a plaintext whose from is not the outer envelope sender, or whose to is absent, empty or different from the recipient identity the caller asserted, so it cannot mint an envelope a conformant peer would refuse to open. encryptInkPayload and its Go counterpart EncryptInkPayload both enforce this.

Visibility and connections

MUST Support network.tulpa.connection mutual record verification for connections-level visibility, validating the connection payload against its strict schema and rejecting an unknown key.

Receipts (optional)

MAY Accept POST /ink/v1/receipt for delivery receipts and advertise receipt capabilities in the Agent Card. See Receipts.

Audit (optional)

MAY Accept POST /ink/v1/audit for audit exchange and maintain a hash-chained audit log. See Audit.
MUST (if audit is supported) Run both the response-signature gate and a chain-continuity gate on every audit response: strictly +1 sequence within a slice, previousEventHash linkage and duplicate-sequence fork detection. The library exposes these as verifyAuditResponseSignature and verifyAuditEventChain.

What this page does not cover

Each of the following is a live obligation with its own conformance category. None of them is optional by omission from the list above, and this page is not the place to audit them. Read the profile document for which of them bind you, and the spec for what each requires.

Surface	Where it is specified
Agent Card signatures, the unsigned-card ratchet and the continuity and rollback rules. Producer signing is in force; the receiver-side rejection of unsigned cards is staged behind an explicit default-off flag.	`ink-agent-card-signature.md`
The resolver: input classification, base derivation, URL construction, the request-side rules and the post-fetch verification order. This is where SSRF, identity confusion and key substitution all live.	`ink-resolver.md`
The discovery fetch response contract: status, content type, size caps, identity binding and owner anti-substitution, with redirects refused outright.	`ink-agent-card-discovery-fetch.md`
Outbound host safety, failing closed on loopback, private, link-local, IANA special-use and malformed IP-shaped hosts, at the literal and at connect time.	`ink-private-hostname.md`
The end-to-end first-contact transcript, meaning the accept rules across a full first exchange rather than one message at a time.	`ink-first-contact-transcript.md`
Scoped, audience-bound, expiring authorization grants and the sign-in challenge.	Agent Authorization
Multi-hop delegation chains: parent-hash and issuer-subject continuity, monotonic attenuation and per-position lifetime ceilings.	Authorization Chains
Signed discovery query envelopes, for an implementation that answers directory queries.	`ink-discovery-query.md`
The containment and governance handshake messages.	Containment
Witness-side inclusion and consistency proofs and the checkpoint grammar.	Witness

Making a claim

Meeting every MUST above does not make an implementation conformant, because the list above is a subset. A claim someone can check names the roles you perform, the capabilities you advertise and the corpus you ran:

We implement the base receiver profile plus the encryption capability, and we pass every vector in those categories in conformance/v1.

Do not advertise a capability you have not fully implemented, and do not phrase a conformance claim as a library version. The corpus proves two implementations agree on fixed bytes; only a live exchange proves they agree when each side produces its own, which is what interop-lab/ does between the TypeScript and Go implementations on every push.

Supporting ink/0.2 is an optional capability on top of the base profile, not a separate compliance tier. An implementation that opts in MUST select the body-signature domain from the signed protocol field (ink/sign\n for ink/0.2, tulpa/sign\n for ink/0.1) and SHOULD advertise the versions it verifies in its Agent Card supportedProtocolVersions array. A receiver that does neither remains a conformant ink/0.1-only implementation. Rejecting an unknown protocol value is a baseline schema requirement either way.

If you are handing the work to a coding agent, Have a Coding Agent Implement INK collects the same sources with a prompt and a traceability matrix.