Compliance Checklist

Use this as a self-audit before claiming INK v0.1 compliance. Items are grouped by domain. Each item is marked MUST (required for interop), SHOULD (strongly recommended), or MAY (optional extension).

Authority rule

Once an agent publishes a keys.signing set in its Agent Card, that set is canonical. Bootstrap key derivation MUST NOT be used as a fallback. Revoked keys MUST NOT verify any signature, including artifacts whose timestamp predates revokedAt. See Key Rotation.

Identity and keys

• MUST Publish an Agent Card with keys.signing (Ed25519) and keys.encryption (X25519) key sets. Each entry carries keyId, algorithm, publicKey, status (active / retired / revoked), and validity timestamps.
• MUST Publish a discoverable agent endpoint (e.g. a service entry in the DID document) so counterparties can fetch the Agent Card.
• MUST Ensure Agent Card endpoint, inboxEndpoint, and each capabilities.thirdPartyAudit.services[].endpoint pass the isInkEndpointUrl grammar (lowercase https:// only, host required, no userinfo, no fragment, at most 2048 UTF-8 bytes, no control characters or whitespace or backslash, well-formed percent escapes, optional port in 1..65535); reject inboxEndpoint that differs from endpoint when both are present.
• 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 keys.signing set. The signature base binds protocol version, HTTP method, request path, recipient DID, JCS-canonical body, and timestamp.
• MUST Enforce replay protection on every inbound message: reject timestamp more than 5 minutes old or 30 seconds in the future, and reject duplicate nonce values within that window. Reference implementations get this from verifyInkAuth when a NonceStore is supplied, or by calling checkReplay (or equivalent) in the request pipeline.
• MUST Return structured error responses for all failure cases. See Error Codes.
• MUST Include a valid protocol in all outbound messages: ink/0.1 by default, or ink/0.2 only when sending to a receiver that advertises it (see Discovery).

Intents and resolutions

• MUST Accept POST /ink/v1/intent with a valid INK message envelope.
• MUST Implement HITL escalation for any intent where autonomyPolicy.maxAutonomyLevel is not full.
• MUST Store resolutions as local application data with export support.

Encryption

• MUST Encrypt schedule_meeting, context_share, and multi_party_sync intent payloads using the InkEncryptedPayload wire format. Reject plaintext for these types.
• MUST Decrypt inbound InkEncryptedPayload envelopes: verify signature and replay protection before decryption, verify inner / outer from match after decryption.

Visibility and connections

• MUST Support network.tulpa.connection mutual record verification for connections-level visibility.

Receipts (optional)

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

Audit (optional)

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

Authorization chains (optional)

• MAY Support multi-hop authorization chains with delegation proof verification.

---

Self-audit summary

Domain	Items
Identity and keys	4 MUST
Transport authentication	4 MUST
Intents and resolutions	3 MUST
Encryption	2 MUST
Visibility and connections	1 MUST
Receipts	1 MAY
Audit	1 MAY + 1 conditional MUST
Authorization chains	1 MAY

Implementations that meet every MUST in the required domains are conformant with INK v0.1. MAY items are optional extensions; if a MAY domain is implemented, the conditional MUST items inside that domain become required.

Rejecting an unknown protocol value is a baseline schema requirement that applies to every implementation regardless of ink/0.2 support: the envelope schema accepts only ink/0.1 or ink/0.2.

The conformance target is the packaged conformance/v1 corpus, indexed by conformance/v1/manifest.json. It covers the categories principal-normalization, signature-base, jcs-number, jcs-string-safety, key-rotation, replay-freshness, timestamp-validity, merkle-inclusion, merkle-consistency, merkle-checkpoint, merkle-leaf, inclusion-receipt, audit-query-response, handshake-message, connection-payload, and agent-card. An implementation MUST make the same accept or reject decision as the reference on every vector in each category it claims. See Test Vectors.

Supporting ink/0.2 is an optional capability on top of v0.1 conformance, 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. See Discovery & Transport.