TIP Protocol

Changelog

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.

2.3.0

• New: Friendly error map (Theailab_Error_Map). Every user-visible error from the TIP node is now translated from opaque codes (“content_hash_mismatch”, “signature verification failed”, “url_already_registered”, 409, 429, 5xx, network failures, invalid TIP-ID format, revoked identity, missing vp_id, missing registered_urls, auth/nonce, reserved identity type) into plain English with an actionable next step. The raw node message is still preserved in the transaction log for developer debugging.
• New: Real content retraction. Prior to this release the plugin treated the node’s /v1/content/:ctid/retract endpoint as unsupported and only recorded retractions locally. When a signed post is trashed the plugin now signs a canonical CONTENT_RETRACTED payload and submits it to the node so the DAG record reflects the retraction. Local state still flips even if the network call fails, so trashing always drops the reader-facing badge.
• New: Revocation feed subscription. Hourly WP-Cron beat calls the node’s /v1/revocations?since= endpoint and, if the site’s Publisher TIP-ID or any personal Author TIP-ID in the contributor registry appears in the revocation list, marks it locally revoked. The registrar refuses to sign with a revoked identity, so publishers stop producing signatures the node would reject.
• New: Reserved-identity-type gate. Importer now correctly flags syndicator / institution / service / collective .tip.json packages as reserved for a future protocol release, with a distinct error message instead of falling through to the generic “unknown tip_id_type” branch. New THEAILAB_IDENTITY_TYPES_RESERVED constant documents the reserved set.
• New: Milestone counter. Non-blocking admin notice at the 1st, 10th, 100th, 1,000th, and 10,000th successful registration on the site.
• Improved: Tier color hex sync. Consolidated the trust-tier hex palette (Highly Trusted, Trusted, Verified, Caution, Not Trusted) into shared THEAILAB_TIER_COLOR_* constants that mirror the TIP node’s getTier() palette. The Verified tier hex now matches the node (#A88B15) instead of a locally-drifted #C9A84C. Added brand accents THEAILAB_BRAND_GOLD / THEAILAB_BRAND_GOLD_DARK / THEAILAB_BRAND_NAVY for cross-surface consistency.
• Improved: Copy pass replacing internal jargon “Origin code” with plain English “How was this written?” across the classic-editor metabox, the settings help panels, and the button strings. Consistent with the block-editor sidebar phrasing.
• Improved: Field-hint microcopy under the origin-code selector explaining that the label is part of the signed record and cannot be silently changed later.
• Reliability: Test suite grew from 406 to 444+ assertions with new test-error-map.php (18) and test-reserved-tip-id-type.php (20).
• Roadmap: Six additional concepts from the node + browser-extension survey are earmarked for follow-up releases: preview canonical form expander (v2.3.1), content read-back + near-duplicate advisory (v2.3.1), domain binding renewal cron (v2.3.2), prescan tier notice + change-origin grace CTA (v2.3.2), publisher-mode gating by post type (v2.3.3), perceptual text fingerprint envelope with MinHash (v2.3.3).

2.2.2

• Plugin-directory listing: appended five new subsections to the Description body to broaden search discoverability without changing the existing positioning. New sections: About the AI Trust Council (governance body entity), About The AI Lab (research and standards organization entity, names Dinesh Mendhe as inventor), Integrations and compatibility (Yoast SEO, Rank Math, WooCommerce, multisite, caching plugins, page builders, WebAuthn browsers), TIP Protocol glossary (11 named-term definitions covering TIP-ID, CTID, CNA-2.2, ML-DSA-65, SHAKE-256, origin codes, trust badge, AI Trust Registry, Global Seal of Trust, Publisher Mode and Personal Mode, domain binding), and Resources (4 external link targets). No code changes.

2.2.1

• Follow-up review of the 2.2.0 wire-envelope refactor caught two issues that the initial test pass missed.
• Fix: The update-content-origin path on the legacy CNA-2 signer route was missing the same legacy-required-fields fallback that the register path has. When sign_with_context() returns an empty $signature['payload'] (legacy CNA-2 case), the wire body sent to the node was missing signer_tip_id, authors, registered_urls, content_hash, and cna_version. The update path now layers those required fields on top of the helper output exactly as the register path does — same shape, same field names. Legacy CNA-2 update calls work again.
• Fix: Removed duplicate content_hash and cna_version fields from the update path’s auxiliary array. Both were already in the canonical signed payload for the CNA-2.2 case, and the legacy fallback supplies them for the CNA-2 case. Sourcing each field from exactly one place removes the silent-override risk that would have appeared if the canonical builder ever changed those fields’ semantics independently.
• Tests: Extended tests/test-wire-envelope-drift.php from 34 to 46 assertions covering the legacy CNA-2 update fallback shape (all spec-required fields present under the new canonical names; drift-guard fields confirmed stripped even on the legacy path) and the no-aux-override invariant (canonical content_hash + cna_version win when aux tries to set them).

2.2.0

• Fix (signing): Align HTTP wire envelope sent to the TIP node with the current CONTENT_SIGNING.md spec. The update-content-origin call previously shipped three legacy fields the node now rejects on verification: author_tip_id (replaced by canonical signer_tip_id plus authors[]), public_key (node now resolves from the DAG identity record; sending it duplicates state), and registered_url singular (renamed to registered_urls plural and already in the canonical signed payload). The new private helper Theailab_Content_Registrar::build_wire_envelope() anchors every wire body on the canonical signed payload and strips the three legacy keys regardless of caller input. Both the register and update code paths now use it. This was the silent root cause of “Content signature verification failed” reports on personal Author IDs whose verification chain was otherwise cryptographically valid.
• Fix (signing): Personal-mode self-author entries now use the Phase 1 spec values role: "byline" + key_mode: "attribution" (previously role: "reporter" + key_mode: "self_signing"). The publisher’s ML-DSA signature IS the author’s signature in self-mode, so the author entry is marked attribution and signed: false. Earlier values were a leftover from a draft spec; the node verifies signatures over signed bytes that include the authors[] entry, so the wrong role/key_mode produced silently mis-verifying signatures.
• Fix (signing): 409 Conflict responses from the TIP node (signal: the same signer_tip_id + ctid pair is already in flight in the mempool) are now mapped to a distinct theailab_api_conflict_pending error code and surfaced to the post as processing status, not error. The previous behavior flipped the post status to error on every transient mempool overlap and required an admin to manually retry.
• Tests: New tests/test-wire-envelope-drift.php (34 assertions) locks in the wire envelope contract — the three legacy keys are stripped even when callers try to pass them. New tests/test-self-author-shape.php (12 assertions) locks in role=byline + key_mode=attribution for personal-mode self across all three code paths. 46 new assertions total.
• No breaking changes for users. The plugin still accepts the same .tip.json packages, still emits the same admin UI, still renders the same <tip-badge>. The only behavior change is that signatures now verify against the current spec — which is what users expected to happen all along.

2.1.7

• Plugin-directory listing: removed the second Contributor handle (theailab) that WordPress.org’s importer flagged as an unknown user. Only theailaborg was the real WordPress.org account; the second handle was a leftover from an earlier intent to register a sister account. No code changes.

2.1.6

• Plugin-directory listing: complete readme rewrite to improve discoverability on WordPress.org search and external search engines. Sharper short description, new “Why publishers and creators use TIP Protocol” value-prop block, new “Who is this for” industry-targeting block, expanded FAQ with high-volume questions (AI-generated content handling, C2PA / Content Credentials comparison, multi-author and multisite workflows, security model, network endpoints), updated tag list (ai disclosure, content provenance, content authenticity, trust badge, publisher). No code changes.
• Removed the local-development / Docker section from the user-facing readme. That content now lives only in the repository docs where it belongs; it was diluting the SEO signal of the public plugin page and listed local-development credentials that should not appear on a public listing.

2.1.5

• Security: Restructured the byline metabox nonce check (admin/class-tip-metabox.php) into the canonical isset → wp_verify_nonce → current_user_can sequence, with each gate an independent early-return so the conditional logic cannot be bypassed. Sanitized $_POST input at the boundary with explicit wp_unslash + is_array check before the per-entry sanitize_text_field loop.
• Security: Sanitized every $_SERVER access. includes/class-tip-webauthn.php and includes/class-tip-visitor-context.php now apply sanitize_text_field( wp_unslash( … ) ) in a single expression so the WordPress coding-standard analyser sees the sanitization chain, and the phpcs:ignore comments that previously masked these reads have been removed.
• Security: Rewrote the legacy-slug admin redirect (admin/class-tip-admin.php redirect_legacy_menu_slug) to use an explicit allow-list of forwardable query params (tab, section, paged), each sanitized via sanitize_text_field and rawurlencoded before reaching add_query_arg. The previous raw $query_args = $_GET assignment is replaced. Capability check moved above all $_GET access so unauthorized requests never touch the superglobal.
• Security: Added a defence-in-depth current_user_can( theailab_set_origin ) gate to Theailab_Admin::build_editor_state() before reading $_GET[‘post’]; absint() now wraps the post-ID lookup explicitly.
• Prefix uniqueness: Removed the legacy un-prefixed shortcode registrations ([tip-badge], [download_button]) and the legacy register_block_type call for tip/verification-badge. Replaced the alias approach with a the_content filter (Theailab_Public::rewrite_legacy_tokens) that rewrites legacy tokens to their prefixed names at render time, so existing post content authored against earlier versions keeps rendering after upgrade. Updated the Gutenberg JS to register theailab/verification-badge, theailab-origin-panel, and theailab-pre-publish-check (previously tip/verification-badge, tip-origin-panel, tip-pre-publish-check).
• No functional changes for end users.

2.1.4

• Compatibility: Bump “Tested up to” header to 7.0 (current WordPress release). No code changes; the WordPress.org automated scanner blocks uploads whose declared compatibility falls below the latest WP version, and this metadata bump unblocks the resubmission of the 2.1.3 prefix-uniqueness fixes.

2.1.3

• Compliance: Address WordPress.org Plugin Directory review feedback on prefix uniqueness. Three PHP-level identifiers carried short or generic prefixes that could collide with other plugins:
  • Bootstrap function tip_protocol() renamed to theailab_tip_bootstrap(). A guarded backward-compat alias preserves the old name for any third-party code or theme snippet that referenced it.
  • Gutenberg block namespace tip/verification-badge renamed to theailab/verification-badge. The legacy block name is also re-registered as an alias so existing post content that embeds the old block continues to render unchanged.
  • Admin menu slug tip-protocol (previously routed to admin.php?page=tip-protocol) was already moved to theailab in an earlier release; this version adds a 301 redirect from the legacy URL to the new one so bookmarked admin URLs keep working.
  • Shortcodes [tip-badge] and [download_button] continue to render via backward-compat aliases registered alongside the canonical [theailab-tip-badge] and [theailab_download_button] names.
• No functional changes for end users. Existing content keeps working; the renames are purely to satisfy the WordPress.org plugin uniqueness rule.
• Bump version forces a cache-buster URL refresh.

2.1.2

• UI fix: The scope picker dropdown clipped the descenders of “publishers” because the wp-components SelectControl forced a fixed height that conflicted with the picker’s padding. Replaced the height constraint with height: auto, increased line-height to 1.5, switched to a custom-drawn navy chevron with explicit right-padding so the option text isn’t crowded, and bumped vertical padding to 12px. The dropdown now renders the full option text cleanly at any zoom level.
• Sign reliability: Added a server-side self-verification step right after each ML-DSA signature is produced and before the registration request is sent to the TIP node. If the stored public key doesn’t correspond to the private key the plugin just signed with — most often because a personal Author ID was imported with a derived (not original) public key — the user gets a precise local error pointing at the cause and remediation, instead of the opaque “Content signature verification failed” the node returns.
• Sign reliability: The registration payload sent to the TIP node now includes the public_key field. Without it, the node had to look up the TIP-ID’s public key on the DAG to verify, which fails for newly-imported personal Author IDs that haven’t been published to the network yet. Including the key gives the node a deterministic verification path; the node should still cross-check this against its DAG record when one exists.
• Sign reliability: When the TIP node rejects a registration with a “signature verification” error AND the local self-verify passed, the editor now surfaces a guided message explaining that the TIP-ID likely isn’t yet published to the TIP DAG (and pointing the user at vp.theailab.org), instead of relaying the raw node error verbatim.
• Bump version forces a cache-buster URL refresh.

2.1.1

• UI: The “What kind of identity is this?” dropdown on the Connect-an-Identity card was easy to overlook even though it controls the most important decision in the import flow (publisher vs. personal). Wrapped it in a high-contrast picker with a colored border, gradient background, “REQUIRED” tag, large icon (🏢 / 👤), and a prominent uppercase label. The picker color-shifts to blue when “Site identity” is selected and green when “Personal Author ID” is selected, so the user gets instant visual confirmation that their choice registered.
• Bump version forces a cache-buster URL refresh.

2.1.0

• Feature: Optional WebAuthn / biometric step-up for personal-mode signing. Writers who choose to can now require a fingerprint, Face ID, Windows Hello, or hardware security-key tap before each post is signed with their personal Author TIP-ID. Configured per-user in WordPress profile, defaults OFF for everyone, and is never a barrier — publisher-mode signing, scheduled posts, WP-CLI, REST automation, and cron-driven workflows always bypass step-up. If a user enables the toggle but has no enrolled key, signing still proceeds; if they remove their last key, the toggle auto-disables.
• New REST surface under /theailab/v1/webauthn/ (status, register/begin, register/complete, auth/begin, auth/complete, required, credentials/remove). All routes are nonce-protected and operate only on the calling user’s row.
• Server-side verifier uses native PHP openssl_verify() with public keys exported directly from the browser via AuthenticatorAttestationResponse.getPublicKey() — no third-party dependency, no CBOR parser, supports ES256 and RS256 algorithms, enforces userVerified flag and signCount monotonic check.
• Editor integration: Both classic and Gutenberg editors detect a 428 Precondition-Required response from /origin/register, run the WebAuthn assertion ceremony, and retry with the resulting single-use ticket. Errors are surfaced via the existing inline-status banner with clear remediation guidance.
• Security audit: WebAuthn step-up is a defense-in-depth layer over the existing capability/nonce model — it gates the API call but does not replace any existing check, and the actual content signature remains ML-DSA-65 over the canonical hash, server-side, exactly as before.

2.0.11

• Fix: When the TIP node returned a structured error response (e.g. {"error":{"message":"…"}}), the plugin’s API client cast the nested object to a string and surfaced the literal word “Array” in the editor — users saw “Couldn’t sign this post / Array” with no actual reason. The client now walks the common shapes (error as string or {message,detail,description,code,reason,details[]}, top-level message, plural errors[]) and falls back to a short raw body snippet or a status-code message, so the real reason from the node always reaches the user.
• Bump version forces a cache-buster URL refresh.

2.0.10

• Fix: Personal Author IDs exported from vp.theailab.org (DOB-locked tip-key-export-v2 files) failed to import with TIP-PKG-2 packages must declare vp_id.. Personal identities are self-claimed and never carry a publisher review, so the importer no longer requires vp_id for tip_id_type === "personal". Publisher and platform identities continue to require a well-formed vp_id, and personal exports that do include one are still validated against THEAILAB_VP_ID_REGEX.
• Bump version forces a cache-buster URL refresh.

2.0.9

• Apply the v2.0.8 inline status …