]> RuleMesh

Stockholm Sweden lawrance.ny@rulemesh.com

Applications and Real-Time Individual Submission compliance authorization HTTP authentication JWT verifiable credentials trust registry This document specifies the HTTP Compliance Authorization Protocol (HCAP), an extension to the HTTP authentication framework that allows resource providers to require demonstrable evidence of caller compliance with declared policies before granting access to protected resources. Callers obtain signed compliance credentials from a compliance registry by presenting evidence of their controls. Credentials are conveyed at the HTTP layer and verified offline by the provider. HCAP operates alongside existing authentication schemes (OAuth 2.0, mTLS) and does not replace identity authentication. It addresses the distinct question of "does the caller meet declared policy requirements" rather than "who is the caller".

Introduction

Motivation Compliance verification between API providers and API callers is today conducted almost entirely out-of-band: vendor questionnaires, bilateral Data Processing Agreements, emailed SOC 2 reports, annual audits, and security reviews. Verification happens at contract time, not at request time. The evidence is prose, not machine-readable. The result is that every API integration requiring regulatory or contractual compliance carries substantial per-pair overhead, and a provider has no runtime signal that a specific caller actually meets the policies they claimed to meet when the relationship was established. HCAP moves compliance verification to the HTTP layer. A provider declares, per endpoint, what ruleset a caller MUST satisfy. A caller obtains a signed Compliance Credential from a Compliance Registry by presenting evidence of the required controls. The caller then presents the credential on subsequent requests. The provider verifies the credential's signature using the Registry's published trust anchors and checks that the credential's claims satisfy the declared ruleset. This allows compliance to be:

• Declarative: Providers publish their requirements in a machine-readable form rather than distributing prose policies.
• Portable: A caller's credential is valid with any provider that trusts the same Registry and ruleset.
• Runtime-verifiable: Verification occurs on each request, not once at contract signing.
• Offline-verifiable: Trust anchor distribution allows signature verification without per-request calls to the Registry.

Non-Goals This specification does not:

• Define what constitutes acceptable evidence for any specific ruleset.
• Mandate a specific evidence schema, compliance ontology, or legal framework.
• Govern liability, enforceability, or regulator recognition of Compliance Credentials.
• Replace identity authentication. A caller MUST still authenticate using an existing scheme.

Relationship to Existing Specifications HCAP extends by defining a new HTTP Authentication Scheme. It reuses JSON Web Tokens for credential encoding, following best current practice. Credential semantics align with the W3C Verifiable Credentials Data Model . Trust anchors are published as JSON Web Key Sets . Well-known URIs follow . HCAP is complementary to OAuth 2.0 and Rich Authorization Requests , which govern what a principal is authorized to do. HCAP governs what policy requirements the principal's operating environment satisfies.

Protocol Scope and Registry Governance This document specifies the wire protocol, data formats, and verification procedures for HCAP. It deliberately does not address the operational, procedural, or governance requirements for entities operating as Compliance Registries. How a Registry establishes the truth of the facts it attests to is a governance problem of substantially different character from the protocol problem, and conflating the two would impair adoption of either. Registry operational requirements are expected to be addressed in separate documents, which may take the form of industry operational baselines (analogous to the CA/Browser Forum Baseline Requirements ), regulator-recognized accreditation schemes (such as the eIDAS qualified trust service provider framework ), or domain-specific profiles. Implementations that adopt this specification remain free to accept credentials from any Registry whose trust anchors they choose to trust, and to apply any additional operational criteria beyond those defined here.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Caller:

The HTTP client attempting to access a protected resource.

Provider:

The HTTP origin server that protects the resource.

Registry:

A trust service that issues Compliance Credentials on behalf of Callers. This specification does not privilege any particular Registry operator. Any entity whose signing keys are published as a trust anchor () and whose credentials meet the verification requirements of MAY operate as a Registry. Registry operational obligations are out of scope for this document ().

Ruleset:

A named, versioned set of compliance requirements, identified by a URI and described by a Ruleset Manifest ().

Claim:

An individual requirement within a Ruleset, identified by a short string (e.g., art32, dpa, encryption_at_rest).

Compliance Credential:

A signed attestation by a Registry that a specific Caller satisfies a specific set of Claims against a specific Ruleset at a specific time.

Presentation:

A Compliance Credential as it appears on an HTTP request, transmitted via the Compliance-Presentation header ().

Trust Anchor:

A Registry's public signing key, published as a JSON Web Key Set and retrievable via a jwks_uri.

Evidence Tier:

A Registry-declared assurance level for the evidence underlying a Compliance Credential. Defined tiers are discussed in .

Protocol Overview The HCAP flow has three participants: the Caller, the Registry, and the Provider. A typical interaction proceeds as follows:

