Summary
- The first public Wathīqa evidence-record draft proposes a chain of attestations that can renew a preserved document under new signature primitives before an old one becomes unsuitable.
- Its two temporal controls are unequal. A transparency-log inclusion receipt is intended as authenticated “not-after” evidence; a randomness-beacon anchor carries “not-before” metadata but is explicitly unauthenticated in revision 00.
- Witness checks are conditional on the caller supplying trusted witness keys. Without that set, the verifier checks content, signatures and predecessor hashes but does not require the inclusion receipt or its time ordering.
- The draft is an Experimental-intended individual Internet-Draft, not an IETF standard or Working Group decision. It reports a complete multi-language implementation but no independent cryptographic review, repository or pinned revision.
- A useful operational result must therefore expose at least three states: cryptographic chain validity, witness-backed upper-bound evidence under a named policy, and the current lower-bound claim as unverified.
A durable signature still needs a date it can defend
Long-term evidence does not fail only when a private key is stolen. It can fail because an algorithm that was acceptable when a record was created is no longer considered strong enough when somebody relies on it years later. The renewal has to occur before that loss of confidence. A fresh signature added after the old primitive has already become forgeable cannot retroactively prove which earlier bytes were genuine.
RFC 4998 already builds renewal into Evidence Record Syntax. It says archive timestamps must be renewed before the relevant algorithms weaken or timestamp certificates become invalid. It also puts the intelligence needed to judge weakening, compromise risk and suitable lifetimes outside the syntax. That division is unavoidable: bytes can record a decision, but they cannot know the future history of cryptanalysis.
The new Wathīqa draft adapts that problem to signature-algorithm agility. One content address is followed by a chain of entries. Each entry signs the protected content under a stated primitive; later entries commit to the canonical hash of their predecessor. The profile names ML-DSA and SLH-DSA, standardized in FIPS 204 and FIPS 205. Those standards identify algorithms. They do not certify this profile or decide how long any relying party should accept a particular parameter set.
The upper bound and lower bound do different work
Wathīqa proposes two ways to place a link in time. The first is an inclusion receipt from an append-only transparency log. A signed tree head and Merkle path can show that the link's signature was present in the logged tree no later than the tree-head time. This borrows concepts from RFC 6962. It is an upper bound, not proof of the instant at which the signer created the link.
The second is a claim tied to a NIST Randomness Beacon pulse. A verifier that authenticates a signed pulse whose unpredictable value is committed into the link could use it as evidence that the link was not formed before that value became public. The NIST Beacon 2.0 page describes pulses as sequenced, time-stamped, signed and hash-chained, while still labelling the service beta and work in progress.
Revision 00 does not perform that authentication. Its Security Considerations say the verifier checks no beacon proof. The stored anchor is tied to the link's signature by a hash equality, but that only proves that this anchor record accompanies this signature. It does not prove that the beacon issued the claimed pulse. The draft says an adversary can populate arbitrary not-before metadata and instructs relying parties not to treat the anchor as authenticated time.
This is not a hidden defect inferred from an attack laboratory. It is a limitation stated by the author. It also means a screen that renders both fields as two equivalent green timestamps would claim more than the protocol has established.
Supplying W changes what “accept” means
The witness side is stronger, but it is not unconditional. The verification procedure accepts an optional set W of trusted witness public keys. When W is supplied, every link must carry a valid inclusion receipt, the signed tree head must verify under a key in W, and those timestamps must be non-decreasing. When W is absent, those requirements are not run. The mandatory path still checks the protected data's content address, every link signature and every predecessor commitment.
The difference is operationally large. Two conforming calls can process identical bytes and both return acceptance while carrying different temporal evidence—one because a named witness policy was enforced, the other because no witness policy was requested. “Valid Wathīqa record” is therefore too compressed a statement unless the output records whether witness enforcement occurred.
Even a successful receipt is conditional on more than mathematics. The verifier must know which witness keys it trusts. Those keys rotate. Revision 00 recommends quorum-authorized, append-only witness-key succession pinned to a long-lived anchor, but it does not supply the institutional operation of that succession. A record designed to outlive algorithms may also outlive the organizations, contracts and incident procedures that maintained its original roster.
The first draft is evidence of a proposal, not adoption
Datatracker lists the text as an individual Internet-Draft with no RFC stream. It is dated 3 September 2026, intended as Experimental and due to expire on 7 March 2027. The I-D announcement establishes that the first public revision was circulated; it does not confer IETF endorsement.
The document says a complete Python reference implementation exists and that JavaScript and Rust verifiers reproduce a shared canonical chain hash. It also says the security argument has not undergone independent cryptographic review. Revision 00 supplies no repository or commit URL, so those implementation and cross-validation claims were not independently reproduced for this Article.
There is a smaller but useful specification warning. Section 4.3 calls the wrapped ASN.1 DER profile version 3 and says its detailed module lives in an authoritative external Python file pending inclusion in a future revision. Appendix B says the current DER profile is version 4, versions 1 through 3 remain decodable, and only version 4 is emitted. The modern ERS modules in RFC 9169 provide a published ASN.1 baseline; they do not resolve which Wathīqa extension version revision 00 intends.
That mismatch may be an ordinary first-draft edit. It should be repaired before interoperability is inferred, especially because the claimed authoritative file is not frozen by a link in the draft. The two proposed media types are also described as outstanding and not yet filed. None of this proves that an implementation is unsafe. It shows that document, code, identifier and test-vector authority are not yet joined into one reproducible release.
A chain can verify without proving the whole timeline
The narrow finding is an asymmetry. The content address and predecessor commitments can be checked locally. Signature verification can establish that the supplied keys validate the supplied messages. With a selected witness set, an inclusion receipt can add authenticated not-after evidence. The current beacon field cannot add authenticated not-before evidence because the current verifier does not validate the pulse.
That leaves several claims outside the binary result. The record cannot decide when an algorithm stopped being acceptable. It cannot choose an organization's trusted witnesses. It cannot guarantee that a log showed one consistent history to everyone. It cannot keep a witness-key governance process alive for decades. And it cannot make an unauthenticated lower-bound claim stronger by placing it beside a post-quantum signature.
Those are not reasons to discard the proposal. They are reasons to name each layer precisely. The draft is most useful when read as an early attempt to keep algorithm renewal portable while leaving relying-party policy local. Its evidence should stay granular enough that the local choice remains visible.
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance

