> ## Documentation Index
> Fetch the complete documentation index at: https://docs.algovoi.co.uk/llms.txt
> Use this file to discover all available pages before exploring further.

# Key-Credential Binding for RFC 9421 Agent Requests

> Bind an RFC 9421 HTTP message signature to an issued agent credential: conformance vectors and reference verifiers (Python and TypeScript) for key anchoring, scope, and revocation checks.

**algovoi-key-credential-binding** pins the layer RFC 9421 leaves open: the
signature proves a request was signed by the holder of *a* key, but not which
issued credential that key belongs to, nor that the request is within the
credential's authorized scope. Every issuer and verifier maps `keyid` to a
credential differently, or not at all. This package makes the missing layer
testable, as conformance vectors plus reference verifiers, so implementations
can converge on one behavior.

* **PyPI**: [`pip install algovoi-key-credential-binding`](https://pypi.org/project/algovoi-key-credential-binding/) (0.1.2)
* **npm**: [`@algovoi/key-credential-binding`](https://www.npmjs.com/package/@algovoi/key-credential-binding) (0.1.1)
* **Self-hosted index**: `pip install --index-url https://pip.algovoi.co.uk/simple/ algovoi-key-credential-binding`
* **Source**: monorepo package, vectors shared across Python and TypeScript;
  builds on [rfc9421-verifier](/rfc9421-verifier) and
  [rfc9421-signer](/rfc9421-signer).

## Security advisory: scope bypass fixed in 0.1.2 / 0.1.1

Versions before Python 0.1.2 and npm 0.1.1 matched credential scope path
prefixes with a raw string prefix test (CWE-863, incorrect authorization). A
credential scoped to `/v1/binding-receipts` also admitted sibling resources
such as `/v1/binding-receipts-evil`. Fixed releases match prefixes only at a
path-segment boundary (`path == prefix` or `path.startswith(prefix + "/")`).

Affected: Python 0.1.0 and 0.1.1, npm 0.1.0 (now deprecated on the registry).
Fixed: Python 0.1.2, npm 0.1.1. Upgrade directly; the verifier API is
unchanged. The regression is locked by security probe S4 and conformance
vector `kcb-v1-009`/`kcb-v1-005` coverage in both languages.

## The four checks

A bound request is verified along four independent dimensions:

| Check              | Meaning                                                                                                                                                                                                |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `key_anchored`     | The signature-input `keyid` resolves to a key enrolled in the presented credential, through a verifier-controlled registry. The public key comes from the credential, never from the request artifact. |
| `signature_valid`  | The raw RFC 9421 + RFC 9530 signature verifies against the credential-resolved public key.                                                                                                             |
| `scope_valid`      | The request method and path fall within the credential's declared scope. Path prefixes match only at path-segment boundaries.                                                                          |
| `credential_valid` | The credential is active (not revoked) and the signed `created` falls within the credential validity window.                                                                                           |

`valid` holds only when all four hold. The dimensions are deliberately
separable so a failure in one is observable without collapsing into another.

## Why key material comes from the credential

`keyid` is a lookup hint into verifier-held material, not a trust-root
selector. The verifier resolves the public key from its own credential
registry; it never fetches or reads key material nominated by the signer (an
embedded key, a `jku`, or an `x5u`). A signed artifact that nominates its own
trust root can be fabricated wholesale and still verify cleanly against the
key it supplies.

Vector `kcb-v1-004` (keyid substitution) proves the point: an adversary signs
a request and spoofs an enrolled `keyid`. A binding verifier resolves the key
from the credential and rejects the forgery; a naive verifier that trusts a
key carried in the artifact accepts it. The vector generator asserts both
outcomes.

## Where it fits

Agent payment requests signed under [x402](/verifiable-x402-receipt), AP2, or
A2A all lean on HTTP message signatures for request integrity. Key-credential
binding is what turns "a valid signature" into "a valid signature by this
agent, within this credential's scope, while that credential was live", the
check a paying counterparty actually needs. It composes with
[Agent Passport](/agent-passport) credentials and the
[conformance vectors](/conformance-vectors) discipline used across the
substrate.