1. The Caller sends a request to the Provider's protected resource.
2. The Provider responds with 401 Unauthorized and a WWW-Authenticate: Compliance challenge naming the required Ruleset and Claims.
3. The Caller obtains the Ruleset Manifest (typically cached from a prior interaction) and presents evidence of the required controls to the Registry.
4. The Registry issues a signed Compliance Credential to the Caller.
5. The Caller retries the original request with the credential in the Compliance-Presentation header.
6. The Provider verifies the credential's signature using cached trust anchors and checks that its Claims satisfy the declared Ruleset.
7. The Provider serves the protected resource.

Steps 3 and 4 are typically executed ahead of time and the resulting credential is reused until it expires. The Caller SHOULD NOT perform a Registry round-trip on every protected request.

Ruleset Discovery

Well-Known URI A Provider implementing HCAP SHOULD publish a Ruleset Manifest at the well-known URI /.well-known/compliance, registered per . A Provider MAY publish multiple manifests at distinct paths under this namespace, e.g., /.well-known/compliance/customers. A Provider MAY reference a specific manifest from a challenge using the ruleset parameter (). When no explicit URI is given, the Caller resolves the manifest from the challenge's realm and the default well-known path.

Ruleset Manifest A Ruleset Manifest is a JSON document with the media type application/compliance-manifest+json. The manifest MUST contain the following fields:

• ruleset_id: URI, the canonical identifier for this ruleset.
• version: Semantic version string.
• authority: URI or DID identifying the issuer of the ruleset definition (distinct from the Registry that signs credentials against it).
• claims: An array of Claim definitions, each with id, description, and OPTIONAL references to external normative texts (e.g., specific GDPR articles).
• trust_anchors: An array of jwks_uri values identifying Registries whose credentials the Provider will accept.
• endpoints: An array of endpoint rules (see ).

The manifest MAY include accepted_equivalents, an array of other Ruleset URIs whose credentials the Provider will also accept for this Ruleset. Equivalence is always declared by the Provider; a Caller MUST NOT assume two Rulesets are equivalent absent such a declaration.

Endpoint Rules Each entry in endpoints declares which requests require which Claims:

• path_pattern: String, using the pattern syntax of .
• methods: Array of HTTP methods this rule applies to.
• required_claims: Array of Claim IDs from this Ruleset.
• required_evidence_tier: OPTIONAL minimum Evidence Tier.

When multiple endpoint rules match a request, the Provider MUST require the union of their Claims.

Caching Ruleset Manifests SHOULD be served with Cache-Control and ETag headers. Callers SHOULD cache manifests for the duration indicated by max-age. When no directive is present, Callers MAY cache for up to 24 hours.

The Compliance Challenge

Status Code A Provider MUST return 401 Unauthorized when a request requires a Compliance Credential and no valid Compliance-Presentation is present. A Provider MUST return 403 Forbidden when a valid Presentation is provided but it does not satisfy the required Ruleset.

The Compliance Authentication Scheme HCAP defines a new HTTP Authentication Scheme named Compliance. A challenge has the form: A Provider MAY include a Compliance challenge alongside other authentication challenges (e.g., Bearer). In this case the Caller MUST satisfy all required schemes.

Parameters The Compliance scheme defines the following parameters:

• realm (REQUIRED): As defined in .
• ruleset (REQUIRED): URI identifying the required Ruleset.
• claims (OPTIONAL): Space-separated list of Claim IDs overriding the Ruleset manifest's endpoint rules for this response.
• trust_anchors (OPTIONAL): Space-separated list of jwks_uri values identifying acceptable Registries. If omitted, the Provider accepts any Registry listed in the Ruleset Manifest.
• max_age (OPTIONAL): Maximum credential age in seconds that the Provider will accept, measured from the credential's iat.
• error (OPTIONAL): Error code from .
• error_description (OPTIONAL): Human-readable error detail. MUST NOT be relied upon by automated clients.

Credential Acquisition The protocol between a Caller and a Registry is out of scope for this specification. Registries MAY define their own acquisition APIs. This section describes the minimum contract that any Registry protocol MUST satisfy.

Inputs A Caller supplies, at minimum:

• A Caller identifier (typically the same sub used in the Caller's identity authentication against the Provider).
• The target Ruleset URI.
• Evidence sufficient to establish each required Claim. The form of evidence is determined by the Registry and MAY include self-attestations, signed statements from authorized personnel, third-party audit reports, cryptographic attestations of system state, or other artifacts.

Outputs On successful evaluation, the Registry issues a Compliance Credential (). The Registry MUST NOT issue credentials for Claims whose evidence it has not evaluated.

Lifetime A Registry SHOULD issue credentials with the shortest lifetime operationally practical. A lifetime of 1 hour is RECOMMENDED for typical deployments. Credentials MUST NOT have a lifetime exceeding 24 hours unless the Registry also publishes a revocation status endpoint ().

Credential Presentation

The Compliance-Presentation Header A Caller presents a Compliance Credential by including the Compliance-Presentation header field on the request: ]]> The <token> value is the JWT encoding of the credential as defined in . The Compliance-Presentation header is independent of the Authorization header. A request MAY include both, and typically does: Authorization conveys identity; Compliance-Presentation conveys policy satisfaction.

