Intent to apply: RFC 9421 HTTP Message Signatures library for TypeScript, seeking feedback on scope

[Dprof-in-tech]

Hi all,

I'm planning to apply for the RFC 9421 HTTP Message Signatures library track for TypeScript ($5,000). Before I formally submit, I want to put the scope in front of this community for a quick check, specifically from anyone who has worked with the Open Payments TypeScript SDK or the @interledger/http-signature-utils package.

About me
I'm Isaac Ugwu, a software and AI engineer based in Enugu, Nigeria. I currently work at Paycrest, building payment protocol infrastructure using stablecoins. Before that I contributed to open-source projects across Starknet, Stellar, and Aztec ecosystems through OnlyDust, where most of my work involved TypeScript and protocol-level integrations. I have first-hand experience with Ed25519 key signing from building on Starknet (which uses it natively), and I have worked on ZK-proof-based financial applications including a cross-chain bridge and a p2p lending protocol. My GitHub is dprof-in-tech.

The gap I see
The Open Payments ecosystem currently has @interledger/http-signature-utils, which is tightly coupled to the Node.js SDK. There is no:

Standalone, installable TypeScript package that implements RFC 9421 as a clean, reusable primitive
Browser-compatible implementation (the existing utils are Node-only due to crypto module dependencies)
ESM-native package with full TypeScript types, usable by both SDK generators like Kiota and application developers directly

The goal isn't to replace the existing utils, it's to provide a lower-level, dependency-free building block that the ecosystem (including future Kiota-generated SDKs) can compose from.

What I propose to build
A TypeScript package (http-message-signatures) that implements RFC 9421 signing and verification, scoped strictly to the IANA-registered algorithm set per the grant program's guidance. Concretely:

Signature base construction, canonical serialization of covered components per RFC 9421 §2, including derived components (@method, @target-uri, @path, @query, @status)
Signing: Ed25519 primary target (Open Payments requirement), with ECDSA-P256 and HMAC-SHA256 also supported as they are IANA-registered

Verification: full verify path including created/expires timestamp enforcement
Signature-Input and Signature header serialization/parsing
Browser + Node.js dual compatibility via the Web Crypto API (SubtleCrypto) as the cryptographic backend

Full RFC 9421 test vector coverage: the spec includes appendix test vectors; I will implement these as a CI test suite so any deviation from the spec fails the build

Deliberately out of scope

GNAP protocol handling: separate grant track
Post-quantum algorithms: not yet in the IANA HTTP Signature Algorithms registry
Python implementation: I may apply separately for this after the TypeScript library ships

One question for the community
@interledger/http-signature-utils currently uses Node's built-in crypto module directly. Is there appetite in the Open Payments team for a browser-compatible replacement, or does the current Node-only constraint reflect an intentional architecture decision I should be aware of before designing around it?

Happy to adjust scope or deliverables based on feedback. Full Submittable application is drafted and ready to go once I've heard from this community.
cc @jeremiahlee

[jeremiahlee]

The Interledger Foundation is aware of @interledger/http-signature-utils's limitations. You raised a valid point that is an example of the motivation for the SDK Grant. The Interledger Foundation hopes to not need to create and maintain bespoke SDKs in the future.

Applicants proposing a software library implementing RFC 9421 should evaluate existing maintained libraries for their suitability for use with Kiota.

While that website lists it as Node.js, Cloudflare's http-message-sig library appears to be decoupled from Node.js enough to work with Cloudflare Workers, is written in TypeScript, and uses ESM.