Summary

  • The individual Internet-Draft lets an issuer evaluate a wallet condition against a referenced chain state and return a signed boolean that can be verified offline with JWKS.
  • In the JSON format, the signature covers id, pass, results and attestedAt; expiresAt, kid, wrappers and usually the wallet identity itself sit outside those signed bytes.
  • A valid signature proves an issuer signed a defined observation. It does not prove that the observation path was independent, the block is final, the state is still current, replay is impossible or access should be granted.

A green answer with an old referent

Suppose an access service asks whether a wallet holds enough stake. The issuer reads a chain endpoint, evaluates the condition, signs pass: true, and includes a block reference and signing time. The relying party verifies the signature five seconds later. Cryptographically, the artifact may be flawless. Operationally, the wallet may already have transferred the stake, the chain may have reorganised, or the issuer may have read a lagging indexer.

Those possibilities do not invalidate the signature. They reveal what it signs. The signer vouches for the recorded evaluation and anchors, not for an eternal world state. Revision 01 is unusually useful because it exposes that custody line instead of hiding it behind the word “attestation”.

The document was posted on 27 September 2026. Datatracker places it under Individual Submissions, with no standards stream, and records only Active and I-D Exists. The text says it profiles existing JWT, JWKS and JOSE building blocks rather than defining a new wire protocol. It is not an adopted working-group item, an RFC, interoperability result or deployment report.

Four signed members, several adjacent decisions

The JSON form defines one narrow signature surface: id, pass, results and attestedAt. Each result carries the evaluated condition, its hash and a chain-specific reference. EVM uses block number and timestamp; XRPL uses ledger index and a hash where available; Solana uses a slot; Bitcoin uses height and hash as chain-tip evidence.

Revision 01 offers two reconstruction schemes. The bare scheme depends on the exact transmitted member order, including nested result members. The domain-separated scheme adds a message-type tag and version, then uses RFC 8785 canonical JSON. That is an interoperability improvement: two implementations can reproduce the same bytes more reliably. Canonicalization still proves only byte agreement. It cannot make a selected RPC source canonical or a referenced block final.

The adjacent fields matter. In JSON, kid, sig and expiresAt are not part of those signed bytes. A verifier uses kid to select both the key and reconstruction scheme from the issuer’s JWKS. A missing or unknown value is unverifiable, not refuted, and another key must not be substituted. During key introduction, cached JWKS versions can therefore split verifiers into those that can place the artifact and those that cannot.

The signed object also does not generally name the wallet. Some conditions may put an address inside evaluatedCondition, but a second-hand JSON artifact cannot assume that binding. The JWT form is different: it signs sub and exp, and it must be verified in its own right. Verifying the neighbouring JSON signature is not a substitute for verifying the JWT.

Freshness is a policy over anchors

The draft calls the per-result chain reference and signed attestedAt the cryptographically bound freshness anchors. It then gives the decisive responsibility to the verifier: decide how old either may be for this transaction. A thirty-minute attestation age and a sixty-second block age answer different questions. A fresh signature over a stale block is still a fresh signature.

The JSON expiresAt is only an unsigned TTL hint. Revision 01 recommends rejecting a value that extends beyond signed attestedAt plus the issuer’s documented window; deployments needing protected expiry should use signed JWT exp. More subtly, expiry checking is RECOMMENDED, not REQUIRED. A leadership policy must therefore state what happens when a verifier omits the check. “Signature valid” cannot silently mean “all recommended freshness controls performed”.

Replay control is another local decision. The signed id can support a seen-set, but nonce and audience binding are left to integration profiles. An artifact may be current enough by time and still be reusable in a context for which it was never bound.

The chain can revoke yesterday without touching the signature

Revision 01 explicitly leaves RPC routing, indexer selection, archive-node choice, finality and data availability out of scope. It also says a reorganisation after issuance may make the observed historical state non-canonical. Strong finality, older references, independent cross-checks or deployment-specific reorg logic are operator choices.

That creates at least three clocks. The issuer has an observation clock. The chain has a canonicality or finality clock. The relying party has a decision clock. The artifact connects them, but does not merge them. A successful Merkle proof can reduce trust in an issuer’s evaluation against a named root; it still needs a finality judgment about that root and a policy about whether that historical fact remains adequate now.

The conditionHash provides another precise but limited receipt. Recomputing it detects alteration of the declared predicate. It does not independently show that the issuer used the right chain, the right block, the right data source or the right business threshold. Syntax integrity and observation integrity are adjacent controls.

What the receipt ledger must say

Lu Heng’s reality-layer discipline maps cleanly onto this design. Keep the signed representation separate from the issuer’s observation, the chain’s canonical state, the current state and the service decision. Running-Code Primacy makes the live chain and observed application outcome superior to a label such as “attestation verified”. Minimum Initial Specification argues for a small shared format while leaving finality and authorization policy explicit and reversible.

An honest audit record therefore retains the issuer, exact kid, scheme and domain tag; reconstructed-byte hash; primary and companion verdicts; condition-hash outcome; wallet-binding surface; block or ledger reference; independent-source and finality judgment; signed time; expiry decision; replay or audience decision; authorization rule; and observed downstream result.

The most dangerous compression is a single green boolean. It erases whether the signature was verified, the anchor was recent, the anchor remained canonical, the wallet was bound, replay was excluded and the action was authorized. The draft’s own verification procedure recommends separate verdicts. Operators should preserve that plural.

Sources and limits

These sources do not establish IETF consensus, a working-group adoption, assigned interoperability profile, implementation, deployment, independent chain observation, finality, holder consent, wallet control, successful authorization, settlement, delivery or service outcome. Ecosystem-adoption statements inside the draft remain the authors’ informative claims unless independently verified.