Multiple Credentials A Caller MAY present multiple credentials on a single request when the required Claims span multiple Rulesets or Registries. In this case the header value is a comma-separated list of tokens: , ]]> The Provider MUST consider the union of claims_satisfied across all valid credentials when evaluating the request.

Caching Callers SHOULD cache credentials and reuse them across requests until expiry. Callers SHOULD NOT include credentials on requests to origins for which no challenge has been received.

Credential Format

Encoding A Compliance Credential is encoded as a JSON Web Token per , signed using an algorithm from . Registries MUST use an asymmetric signature algorithm; EdDSA and ES256 are RECOMMENDED. The credential payload MAY be expressed as a Verifiable Credential using the JWT binding, with a vc claim containing the VC document. Implementations that do not require W3C VC interoperability MAY omit the vc claim and use the flat JWT claim set defined below.

Claim Set A Compliance Credential MUST contain the following claims:

• iss: URI identifying the Registry.
• sub: Caller identifier. Providers MUST verify this matches the subject of the Caller's identity authentication.
• aud: Ruleset URI, or an array including the Ruleset URI and OPTIONAL Provider identifier.
• iat: Issuance time (seconds since epoch).
• exp: Expiration time.
• jti: Unique credential identifier. Used for revocation tracking.
• ruleset: Ruleset URI this credential satisfies.
• claims_satisfied: Array of Claim IDs the Registry attests the Caller meets.

A Compliance Credential MAY contain:

• evidence_tier: String indicating evidence strength. Defined values:
  • self_attested: Caller-signed statement, no Registry verification of underlying facts.
  • attested_by_officer: Statement signed by a named authorized individual at the Caller (e.g., DPO, CISO).
  • third_party_audit: Underlying evidence is a dated attestation by an independent auditor.
  • cryptographic_proof: Underlying evidence is a cryptographic attestation of system state (e.g., TPM quote, TEE report).
• status: URI of a Status List entry for revocation.
• cnf: Confirmation claim binding the credential to a key held by the Caller, for use with proof-of-possession.

Example A decoded credential payload:

Verification Procedure On receiving a request with a Compliance-Presentation header, a Provider MUST perform the following checks, in order. If any check fails, the Provider MUST respond with 403 Forbidden and an appropriate error code ().

Signature

1. Parse the JWT.
2. Resolve the signing key from the Provider's cached trust anchors for the iss claim, refreshing from jwks_uri if the key ID is unknown.
3. Verify the signature.

A Provider MUST NOT fetch a new jwks_uri from an iss not previously declared in its Ruleset Manifest.

Temporal Validity

1. Verify exp has not passed, allowing a clock skew of at most 60 seconds.
2. Verify iat is not in the future beyond the same skew.
3. Verify the credential age (now - iat) does not exceed any max_age declared in the challenge.

Binding

1. Verify sub matches the subject of the Caller's identity authentication. Providers MUST reject credentials whose sub does not match.
2. If cnf is present, verify proof-of-possession per or equivalent.
3. Verify aud includes the Ruleset URI required by this endpoint.

Revocation If status is present, the Provider SHOULD consult the status list per . Providers MAY cache status list results for up to the credential's remaining lifetime, but SHOULD refresh on cache-miss.

Ruleset Satisfaction

1. Determine the required Ruleset and Claims for the endpoint, per .
2. Compute the set of Claims satisfied by the union of all valid credentials on the request.
3. Verify this set is a superset of the required Claims.
4. If the endpoint specifies required_evidence_tier, verify that each required Claim is satisfied by at least one credential of sufficient tier.

Equivalence If no credential directly satisfies the required Ruleset, the Provider MAY attempt to satisfy it via declared accepted_equivalents. Equivalence MUST NOT be inferred; the Provider's own manifest is authoritative.

Error Handling Errors are reported via the error parameter of the WWW-Authenticate challenge, accompanying a 401 or 403 response. The following error codes are defined:

• compliance_required: No presentation on a protected request.
• invalid_credential: Signature invalid, malformed JWT, unknown algorithm.
• expired_credential: exp has passed, or credential age exceeds max_age.
• revoked_credential: Status list indicates revocation.
• insufficient_claims: Valid credential, but required Claims not met.
• insufficient_evidence_tier: Claim satisfied but tier too low.
• unsupported_ruleset: Credential cites a Ruleset the Provider does not recognize.
• trust_anchor_unknown: iss is not among declared Registries.
• subject_mismatch: sub does not match authenticated identity.

