Companies that exchange data over APIs still check each other's compliance by questionnaire and contract, once, when the relationship starts. HCAP, the HTTP Compliance Authorization Protocol, proposes that the check happen on the request instead, using the same HTTP machinery that already carries authentication.
We published it as an individual Internet-Draft in April 2026. It is version 00, no IETF working group has adopted it, and it is open for comment. This note explains what the draft specifies, what it leaves out on purpose, and the questions it has not answered yet. The draft is the authority throughout; where this page summarises, the section numbers point to the text.
The problem the draft addresses
Compliance checks between an API provider and its callers happen out of band. A vendor questionnaire goes round by email, a data processing agreement is negotiated, a SOC 2 report is shared, and a security review takes place before the contract is signed. All of it is prose, and all of it happens once. After that, the provider has no signal at request time that a particular caller still meets the policy it described, and every new integration starts the exercise again.
HCAP moves the check onto the request (Section 1.1). A provider declares, per endpoint, which ruleset a caller must satisfy. The caller obtains a credential that says it does, and presents it. The provider verifies the signature against keys it already holds and compares the credential's claims with what the endpoint requires. Contracts and audits still take place, and the credential is where their outcome ends up, in a form a server can read on every call.
How the protocol works
Three parties take part: the caller, the provider that protects the resource, and a compliance registry that issues credentials. The draft describes the exchange in seven steps. The diagram adds the manifest fetch from Appendix A.1 as its own step.
The provider declares what it requires
A provider publishes a ruleset manifest at /.well-known/compliance, as JSON with the media type application/compliance-manifest+json (Section 4). The manifest names the ruleset and its version, the authority that defined it, the claims it contains, the registries whose credentials the provider will accept, and per-endpoint rules saying which claims each path and method requires. When several rules match one request, the provider requires the union of their claims. An excerpt from the draft's example:
{
"ruleset_id": "https://rules.example.com/gdpr-processor/v2",
"version": "2.1.0",
"authority": "did:web:rules.example.com",
"trust_anchors": [
"https://trust.example.net/.well-known/jwks.json"
],
"endpoints": [
{
"path_pattern": "/customers/{id}/pii",
"methods": ["GET"],
"required_claims": ["art28", "art32", "dpa"],
"required_evidence_tier": "third_party_audit"
}
]
}A manifest can also list accepted_equivalents, other rulesets whose credentials the provider will accept in place of this one. Equivalence is only ever what the provider declares; a caller must not assume it.
The provider challenges a caller without a credential
HCAP defines a new HTTP authentication scheme named Compliance (Section 5). A request that needs a credential and arrives without one gets a 401 with a challenge naming the ruleset and, optionally, the specific claims and acceptable registries. A request whose credential is valid but falls short gets a 403. The challenge can sit alongside an ordinary Bearer challenge, in which case the caller has to satisfy both.
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Compliance realm="api.example.com",
ruleset="https://rules.example.com/gdpr-processor/v2",
claims="art28 art32 dpa",
trust_anchors="https://trust.example.net/.well-known/jwks.json",
max_age=3600,
error="compliance_required"
Link: </.well-known/compliance>; rel="compliance-requirements"The caller obtains a credential from a registry
How a caller talks to a registry is left to each registry (Section 6). The draft sets only the minimum contract: the caller supplies an identifier, the target ruleset and evidence for each required claim, and the registry must not issue a credential for any claim whose evidence it has not evaluated. Evidence can range from a self-attestation to a third-party audit report or a cryptographic attestation of system state, and the credential records which, as an evidence tier.
self_attested: a statement signed by the caller, with no registry verification of the facts behind it.attested_by_officer: signed by a named individual at the caller, such as the DPO or CISO.third_party_audit: backed by a dated attestation from an independent auditor.cryptographic_proof: backed by an attestation of system state, such as a TPM quote or a TEE report.
Credentials are meant to be short-lived. The draft recommends one hour and caps lifetime at twenty-four hours unless the registry also publishes a revocation status endpoint. A provider can require a minimum tier per endpoint, which lets the same ruleset ask for an officer's signature on one path and an audit on another.
The caller presents it, and the provider verifies
The credential travels in its own request header, Compliance-Presentation, not in Authorization (Section 7). The two answer different questions. In the draft's words, Authorization conveys identity, and Compliance-Presentation conveys policy satisfaction. A request normally carries both.
GET /customers/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGc...
Compliance-Presentation: eyJhbGc...The credential is a JSON Web Token signed with an asymmetric algorithm, EdDSA or ES256 recommended (Section 8). It names the registry that issued it, the caller it was issued to, the ruleset, the claims satisfied, its issue and expiry times, and optionally the evidence tier, a revocation status entry and a proof-of-possession key. It can also be expressed as a W3C Verifiable Credential.
{
"iss": "https://registry.example.net",
"sub": "client_abc123",
"aud": [
"https://rules.example.com/gdpr-processor/v2",
"https://api.example.com"
],
"iat": 1713024000,
"exp": 1713027600,
"jti": "cred_7a3d91f0e2",
"ruleset": "https://rules.example.com/gdpr-processor/v2",
"claims_satisfied": ["art28", "art32", "dpa"],
"evidence_tier": "third_party_audit",
"status": "https://registry.example.net/status/12#5142"
}Verification runs in a fixed order, and any failure ends in a 403 with an error code (Sections 9 and 10). The provider checks the signature against the registry keys it has cached, refusing any issuer it has not declared. It checks the time window, allowing at most sixty seconds of clock skew and any maximum age the challenge set. It checks that the credential's subject is the same party that authenticated the request, and proof of possession where the credential is bound to a key. It consults the revocation status list when one is named. Finally it checks that the claims across all valid credentials on the request cover what the endpoint requires, at the evidence tier it requires. None of these steps needs a call to the registry on the request path, apart from a status list lookup that can be cached.
How it relates to existing standards
HCAP is built from parts that already exist (Section 1.3). It extends the HTTP authentication framework of RFC 9110, encodes credentials as JSON Web Tokens under the RFC 8725 best practices, publishes registry keys as JSON Web Key Sets, and aligns credential semantics with the W3C Verifiable Credentials Data Model. Revocation uses the OAuth Token Status List draft, and proof of possession can follow DPoP.
It sits beside OAuth rather than in place of it. OAuth 2.0 and Rich Authorization Requests govern what a principal is allowed to do. HCAP governs which policy requirements the principal's operating environment satisfies, and it still requires the caller to authenticate with an existing scheme.
What the draft leaves out on purpose
The draft specifies the wire protocol, the data formats and the verification procedure, and stops there (Sections 1.2 and 1.4). It does not define what counts as acceptable evidence for any ruleset, does not mandate an evidence schema, compliance ontology or legal framework, and does not settle liability, enforceability or whether a regulator will recognise a credential.
The largest omission is registry governance. How a registry establishes that the facts it attests to are true is a different kind of problem from the protocol, and folding the two together would slow the adoption of both. The draft expects that question to be answered in separate documents, and names the models it has in mind: an industry baseline in the manner of the CA/Browser Forum Baseline Requirements, an accreditation scheme such as the eIDAS framework for qualified trust service providers, or a profile for a particular sector. Any party whose signing keys a provider chooses to trust may operate a registry.
Security and privacy
Without proof of possession, a credential is a bearer token, and a stolen one can be replayed until it expires (Section 11). The draft's defences are short lifetimes, the binding of the credential's subject to the authenticated caller, optional key binding for high-risk endpoints, and TLS 1.2 or later on every request. Against a compromised registry, providers should pin keys or follow published rotation schedules, and registries should keep key transparency logs where they can. Intermediaries must not modify, cache or forward the presentation header, and the unsigned none algorithm is never accepted.
A credential also discloses something (Section 12): which registry the caller uses, which can hint at its jurisdiction or industry, its compliance position at a point in time, and through the evidence tier something of its audit practice. The draft asks registries to support selective disclosure, and forbids providers from logging presentation values in clear text. The credential identifier may be logged for audit.
Open questions
Appendix B lists five questions the draft leaves open, and comments on any of them are welcome.
- Registry governance. Who decides which registries a provider should trust, and what operational requirements they must meet.
- Equivalence authority. The draft lets each provider declare which rulesets it treats as equivalent. A regulator or a neutral standards body could hold that authority instead.
- Revocation granularity. Status lists revoke a whole credential. Whether single claims inside a credential need to be revocable is undecided.
- Selective disclosure. Whether to profile BBS+ signatures, SD-JWT, or both.
- Request-scoped claims. Some policies depend on the request itself, for example a caller allowed to process data only for subjects in the EU. The draft cannot express that binding yet.
Comments can go to the author at the address in the draft, [email protected].
Where RuleMesh fits
The protocol carries a claim such as art32 from a registry to a provider. It does not say what that claim requires in practice, or what evidence should support it, and it is not meant to. That question is the one RuleMesh works on. We turn regulations into requirements a team can act on, each with the article behind it and the evidence an auditor would expect, and requirements of that kind are what a ruleset's claims have to stand on before any registry can sign them.
The draft does not depend on RuleMesh, names no registry operator, and gives none a privileged position. We wrote it as an open protocol because a compliance check that works with only one vendor's service would leave providers negotiating vendor by vendor again, which is the overhead the draft sets out to remove. You can read about what RuleMesh does today on the how it works page.