“Who made this, when, and how do you know?” has been a legal footer for most of the web’s history. A line of gray text at the bottom of the page. Nobody reads it. Nobody needs to, because the domain name and the visual design and the overall vibe do the trust work that formal provenance would do if anyone bothered.
That is changing for a reason that has nothing to do with regulation or compliance: the primary consumer of trust signals is shifting from humans to machines. A human can vibe-check a website. A machine cannot vibe-check anything. A machine needs structured attestations — signed claims from identifiable parties — and it needs to evaluate them at speed.
When the reader is a machine, the attestation moves from the footer to the foreground. It becomes a design surface.
What an attestation surface looks like.
An attestation is a signed claim by an identifiable party. “This product was manufactured by X, inspected by Y, and certified by Z.” Each element — the manufacturer, the inspector, the certifier — is a party whose identity can be verified, whose claim is signed with a key they control, and whose signing history is queryable.
The design challenge is presenting this to two audiences simultaneously. The machine needs the structured, signed, parseable version. The human needs the legible, trustworthy, not-overwhelming version. These are not the same presentation, but they need to represent the same truth.
The closest precedent is probably the SSL certificate indicator in the browser chrome. A green padlock for verified, a warning for unverified. That model works for binary trust decisions — is this connection encrypted, yes or no. Attestation surfaces need to handle continuous trust: this party has been verified, their claim covers these aspects, this other aspect is unattested, and this attestation was issued three years ago and might be stale.
The visual vocabulary for this does not exist. Traffic lights are too crude. Badge systems devolve into meaningless collections. Detailed audit trails overwhelm the user. The design problem is genuine: how do you make complex provenance legible without making every product page feel like a security audit?
The machine layer.
Underneath the human-facing design, the machine layer is more straightforward. Attestations are JSON-LD objects with standard fields: who signed, when, what they attested, the hash of the artifact they attested to, their credential chain, and the revocation endpoint. An agent evaluating the product reads this layer directly, checks the signatures, verifies the credentials, and integrates the trust signal into its decision.
The human never needs to see the JSON. The human sees the design surface that the JSON generates. A badge that says “verified by Bureau Veritas, June 2025” is a rendering of a signed attestation. The rendering is design. The attestation is infrastructure.
The organizations that get this right — two layers, one truth, different presentations for different readers — will have a structural advantage in an agent-mediated economy. The ones that treat attestations as compliance overhead will look unverified to every agent that evaluates them, which increasingly means looking unverified to the humans those agents serve.
The design discipline.
Attestation surface design sits at the intersection of information design, cryptographic infrastructure, and UX. It requires understanding signed credentials enough to know what can be verified and what cannot. It requires information design skill to present complex provenance clearly. It requires UX sensitivity to avoid turning every interaction into a trust interrogation.
Nobody is teaching this. The cryptography people think design is someone else’s problem. The designers think cryptography is someone else’s problem. The gap between them is where the discipline needs to form.
Seems like an obvious place for design education to go next, if design education were paying attention to where the reader is going. Not sure it is.