Replace http-message-sig with fetch-message-signatures in the web-bot-auth package - #122
Replace http-message-sig with fetch-message-signatures in the web-bot-auth package#122panva wants to merge 2 commits into
Conversation
The packages/http-message-sig package is unchanged, and is still built, tested and published from this repo. This is a breaking change for consumers of web-bot-auth. Signer is now a key identifier paired with a signer factory rather than a sign callback, and verify() takes a verifier factory in place of Verify<T>, which is removed along with SignerSync, SignOptions and SignSyncOptions. Directory.schema becomes optional. Every other export keeps its name, including signatureHeadersSync, directoryResponseHeaders, MediaType, Tag and HTTP_MESSAGE_SIGNATURES_DIRECTORY. One behaviour changes. RSA keys are validated for their digest as well as their algorithm, so verifier() rejects an RSA-PSS key created for SHA-256 rather than verifying with SHA-256 under a signature naming rsa-pss-sha512. Covered component matching is unchanged: both rules still match a field or derived component name whatever parameters the identifier carries. signatureHeadersSync composes createSignatureBase() and createSignatureFields(), neither of which returns a Promise. The IETF draft vectors now assert its Signature-Input byte for byte alongside the asynchronous path.
fetch-message-signatures exports the Structured Fields parser RFC 9421 is built on, so the separate structured-headers dependency is no longer needed here. packages/http-message-sig keeps its own. Values come back tagged rather than as raw JavaScript, so discoveryType reads a Token's text instead of relying on String() to produce it.
|
Thanks for the PR. I checked a few cases, and this looks useful for addressing rough edges in My main question is long-term maintenance. Keeping the RFC 9421 implementation in this repository preserves change control and avoids another external dependency. On the other hand, consolidating on a well-maintained ecosystem package avoids duplicating effort. I’m happy to help maintain or contribute to that package if we take this route (some of the changes from the below commit for instance). For this change, I think preserving as much of the existing API as possible while improving correctness is important. I pushed an additional commit on top of your branch: I can’t open a PR targeting your fork’s branch, but the commit can be cherry-picked or stacked onto this PR. |
|
@thibmeu you can push directly to this repo's PR head. I'm on PTO so feel free to do whatever you feel is best for web-bot-auth. As I said I used it merely to validate my API and identify gaps. I'll be test driving the module some more after PTO and then call it 1.0 stable |
2 participants
@thibmeu 👋
I built fetch-message-signatures over the course of IETF 126 and finally wrapped it up today, an RFC 9421 implementation built for the Fetch API until it maybe one day supports it natively.
I ported
packages/web-bot-authonto it to test my own API against a real consumer. Opening the result here in case it's useful. If you'd rather keep your own implementation, feel free to close.Only
packages/web-bot-authchanges, I didn't touchpackages/http-message-sig. It also dropsstructured-headers, because the RFC 9651 parser comes fromfetch-message-signaturestoo.Two commits: the swap, then the
Signature-Agentparsing separately.Breaking for consumers:
Signeris now a key id plus a signer factory instead of a sign callback, andverify()takes a verifier factory instead ofVerify<T>.Verify<T>,SignerSync,SignOptionsandSignSyncOptionsare gone, andDirectory.schemais optional. Everything else keeps its name.Fixes: RSA keys are checked for their digest as well as their algorithm, so
verifier()rejects an RSA-PSS key made for SHA-256 rather than verifying with SHA-256 under a signature that saysrsa-pss-sha512.