| Internet-Draft | Accountable Statements | October 2026 |
| Yanteri | Expires 30 April 2027 | [Page] |
AI agents increasingly act on information they cannot check: what a business can supply, what a person said, what rules a platform applies. This document describes a minimal way to make such statements accountable. Every statement is signed by its author, bound where possible to a domain the author controls, and sealed in a public append-only Merkle log whose tree heads are signed, timestamped and publicly monitored. The design proves who said what and when, and that the record was not rewritten. It deliberately does not attempt to prove that a statement is true.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 30 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Search results, marketing pages and machine-generated text give an AI agent no way to tell an accountable statement from an anonymous one. Reputation scores can be bought or gamed. Certification does not scale to every sector.¶
This document takes a narrower goal that can be verified mechanically:¶
Origin: a statement was signed by a specific key, and that key was bound to a specific domain or device.¶
Integrity: the statement has not changed since it was signed.¶
Non-repudiation over time: the statement was publicly recorded at a known time, and the record cannot be edited, removed or shown differently to different readers without detection.¶
Truth is left to the reader. An AI weighs accountable statements with its own sources, as a journalist weighs on-the-record quotes.¶
A deployed reference implementation is described in [HUMANCOLLAB-SPEC]; the design and its security analysis are described in [HUMANCOLLAB-PAPER].¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Statements are serialized as canonical JSON: object keys sorted recursively, no insignificant whitespace, and only strings, booleans, null, arrays, objects and safe integers. This is a subset of JSON Canonicalization Scheme [RFC8785] that avoids floating-point canonicalization.¶
An envelope is {payload, public_key, signature} where public_key is a raw Ed25519 key [RFC8032] and
signature covers the UTF-8 bytes of the canonical payload. Receivers MUST reject envelopes with unknown payload
fields, timestamps outside a short window (five minutes in the reference implementation) and payloads whose SHA-256
has been seen before.¶
An agent's first statement SHOULD be a responsibility statement in which it accepts responsibility for its actions; every later action is signed by the same key.¶
A key is bound to a domain by a DNS TXT record _humancollab.<domain> whose value names the key, for example
humancollab-business=<base64 public key> or humancollab-agent=<base64 public key>. An HTTPS file at
/.well-known/humancollab.txt MAY be accepted for a first binding. Replacing the key of an established binding MUST
require the DNS proof; the previous key MUST NOT be reusable for any domain afterwards, and every key MUST remain
visible in a public key history with the log index of the first statement it signed.¶
People sign with WebAuthn passkeys [WEBAUTHN]. The WebAuthn challenge is
base64url(SHA-256(canonical statement)), where the statement contains the content, its license and a single-use
nonce issued by the service. The service publishes the complete assertion (authenticator data, client data,
signature and public key) to whoever the statement is addressed to. Only a seal of it enters the log
(Section 4.2), so the log alone neither reveals content nor links two statements by the same person.¶
Passkeys raise the cost of automation; they are not proof of a unique human, and services SHOULD say so.¶
A leaf for a signed statement is the canonical JSON object¶
{"canonical": <canonical payload>, "kind": <payload type>,
"public_key": <base64>, "signature": <base64>,
"statement_seq": <integer>}
¶
Anyone can re-verify the signature from the leaf alone.¶
{"commitment": hex(SHA-256(canonical assertion package)), "kind": <type>}.¶
{"document": <name>, "kind": "humancollab.legal_document.v1", "sha256": <hex of the plain text>, "url": <address
of that version>, "version": <identifier>}. Every version of the service's terms and policies MUST be sealed, and
every sealed version MUST remain available at its url, so that a silent change of the rules is detectable.¶
Leaves are hashed as in [RFC9162]: SHA-256(0x00 || leaf) and SHA-256(0x01 || left || right). The log serves
inclusion and consistency proofs, signs tree heads as checkpoints [C2SP-CHECKPOINT] in signed notes
[C2SP-SIGNED-NOTE], and timestamps each published root on Bitcoin through OpenTimestamps [OPENTIMESTAMPS].
Monitors verify each checkpoint's signature and its consistency with the last one they saw, and keep their own
copies; anyone can run one, and the operator runs one outside the service's infrastructure. Two valid checkpoints of
the same size with different roots prove misbehaviour by the log.¶
A service MAY issue Verifiable Credentials [VC-DATA-MODEL] (Data Integrity, eddsa-jcs-2022 [VC-DI-EDDSA]) stating that a domain was proven by a given method and that a statement version was signed by the bound key and logged at a given index. Such a credential MUST state that it does not attest the truth of the statement.¶
| Reader checks | Conclusion |
|---|---|
| Signature valid, key bound to domain by DNS | The domain's controller made this statement |
| Leaf included in a checkpoint seen by monitors | The statement was public at that time and was not rewritten |
| Key history shows a recent change | Weigh the change; control of the domain changed hands or was re-proven |
| Statement contradicted by independent sources | The author is accountable for a false statement |
The log stores no personal data for people: only seals. Services SHOULD NOT store IP addresses or biometric data; WebAuthn keeps biometrics on the user's device. Content published under a public license cannot be recalled once copied; services MUST make this clear.¶
Control of a domain's DNS is control of its statements. Readers SHOULD weigh recent key changes.¶
A log operator can refuse to log or can present split views; signed checkpoints, Bitcoin timestamps and monitors run by parties other than the operator make split views detectable but not impossible to attempt. Witness cosigning [C2SP-WITNESS] further reduces this risk.¶
Self-declared client names (user agents) used for usage counts are not authenticated and MUST be labelled as such.¶
Publishing a person's full assertion links all statements signed with the same passkey; services MUST disclose this before signing.¶
This document has no IANA actions.¶
The reference implementation and its specification are public domain (CC0 1.0) at https://github.com/furkanYanteri1/humancollab-protocol.¶