TIP Protocol

2.5.1

• Fix. An organization TIP-ID with no personal byline can sign. When no writer is credited on a post, the organization is listed as its own author, the same way the TIP browser extension and the verification portal sign for an organization. Before this, the TIP network refused every such post because it requires at least one author, and the error sent publishers to an “Allow author-less posts” setting that the settings screen never showed. Posts that credit a writer are unchanged and still name that person as the byline.
• Fix. The page markup credits an organization that signed as its own author as an Organization, not as a Person named after the WordPress user who pressed Publish.
• Fix. Importing an organization TIP-ID file now asks for the organization’s date of incorporation, which is the date that locks it. The unlock screen used to describe every locked file as a personal Author ID locked with a date of birth, so organizations typed the wrong date and the file looked broken. Personal Author ID files still ask for the date of birth.
• Tests. 697 to 716 assertions across 22 files, all passing. They cover the organization-as-author context, the validators that check it, and the page markup. The signed payload for an organization signing as itself was compared byte for byte with the payload the TIP network’s own code builds from the same input, and an organization file locked with the network’s own key-file code was unlocked by the plugin’s import code.
• Verified against the TIP node repository as of 2026-10-04. No change to the signing recipe or any endpoint.

2.5.0

• New (security, behaviour change). Biometric signing on every publish. Every content signature, for personal and organization TIP-IDs alike, now requires a WebAuthn user-verification confirmation (Face ID, Touch ID, Windows Hello, a fingerprint reader or a security-key PIN) by the WordPress user who triggers it. There is no per-user or per-site switch. The earlier opt-in step-up from 2.1.0 is retired.
• New. Biometric sign popup in both the block editor and the classic editor. It opens right after a post is first published or scheduled, lets the writer confirm the AI-disclosure label, and walks first-time users through adding their device. Users who sign from a new computer can add it from the same popup. The popup is keyboard accessible, keeps focus inside, announces progress to screen readers and closes with Escape.
• New design. The popup, the editor sign panel and the profile device list follow a quiet editorial style, with one typeface, ink on light grey, hairline rules and no shadows, gradients or icons.
• Security. Signing has a single enforcement point. The registrar refuses to decrypt a private key unless the current request carries a single-use proof that the same user just passed a verified WebAuthn assertion for that exact post. Publish hooks, the legacy /register and /update REST routes, cron, WP-CLI, XML-RPC, application-password REST calls and the prescan “accept” link cannot sign. Retracting a post and updating its address after a permalink change remain automatic, because they add no new authorship claim.
• Security. Adding or removing a signing device requires the account’s WordPress password (five wrong attempts lock the step for 15 minutes), and the account owner is emailed on every change. Without this, anyone holding a session cookie could add their own authenticator. Administrators can remove a user’s device from that user’s profile. Sites that sign in through single sign-on can turn off the password step with the theailab_webauthn_require_password filter.
• Security. When a post signs with its author’s personal TIP-ID (no site-wide TIP-ID), only that author can confirm the signature. An editor’s confirmation no longer authorizes another person’s key.
• Security. Challenges and tickets are now claimed atomically, so two concurrent requests can never spend the same one. Several challenges can be open at once, so two editor tabs no longer cancel each other. A signature counter that drops back to 0 is treated as a possible cloned key. Device data from the browser is size-limited, and only P-256 and 2048 to 4096-bit RSA keys are accepted. The biometric REST routes require the content-signing capability.
• Publishing is never blocked. Posts published from tools that cannot show a biometric prompt (mobile apps, REST integrations, WP-CLI, scheduled publishing) go live as usual, wait as “awaiting biometric signature”, and are listed under Waiting for a signature in the dashboard widget until someone signs them from the editor. Private posts are never prompted, because signing registers a post on the public TIP network.
• Fix. Scheduled posts are signed with the address they will have once live. WordPress gives scheduled posts a plain ?p=ID link, which would otherwise have been signed into the record. When a scheduled post goes live, its registered address is also checked and repaired if the slug changed.
• Fix. A label change on a registered post (accepting the AI prescan suggestion) only ever uses the lean origin update; it can no longer turn into a second full registration. The label is changed only after the signature succeeds, so cancelling leaves the post as it was and the suggestion can be accepted again.
• Fix. The label chosen in the block editor sidebar is now the one the sign popup and the pre-publish check show.
• Fix. Safari compatibility. Ceremony options are fetched before the click and refreshed before they expire, and the sign button waits until they are ready, so Safari, which only allows passkey prompts in direct response to a click, no longer refuses the confirmation. This also applies to adding a device on the profile page.
• Fix. The relying party is the wp-admin host. Each device records the address it was set up for, and devices set up for another address are listed but not offered for signing, so the popup asks to add this device instead of failing.
• Fix. The first-publish hook covers every public post type. The previous hooks only fired for posts and pages, so custom post types such as WooCommerce products never reached the publish flow. The editor panels no longer load in the site editor.
• Fix. A site with no TIP-ID connected is not asked for biometrics on publish. The editor shows a link to connect a TIP-ID instead.
• Fix. TIP-IDs with three-letter regions (for example tip://id/IND-…), which exist on the TIP network, can now be imported. The importer previously accepted only two-letter regions.
• Fix. The biometric audit record is written to the local transaction log for every signature. Earlier releases stored it in post meta that nothing read.
• Privacy. WordPress’s personal data export now includes each user’s signing devices, and erasure removes them; audit records of posts already signed are kept with the post’s transaction log. The suggested privacy policy text describes passkeys, the audit record, and that a signed post’s text is sent to the TIP node. The FAQ previously said the article body was not sent; that was wrong and is corrected.
• Improved. Plain-English messages for the TIP network’s 412 byline checks, for expired sessions, and for every WebAuthn failure. Admin notices when wp-admin is not served over HTTPS or the server lacks the OpenSSL extension. Uninstall removes passkey records network-wide on multisite, plus pending sign prompts.
• Tests. 559 to 697 assertions across 22 files, all passing. The WebAuthn verifier is driven with real P-256 keys and signatures through every rejection path, including replay, missing user verification, wrong origin or relying party, altered data, a foreign key, a cloned-key counter, password-less enrollment, unsupported key types and concurrent claims. Source contracts pin where the signing gate, the ownership check and the relabel rule sit. Key checks were confirmed by mutation testing. The flow was exercised end to end in a real WordPress install in both editors.
• Verified against the node, verification-provider and browser-extension repositories as of 2026-10-04. No contract-affecting upstream change. The canonical payload, hash and signature recipe, the author-signed actions and the .tip.json export are unchanged, and the node neither requires nor accepts any biometric field, so this release changes no signed bytes.

2.4.1

• Fix (forward-compatibility, protocol-critical): registrations of posts without attached media no longer send empty media-fingerprint fields to the TIP network. The network’s latest schema validates the media fingerprint against a strict 64-character format and treats an empty string as malformed, which would have rejected every text-only post registration once that node release deploys. The plugin now omits the media fields entirely when a post has no attached media, which the network explicitly treats as valid. Posts with attached media are unaffected, and because these fields sit outside the signed payload, no signature bytes change and all existing registrations remain exactly as they are.
• Improved: plain-English explanation for the network’s malformed-media-fingerprint rejection, pointing at the actual causes (manifest tampering by another plugin) rather than surfacing a raw error code.
• Tests: 549 to 559 assertions, all passing, including coverage that text-only registrations omit the empty media fields while media-carrying registrations preserve them byte-for-byte.
• Verified against the node and verification-provider repositories as of 2026-08-20: this schema bounding is the only contract-affecting upstream change; the signing algorithm, canonical payload, identity import format, and every endpoint the plugin calls are unchanged.

2.4.0

• New: AI-prescan verdict on the edit screen. After each registration the plugin reads back the network’s asynchronous AI check and, if the content was flagged while labeled Original Human, shows a clear warning with the network’s own explanation, the zero-penalty decision deadline, and a one-click “Change label to AI-Assisted” action. Relabeling inside the window costs nothing; ignoring a strong flag can escalate to a network reviewer, so the plugin now makes that choice visible instead of silent.
• New: near-duplicate advisory. When the network’s similarity sweep matches your newly registered post against existing registered content, a non-blocking amber notice lists the closest matches. The registration itself succeeded and keeps its own record; the notice is context, not an error, and can be dismissed.
• New: “Preview what will be signed” expander in the classic editor metabox. Shows the exact normalized text and hash that will be signed, so writers can see why smart-quote changes, markup edits, or whitespace tweaks after publishing can invalidate the badge. Read-only and loaded on demand.
• New: domain binding renewal. The plugin now re-verifies the domain binding twice daily (when due) instead of trusting a one-time check forever. A transient network blip never drops the verified state: the status only downgrades after five consecutive failures, mirroring the network’s own failure budget.
• New: share-card warming. After each registration the plugin pings the verification provider’s card renderer so findtip.org share links unfurl correctly on the very first scrape instead of showing an empty card that social platforms then cache.
• Reliability: the read-back is fully non-blocking with capped retries; every new surface is advisory and can never affect registration state or editing.
• Tests: 521 to 549 assertions across 19 files, all passing, including behavioural coverage for the read-back scheduler, retry caps, verdict projection, and the share-card ping.
• Roadmap: per-post-type default signer and the perceptual text fingerprint envelope remain planned for a future release.

2.3.2

• Fix (protocol-critical): origin updates and retractions now use the TIP node’s author-signed action contract. The node verifies these post-registration actions against a small fixed field set signed by the registering identity, with the content ID bound into the signature server-side so a captured signature cannot be replayed against different content. Earlier releases sent a differently shaped body for both actions: the node rejected every origin update and every retraction at validation, and retractions silently fell back to local-only. Both actions now reach the network correctly.
• New: automatic permalink repair. Changing a registered post’s slug or permalink now proposes an owner-signed registered-URL update to the TIP network, so the public record follows the post instead of pointing at a URL that no longer resolves. The repair compares the recorded URL against the current canonical permalink on every post update, which also heals older registrations whose stored URL predates the canonicalization fix in 2.3.1. Failures are logged and retried on the next edit; they never block editing or flip the post’s registration status.
• Compatibility: the wire envelope now explicitly tolerates the network’s new optional parent-context URL field on content records, and the drift-guard test suite locks in that tolerance. Content registered by this plugin is unaffected; the field exists for reply-type content registered by other TIP clients.
• Improved: three new plain-English error explanations, including a targeted message when the site’s current signing identity differs from the identity that originally registered a post (previously this surfaced as a misleading “session expired” message).
• Tests: 495 to 521 assertions across 18 files, all passing. New coverage pins the exact signed bytes for all three author actions so the field-set regression that motivated this release cannot return.
• Verified against the node, verification-provider, and browser-extension repositories as of 2026-08-15: the content registration contract, the .tip.json export format, and the signing algorithm are all unchanged — existing registrations and imported identities are unaffected.

2.3.1

• Fix (protocol-critical): registered URLs are now WHATWG-canonicalized before signing. The registered URL is part of the cryptographically signed payload, so the TIP node cannot normalize it and instead rejects any URL that is not already in canonical form. WordPress permalinks frequently are not: a site whose front page URL has no trailing slash, a host with any uppercase letter, an explicit :80 or :443 port, an internationalized domain, or a post slug containing non-ASCII characters would all have been refused by the network. The plugin now converts each URL to the exact same canonical form the rest of the TIP ecosystem produces, verified byte-for-byte against 32 reference cases covering Latin, accented, Cyrillic, CJK, and internationalized-domain inputs.
• Fix: identity imports no longer discard issuer data. When unlocking a date-of-birth protected .tip.json from vp.theailab.org, the plugin previously hardcoded the identity type and dropped the verification-provider ID and display name that the file actually carried. All three are now read from the file and passed through, so the issuer binding is preserved and writers appear under their real name in bylines instead of a bare TIP-ID.
• Improved: added a plain-English explanation for the network’s non-canonical-URL rejection, so the rare remaining cases (a permalink with an embedded username and password, or a non-http scheme) produce actionable guidance rather than a raw error code.
• Tests: 447 to 495 assertions across 17 files, all passing. New coverage includes a URL canonicalization suite whose expectations were generated from the reference implementation, plus explicit guards for the byte-safety bug that would silently corrupt non-ASCII permalinks.
• No changes to signing keys, the canonical payload shape, or stored data. Existing registrations are unaffected.