Additional error codes MAY be defined by future specifications or extensions, following the IANA registration procedure in .

Security Considerations

Credential Theft and Replay A Compliance Credential is a bearer token in the absence of proof-of-possession. An attacker who obtains a credential can replay it until expiry. Mitigations:

• Short lifetimes () limit replay windows.
• Subject binding () ensures a stolen credential cannot be used by a different identity if identity authentication is sound.
• Providers MAY require cnf proof-of-possession for high-risk endpoints.
• Transport MUST be TLS 1.2 or later .

Registry Compromise A compromised Registry can issue fraudulent credentials. Defenses:

• Providers SHOULD pin specific Registry keys or operate against short, published key-rotation schedules.
• Registries SHOULD publish signing-key transparency logs where feasible.
• A Provider MAY operate a local override list of Registries pending investigation.

Downgrade Attacks

• A Provider MUST NOT serve a protected resource on receipt of a request that lacks a valid Presentation when its own policy requires one.
• Providers MUST NOT accept Compliance-Presentation over plaintext HTTP.
• Intermediaries MUST NOT modify, cache, or forward Compliance-Presentation headers.

Signature Algorithm Confusion Implementations MUST follow and MUST NOT accept the none algorithm. Implementations MUST verify the algorithm used against an allow-list declared in the trust anchor JWKS.

Clock Skew Verifiers MUST allow no more than 60 seconds of clock skew on temporal checks. Registries SHOULD use NTP-synchronized time.

Privacy Considerations A Compliance Credential reveals that a Caller has satisfied specific Claims with a specific Registry. This may inadvertently disclose:

• The Caller's choice of Registry, which may correlate with the Caller's jurisdiction or industry.
• The Caller's compliance posture at a point in time.
• Via evidence_tier, aspects of the Caller's audit practices.

Registries SHOULD support selective disclosure, including issuing credentials that commit to a set of Claims without revealing which subset is invoked on any given request. BBS+ signatures and related schemes building on are candidates for this mode. Providers MUST NOT log Compliance-Presentation header values in cleartext. The credential's jti MAY be logged for audit purposes.

IANA Considerations This document requests the following registrations. All registrations are subject to IETF Review.

HTTP Authentication Scheme Registration in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry":

• Scheme Name: Compliance
• Reference: This document.

HTTP Header Field Registration in the "Hypertext Transfer Protocol (HTTP) Field Name Registry":

• Field Name: Compliance-Presentation
• Status: Standard
• Reference: This document ()
• Comments: Request-only.

Well-Known URI Registration in the "Well-Known URIs" registry:

• URI Suffix: compliance
• Change Controller: IETF
• Reference: This document ()

Media Type Registration in the "Media Types" registry:

• Type Name: application
• Subtype Name: compliance-manifest+json
• Reference: This document ()

HCAP Error Code Registry Establishment of a new "HCAP Error Codes" registry with the values defined in . Registration policy: Specification Required.

HCAP Evidence Tier Registry Establishment of a new "HCAP Evidence Tiers" registry with the values defined in . Registration policy: Specification Required.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. Informative References A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion. This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet. [STANDARDS-TRACK] The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. n.d. CA/Browser Forum n.d. European Union

Examples

Full Handshake Initial request: Challenge: ; rel="compliance-requirements" ]]> Caller fetches manifest (cached after first retrieval): Caller presents evidence to Registry (out-of-band protocol) and receives a Compliance Credential. Retry with Presentation: Success:

Ruleset Manifest

Open Questions The following questions are explicitly unresolved in this draft and invite community input:

1. Registry governance. The truthfulness of the facts a Registry attests to, the operational requirements Registries must meet, and the trust framework by which Providers decide which Registries to include in their trust anchors are out of scope for this specification (). A companion document or industry operational baseline is expected to address these concerns separately. Candidate models include the CA/Browser Forum Baseline Requirements , the eIDAS qualified trust service provider framework , and domain-specific accreditation schemes.
2. Equivalence authority. Placing equivalence authority with the Provider is one option. An alternative model assigns equivalence assertions to a third-party authority (e.g., a regulator or a neutral standards body). Both models have merits; the current draft prefers provider autonomy.
3. Revocation granularity. The current design supports credential-level revocation via status lists. It does not support claim-level revocation within a credential. Whether this is needed in practice is open.
4. Selective disclosure. Whether to profile BBS+ signatures, SD-JWT, or both is unresolved.
5. Request-scoped claims. Some policies require binding between a credential and specifics of a request (e.g., "the caller may process data for EU subjects only"). The current draft does not express such binding. An extension mechanism via cnf-style request-bound confirmation claims is a candidate.

Acknowledgements The author thanks early reviewers and design partners for their feedback on the protocol shape and on the separation between protocol and Registry-governance concerns. Specific acknowledgements to be added upon submission.