Skip to content

Releases: MachinesOfDesire/axis-platform-sdk

Release list

0.5.0 — Web Bot Auth inbound verification

0.5.0 — Web Bot Auth inbound verification Latest
Latest

Choose a tag to compare

View all tags
@MachinesOfDesire MachinesOfDesire released this 03 Aug 04:45
v0.5.0
d938828
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode. 
npm install axis-platform-sdk@0.5.0

Added — axis-platform-sdk/webbotauth

Verify that an inbound request really came from the bot it claims to be, using HTTP Message Signatures (RFC 9421) as specified by the Web Bot Auth drafts.

  • verifyWebBotAuth(request, opts) — selects the signature tagged web-bot-auth, rebuilds the RFC 9421 signature base, fetches the signer's key directory from /.well-known/http-message-signatures-directory, and checks the Ed25519 signature.
  • webBotAuthGate(request, opts) — composes it with verifyAgent in three postures: either, axis, both.

No new dependencies. Ed25519 via WebCrypto, so it runs on Node 20+, Cloudflare Workers and modern browsers like the rest of the SDK.

What a signature does and does not prove

A valid signature identifies the software vendor — "this really is that crawler." It says nothing about who the agent acts for, what it may do, or whether that can be withdrawn.

Question Answered by
Is this really who it claims to be? verifyWebBotAuth
May this party do this thing, and can I revoke it? verifyAgent

webBotAuthGate composes the two rather than blurring them.

Hardening

  • keyid is checked against the JWK thumbprint of the published key (RFC 8037 §A.3), so a directory cannot name one key and publish another.
  • A present Signature-Agent must itself be covered by the signature, so an intermediary cannot rewrite it and redirect key discovery.
  • Both documented Signature-Agent forms are understood — bare String and Dictionary, the latter selected by the covered component's ;key=. A member declaring type=cimd points at an agent card rather than a key directory and is refused rather than misread.
  • expires required by default; maxAgeSeconds caps replay of stale signatures.
  • A directory outage is never a credential failure — unreachable, timed out or non-2xx all deny as wba_directory_error with retryable: true.

Tested against an independent implementation

The suite replays the Web Bot Auth test vectors published by Cloudflare Research. This matters: signing and verifying with your own key proves self-consistency, not interoperability — a signature base that is wrong in a way your own signer shares round-trips perfectly. Those vectors found two real defects before release.

npm run interop:live replays them against real key directories on the public internet and checks each published kid really is the RFC 8037 thumbprint the SDK computes.

Fixed

  • SDK_VERSION reported 0.3.1 while the package was 0.4.0. Published 0.4.0 therefore advertised the wrong version in X-AXIS-SDK-Version on every registry request.
  • The README's upgrade advice was wrong pre-1.0. It said to pin a caret range for safe updates, but a caret pins to the minor for 0.x — ^0.4.0 never accepts 0.5.0. Anyone following it silently stopped receiving updates, including security fixes. If you pinned ^0.4.0, you will not get this release until you widen the range or pin 0.5.0 explicitly.

Full detail in CHANGELOG.md.

Assets 2
Loading