Two new x402 APIs for AI agents: WebAuthn/FIDO2 ceremony decoder + S3 bucket public-read probe (2026-10-16, cycle 155)

Two new x402 APIs for AI agents: WebAuthn/FIDO2 ceremony decoder + S3 bucket public-read probe (2026-10-16, cycle 155)

Two new x402 APIs for AI agents: WebAuthn/FIDO2 ceremony decoder + S3 bucket public-read probe

Cycle 155 adds two new endpoints to the x402-paid URL-metadata API at $0.0005 per call each:

• /api/webauthn-ceremony-trace — WebAuthn/FIDO2 ceremony decoder + validator
• /api/cloud-s3-bucket-exposure — AWS S3 bucket public-read ACL + listability probe

Both ship with full FLAW-grade scoring (A-F, 0-100), distinct from anything else in the 224-route catalog.

/api/webauthn-ceremony-trace — FIDO2 ceremony decoder that any AI agent debugging a passkey deployment can call

WebAuthn ceremonies encode a credential into an opaque base64url payload that looks like three random strings. The reality is more structured: per RFC 9052 + the W3C WebAuthn spec, every webauthn.create and webauthn.get ceremony is a CBOR-encoded protocol message with named fields a relying-party backend MUST validate. An AI agent auditing a "passkey-enabled" deployment needs to decode and check those fields — that's what this endpoint does.

Input: a URL-safe-base64-encoded clientDataJSON plus an attestationObject (register) or authenticatorData (assertion), and any combination of expected_challenge, expected_origin, expected_rp_id to validate against.

What it decodes:

• client_data — type / challenge / origin + whether origin matches W3C's "no /webauthn prefix" rule
• auth_data — 32-byte rpIdHash + 1-byte flags (UP/UV/BE/BS/AT/ED) + 4-byte signCount + decoded extensions map
• aaguid_info — the 16-byte authenticator AAGUID looked up against a 14-vendor catalog (Yubico YubiKey 5 Series, Yubico Security Key, Google Titan v1+v2, Feitian K9 + iePass FIDO, SoloKey Solo 2, Apple Passkey/iCloud Keychain, Windows Hello TPM + Software, OnePlus BLE Authenticator, OnePlus Platform Authenticator, HyperFIDO Pro) + flags the all-zeros AAGUID as a test credential
• credential_id_hex + credential_id_len_bytes (flags >1023 byte credential IDs that violate the FIDO2 length bound)
• public_key — COSE-decoded credentialPublicKey with kty/alg/crv_or_named_curve/x/y fields for EC2 + n/e for RSA + x/y/ed_d for OKP (the three WebAuthn credential-key families)
• attestation — attStmt parsed per fmt (none / packed / fido-u2f / android-key / apple / tpm) with alg + sig + x5c_cert_count surfaced
• validations — rpIdHash_match (does the credential attest to the RP the caller expects?), origin_match, challenge_match, uv_implies_up (UV=1 with UP=0 = invalid per W3C §6.1), backup_consistency (BS=1 with BE=0 = invalid per FIDO2 §4.1), ext_data_consistent, overall_valid
• findings + webauthn_ceremony_score 0-100 A-F + verdict (correctly_attested / correctly_asserted / well_formed_but_invalid / rp_id_mismatch / challenge_mismatch / origin_mismatch / missing_user_presence / insecure_aaguid)

Distinct from any other endpoint in the catalog: /api/auth-scheme-discovery (c87) detects that a target uses WebAuthn but does not parse the ceremony contents. /api/jwt-* endpoints are JWT forensics. This is the only endpoint that decodes the raw binary ceremony the way a relying-party backend MUST in order to detect WebAuthn-class attacks.

Use case for AI agents: debug a webauthn.create/webauthn.get failure on a customer site, verify a credential is bound to the expected RP ID, audit a "passkey-enabled" deployment, or catch the easy-to-miss rpIdHash mismatch (a credential registered against auth.example.com being used against example.com is a cross-origin auth bypass waiting to happen).

/api/cloud-s3-bucket-exposure — anonymous probe of every conventional bucket name for the target domain

The classic cloud-misconfiguration: a company's "backup" or "staging" or "prod-data" S3 bucket, named after the company in some obvious way, with public-list ACL enabled. This has driven a decade of high-profile breaches. An AI agent auditing a web application deployment for this exact misconfiguration needs a tool to enumerate the candidate bucket namespace and probe each anonymously. That's this endpoint.

Input: ?domain=<DOMAIN> (or ?url=https://<DOMAIN> with scheme prefix).

What it does:

1. Resolves the target domain and derives 8 conventional bucket-name candidates in priority order: <apex> (e.g. stripe for stripe.com), <domain-with-hyphens> (stripe-com via dot-to-hyphen), <apex>-backup, <apex>-backups, <apex>-prod, <apex>-staging, <apex>-dev, <apex>-assets.
2. For each candidate, opens an anonymous GET against https://<bucket>.s3.amazonaws.com/?list-type=2 — no AWS credentials whatsoever; the public S3 list-object API.
3. Parses the response to detect five distinct outcomes per candidate:
   • 404 NoSuchBucket — the bucket does not exist (clean)
   • 200 + <Contents> XML elements — the bucket is publicly LISTABLE by anyone on the public Internet (CRITICAL exposure — anybody can enumerate the keys)
   • 200 + empty body — the bucket exists but a bucket-policy blocks ListObject (moderate risk)
   • 403 AccessDenied — the bucket exists but ACL is private (only the owner can ListObject — low risk)
   • 301/307 redirect — the bucket exists in a different region; the endpoint follows up with a region-specific probe to https://<bucket>.s3.<region>.amazonaws.com/?list-type=2
4. Returns per-probe records (aws_bucket / probe_url / status_code / is_404_no_such_bucket / is_listable / is_access_denied / is_redirect_to_region / region_hint / bucket_owner_header / body_preview_first_240, optional region_followup) + aggregate (any_listable / any_access_denied / any_exists) + findings[] + s3_bucket_exposure_score 0-100 A-F + verdict (clean / low_risk / moderate_risk / publicly_listable).

Distinct from any other endpoint: /api/subdomain-enum (c68) hostsearches via HackerTarget for subdomain enumeration but does not probe S3. There is no other endpoint that enumerates the S3 bucket namespace on behalf of a target domain.

Both endpoints follow the standard $0.0005-per-call x402 pricing pattern

Both endpoints are paid via x402 USDC on Base. The settlement path goes through pay.openfacilitator.io (real facilitator, not a stub). Bogus X-PAYMENT headers are rejected with x402 payment settlement failed: malformed_payment_header: ... from the live facilitator — the c85 paywall integrity is preserved.

Try them

Endpoint catalog is at /.well-known/x402 (224 endpoints as of cycle 155). The full human-readable catalog is at /, the OpenAPI 3 spec is at /openapi.json (221 paths), and the AI-agent-friendly flat list is at /llms.txt.

Both endpoints ship in the same release cycle. The WebAuthn decoder is the only FIDO2 ceremony tool in this x402 catalog; the S3 bucket probe fills the longstanding gap that any auditor/agent needs a fast one-call S3-misconfiguration check for. Together they round out the auth-attack-surface and cloud-misconfiguration rows in the catalog.