ERC-8128: Signed HTTP Requests with Ethereum

jacopo-eth · January 19, 2026, 10:22pm

Discussion for ERC-8128: Signed HTTP Requests with Ethereum — a standard for authenticating generic HTTP requests using Ethereum accounts via HTTP Message Signatures.

github.com/ethereum/ERCs

Add ERC: Signed HTTP Requests with Ethereum

master ← slice-so:temp-eth-http-message-signatures

opened 05:16PM - 16 Jan 26 UTC

jacopo-eth

+524 -0

ERC-8128 defines a standard for signing HTTP requests with Ethereum accounts. Bu…ilt on RFC 9421 (HTTP Message Signatures), each request carries a cryptographic proof bound to its content — stronger than API keys or sessions, which can be stolen and reused. The client defines the security posture, and compliant verifiers always accept the strictest stance, allowing clients to never weaken their guarantees. Request-binding and non-replayability provide flexibility for both high-security operations and high-performance scenarios, with granular control over what each signature authorizes.

A list of open questions can be found below. Feel free to join the Telegram group for more synchronous discussions.

Open Questions

Keyid format

`keyid` is used as the primary identity binding, encoded as erc8128:<chainId>:<address>. The erc8128 namespace intentionally reuses the CAIP-10 (eip155) account identifier syntax and semantics, but with a distinct prefix to make signatures explicitly scoped to this specification. A design question remains whether keyid alone is sufficient to express the signer’s intent to be verified under this ERC’s rules, or whether an explicit discriminator (e.g., a tag field or a dedicated signature parameter) should be standardized to remove ambiguity and make verification semantics opt-in.

An alternative under discussion is adopting eip155:<chainId>:<address> as the primary identity binding in order to reuse the existing EIP-155 namespace. This would avoid introducing a new prefix, but at the cost of increased semantic ambiguity, since eip155 does not inherently scope signatures to this specification.

The second preferred option is erc8128;eip155:<chainId>:<address> which avoids ambiguity and reuses the canonical address format, at the cost of a more verbose syntax.

Future-proofing for alternative EOA signing algorithms

It is plausible that future Ethereum account models may allow EOAs authenticated by algorithms other than ECDSA over secp256k1 (e.g., P-256).

Supporting this in HTTP signatures would require:

a standard mechanism to derive or bind an Ethereum address from signatures produced under additional algorithms, and
a way for verifiers to determine which algorithm is used, currently inferred from keyid.

The former is out of scope and would require a separate proposal. The latter interacts with algorithm signaling: RFC 9421 requires that any algorithm hints (e.g., alg) be consistent with trusted configuration and/or key material, and that verifiers fail verification if conflicting sources are present, in order to prevent algorithm confusion attacks.

The open question is whether potential multi-algorithm EOAs can be supported safely, without weakening the default behavior inferred from keyid or requiring out-of-band agreement between signers and verifiers. One option considered is to:

introduce a dedicated keyid namespace for multi-algorithm EOAs, e.g. erc8128-multi:<chainId>:<address>, which explicitly signals to verifiers that additional parameters must be resolved, and
standardize the deployment of a smart contract on each <chainId> that acts as an on-chain registry, allowing signers to associate signature-related parameters (e.g., alg, public key material) with their keyid, and enabling verifiers to retrieve these parameters as part of the verification process.

Optional fallback headers

Some HTTP environments make it difficult to preserve Structured Fields exactly (e.g., legacy gateways, restrictive middleware, or limited client stacks).

An open question is whether optional fallback headers (specific to Ethereum-signed HTTP messages) that carry the same information as Signature-Input / Signature should be defined, in order to improve deployability in constrained environments. The tradeoff is increased surface area, potential duplication, and new normalization rules; if introduced, fallback headers should be strictly optional and must not create multiple authoritative encodings for the same proof.

Replay protection as a compliance requirement

Strict non-replayability requires verifiers to enforce nonce uniqueness, which introduces statefulness and additional infrastructure. This ensures that each signed request represents a single-use authorization, aligning with ERC-8128’s goal of providing strong, unambiguous security guarantees.

However, this requirement may limit deployability in stateless or horizontally scaled environments where maintaining a replay cache is operationally burdensome.

One open consideration is whether strict nonce-based non-replayability should remain a mandatory requirement for verifier compliance, or whether verifiers that rely solely on request expiry and binding—without enforcing nonce uniqueness—could still be considered compliant under an explicitly defined lower security profile, with clearly understood tradeoffs in replay protection guarantees.

Allowing a lower security profile introduces risks of security ambiguity and silent downgrade, where clients or integrators may assume stronger replay protection guarantees than are actually enforced. This can lead to systemic vulnerabilities and weaker security practices, as historically many incidents have resulted from optional protections being treated as implicit or universal guarantees rather than explicitly defined security properties.