From 543dbe1f45e4f742cfa1d593c763511beb03fb57 Mon Sep 17 00:00:00 2001 From: "Constantine.mirin" Date: Thu, 1 Oct 2026 19:50:13 -0400 Subject: [PATCH 001/164] Specify request signing and key directories as Web Bot Auth FORA's design goal is that every participant signs and verifies requests according to Web Bot Auth, so any WBA library interoperates. The authentication page claimed FORA was "automatically compatible" with WebBotAuth while mandating a profile no WBA library produces or accepts, and the transaction-flow and Exchange request-flow pages listed a third, contradictory covered set. The docs now specify one profile, pinned to draft-ietf-webbotauth-httpsig-protocol-00: - every request signature is a WG-00 signature: a dictionary Signature-Agent naming an https origin and covered by member, tag="web-bot-auth", a fresh 64-byte nonce, alg="ed25519"; - bodied FORA RPCs additionally cover @method, @target-uri, content-digest and authorization, advertised through Accept-Signature; - relay hops follow WG-00 section 5.2.2; - the retrieval proof of possession is a WG-00 signature that the edge still verifies offline against the key bound into the delivery URL; - key directories are served over https as application/http-message-signatures-directory+json, with a signed response; - the bare Signature-Agent value the current SDKs send is refused. JWK alg stays "EdDSA", the JOSE name RFC 7517 section 4.4 defines, which departs from WG-00 section 5.5.1; the authentication page records it as the one deliberate deviation. The SDKs and conformance vectors do not implement this profile yet; the changelog entry lists the change as upcoming. --- proto/CHANGELOG.md | 76 +++++ .../docs/components/broker/overview.mdx | 31 +- .../edge-function/signed-url-verification.mdx | 26 +- .../docs/components/exchange/multi-tenant.mdx | 2 +- .../components/exchange/request-flows.mdx | 28 +- .../docs/components/identity/overview.mdx | 8 +- .../for-exchange-operators.mdx | 6 +- .../getting-started/publisher-onboarding.mdx | 2 +- .../content/docs/protocol/authentication.mdx | 310 +++++++++++++----- .../docs/protocol/content-attestation.mdx | 2 +- .../docs/protocol/exchange-manifest.mdx | 4 +- .../docs/protocol/scenario-walkthrough.mdx | 28 +- .../docs/protocol/standards-layering.mdx | 6 +- .../docs/protocol/transaction-flow.mdx | 6 +- .../content/docs/protocol/walkthrough-v1.mdx | 2 +- .../src/content/docs/reference/changelog.mdx | 76 +++++ .../docs/reference/fora-json-example.mdx | 4 +- .../src/content/docs/reference/proto-fora.mdx | 2 +- website/src/data/standards.mjs | 4 + 19 files changed, 466 insertions(+), 157 deletions(-) diff --git a/proto/CHANGELOG.md b/proto/CHANGELOG.md index 33e8d45d..f4a2b498 100644 --- a/proto/CHANGELOG.md +++ b/proto/CHANGELOG.md @@ -1,5 +1,81 @@ # FORA Protocol Changelog +## Unreleased + +**The documentation now specifies a Web Bot Auth profile for request signatures +(docs only in this entry; the SDK and wire changes follow).** The Authentication +page said FORA was "automatically compatible" with Web Bot Auth and that "no +changes to FORA's authentication are required". That was not true. A Web Bot Auth +verifier refuses a FORA signature, and a FORA verifier refuses a signature from a +Web Bot Auth library. The pages also disagreed with each other: Transaction Flow +and the Exchange request flows said each hop covers `@method`, `@authority`, +`@path` and `Content-Digest`, while Authentication required `@method`, +`@target-uri`, `content-digest`, `authorization` and `signature-agent`. + +The target is draft-ietf-webbotauth-httpsig-protocol-00 (1 September 2026), the +only document the IETF webbotauth working group has adopted. Authentication now +specifies the profile in one place, and the other pages refer to it: + +- Every FORA request signature is a conformant Web Bot Auth signature. + `Signature-Agent` is a structured-field dictionary, `