



Individual Submission                                         L. Nyakiso
Internet-Draft                                                  RuleMesh
Intended status: Standards Track                           20 April 2026
Expires: 22 October 2026


             HTTP Compliance Authorization Protocol (HCAP)
                         draft-nyakiso-hcap-00

Abstract

   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".

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 22 October 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Nyakiso                  Expires 22 October 2026                [Page 1]

Internet-Draft                    HCAP                        April 2026


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.3.  Relationship to Existing Specifications . . . . . . . . .   4
     1.4.  Protocol Scope and Registry Governance  . . . . . . . . .   4
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   5
   3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Ruleset Discovery . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Well-Known URI  . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Ruleset Manifest  . . . . . . . . . . . . . . . . . . . .   7
     4.3.  Endpoint Rules  . . . . . . . . . . . . . . . . . . . . .   7
     4.4.  Caching . . . . . . . . . . . . . . . . . . . . . . . . .   8
   5.  The Compliance Challenge  . . . . . . . . . . . . . . . . . .   8
     5.1.  Status Code . . . . . . . . . . . . . . . . . . . . . . .   8
     5.2.  The Compliance Authentication Scheme  . . . . . . . . . .   8
     5.3.  Parameters  . . . . . . . . . . . . . . . . . . . . . . .   8
   6.  Credential Acquisition  . . . . . . . . . . . . . . . . . . .   9
     6.1.  Inputs  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     6.2.  Outputs . . . . . . . . . . . . . . . . . . . . . . . . .   9
     6.3.  Lifetime  . . . . . . . . . . . . . . . . . . . . . . . .   9
   7.  Credential Presentation . . . . . . . . . . . . . . . . . . .   9
     7.1.  The Compliance-Presentation Header  . . . . . . . . . . .  10
     7.2.  Multiple Credentials  . . . . . . . . . . . . . . . . . .  10
     7.3.  Caching . . . . . . . . . . . . . . . . . . . . . . . . .  10
   8.  Credential Format . . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Encoding  . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.2.  Claim Set . . . . . . . . . . . . . . . . . . . . . . . .  11
     8.3.  Example . . . . . . . . . . . . . . . . . . . . . . . . .  12
   9.  Verification Procedure  . . . . . . . . . . . . . . . . . . .  12
     9.1.  Signature . . . . . . . . . . . . . . . . . . . . . . . .  12
     9.2.  Temporal Validity . . . . . . . . . . . . . . . . . . . .  12
     9.3.  Binding . . . . . . . . . . . . . . . . . . . . . . . . .  13
     9.4.  Revocation  . . . . . . . . . . . . . . . . . . . . . . .  13
     9.5.  Ruleset Satisfaction  . . . . . . . . . . . . . . . . . .  13
     9.6.  Equivalence . . . . . . . . . . . . . . . . . . . . . . .  13
   10. Error Handling  . . . . . . . . . . . . . . . . . . . . . . .  13
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  14



Nyakiso                  Expires 22 October 2026                [Page 2]

Internet-Draft                    HCAP                        April 2026


     11.1.  Credential Theft and Replay  . . . . . . . . . . . . . .  14
     11.2.  Registry Compromise  . . . . . . . . . . . . . . . . . .  14
     11.3.  Downgrade Attacks  . . . . . . . . . . . . . . . . . . .  15
     11.4.  Signature Algorithm Confusion  . . . . . . . . . . . . .  15
     11.5.  Clock Skew . . . . . . . . . . . . . . . . . . . . . . .  15
   12. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  15
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
     13.1.  HTTP Authentication Scheme . . . . . . . . . . . . . . .  16
     13.2.  HTTP Header Field  . . . . . . . . . . . . . . . . . . .  16
     13.3.  Well-Known URI . . . . . . . . . . . . . . . . . . . . .  16
     13.4.  Media Type . . . . . . . . . . . . . . . . . . . . . . .  16
     13.5.  HCAP Error Code Registry . . . . . . . . . . . . . . . .  17
     13.6.  HCAP Evidence Tier Registry  . . . . . . . . . . . . . .  17
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  17
     14.2.  Informative References . . . . . . . . . . . . . . . . .  18
   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  19
     A.1.  Full Handshake  . . . . . . . . . . . . . . . . . . . . .  19
     A.2.  Ruleset Manifest  . . . . . . . . . . . . . . . . . . . .  19
   Appendix B.  Open Questions . . . . . . . . . . . . . . . . . . .  21
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  21
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  21

1.  Introduction

1.1.  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:



Nyakiso                  Expires 22 October 2026                [Page 3]

Internet-Draft                    HCAP                        April 2026


   *  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.

1.2.  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.

1.3.  Relationship to Existing Specifications

   HCAP extends [RFC9110] by defining a new HTTP Authentication Scheme.
   It reuses [RFC7519] JSON Web Tokens for credential encoding,
   following [RFC8725] best current practice.  Credential semantics
   align with the W3C Verifiable Credentials Data Model [VC-DATA-MODEL].
   Trust anchors are published as JSON Web Key Sets [RFC7517].  Well-
   known URIs follow [RFC8615].

   HCAP is complementary to OAuth 2.0 [RFC6749] and Rich Authorization
   Requests [RFC9396], which govern what a principal is authorized to
   do.  HCAP governs what policy requirements the principal's operating
   environment satisfies.

1.4.  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.



Nyakiso                  Expires 22 October 2026                [Page 4]

Internet-Draft                    HCAP                        April 2026


   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 [CABF-BR]), regulator-recognized accreditation schemes
   (such as the eIDAS qualified trust service provider framework
   [EIDAS]), 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.

2.  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 [RFC2119] [RFC8174] 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 (Section 4) and whose credentials meet
      the verification requirements of Section 9 MAY operate as a
      Registry.  Registry operational obligations are out of scope for
      this document (Section 1.4).

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

   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




Nyakiso                  Expires 22 October 2026                [Page 5]

Internet-Draft                    HCAP                        April 2026


      request, transmitted via the Compliance-Presentation header
      (Section 7).

   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 Section 8.2.

3.  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.

4.  Ruleset Discovery

4.1.  Well-Known URI

   A Provider implementing HCAP SHOULD publish a Ruleset Manifest at the
   well-known URI /.well-known/compliance, registered per [RFC8615].  A
   Provider MAY publish multiple manifests at distinct paths under this
   namespace, e.g., /.well-known/compliance/customers.



Nyakiso                  Expires 22 October 2026                [Page 6]

Internet-Draft                    HCAP                        April 2026


   A Provider MAY reference a specific manifest from a challenge using
   the ruleset parameter (Section 5.3).  When no explicit URI is given,
   the Caller resolves the manifest from the challenge's realm and the
   default well-known path.

4.2.  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 Section 4.3).

   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.

4.3.  Endpoint Rules

   Each entry in endpoints declares which requests require which Claims:

   *  path_pattern: String, using the pattern syntax of [RFC6570].

   *  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.



Nyakiso                  Expires 22 October 2026                [Page 7]

Internet-Draft                    HCAP                        April 2026


4.4.  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.

5.  The Compliance Challenge

5.1.  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.

5.2.  The Compliance Authentication Scheme

   HCAP defines a new HTTP Authentication Scheme named Compliance.  A
   challenge has the form:

   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"

   A Provider MAY include a Compliance challenge alongside other
   authentication challenges (e.g., Bearer).  In this case the Caller
   MUST satisfy all required schemes.

5.3.  Parameters

   The Compliance scheme defines the following parameters:

   *  realm (REQUIRED): As defined in [RFC9110].

   *  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.



Nyakiso                  Expires 22 October 2026                [Page 8]

Internet-Draft                    HCAP                        April 2026


   *  max_age (OPTIONAL): Maximum credential age in seconds that the
      Provider will accept, measured from the credential's iat.

   *  error (OPTIONAL): Error code from Section 10.

   *  error_description (OPTIONAL): Human-readable error detail.  MUST
      NOT be relied upon by automated clients.

6.  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.

6.1.  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.

6.2.  Outputs

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

6.3.  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 (Section 9.4).

7.  Credential Presentation






Nyakiso                  Expires 22 October 2026                [Page 9]

Internet-Draft                    HCAP                        April 2026


7.1.  The Compliance-Presentation Header

   A Caller presents a Compliance Credential by including the
   Compliance-Presentation header field on the request:

   Compliance-Presentation: <token>

   The <token> value is the JWT encoding of the credential as defined in
   Section 8.

   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.

7.2.  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:

   Compliance-Presentation: <token1>, <token2>

   The Provider MUST consider the union of claims_satisfied across all
   valid credentials when evaluating the request.

7.3.  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.

8.  Credential Format

8.1.  Encoding

   A Compliance Credential is encoded as a JSON Web Token per [RFC7519],
   signed using an algorithm from [RFC7518].  Registries MUST use an
   asymmetric signature algorithm; EdDSA and ES256 are RECOMMENDED.

   The credential payload MAY be expressed as a Verifiable Credential
   [VC-DATA-MODEL] 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.






Nyakiso                  Expires 22 October 2026               [Page 10]

Internet-Draft                    HCAP                        April 2026


8.2.  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 [STATUS-LIST] entry for revocation.

   *  cnf: Confirmation claim [RFC7800] binding the credential to a key
      held by the Caller, for use with proof-of-possession.







Nyakiso                  Expires 22 October 2026               [Page 11]

Internet-Draft                    HCAP                        April 2026


8.3.  Example

   A decoded credential payload:

   {
     "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"
   }

9.  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 (Section 10).

9.1.  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.

9.2.  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.





Nyakiso                  Expires 22 October 2026               [Page 12]

Internet-Draft                    HCAP                        April 2026


   3.  Verify the credential age (now - iat) does not exceed any max_age
       declared in the challenge.

9.3.  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 [RFC9449] or
       equivalent.

   3.  Verify aud includes the Ruleset URI required by this endpoint.

9.4.  Revocation

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

9.5.  Ruleset Satisfaction

   1.  Determine the required Ruleset and Claims for the endpoint, per
       Section 4.

   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.

9.6.  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.

10.  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.



Nyakiso                  Expires 22 October 2026               [Page 13]

Internet-Draft                    HCAP                        April 2026


   *  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 Section 13.

11.  Security Considerations

11.1.  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 (Section 6.3) limit replay windows.

   *  Subject binding (Section 9.3) 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 [RFC8446].

11.2.  Registry Compromise

   A compromised Registry can issue fraudulent credentials.  Defenses:

   *  Providers SHOULD pin specific Registry keys or operate against
      short, published key-rotation schedules.



Nyakiso                  Expires 22 October 2026               [Page 14]

Internet-Draft                    HCAP                        April 2026


   *  Registries SHOULD publish signing-key transparency logs where
      feasible.

   *  A Provider MAY operate a local override list of Registries pending
      investigation.

11.3.  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.

11.4.  Signature Algorithm Confusion

   Implementations MUST follow [RFC8725] and MUST NOT accept the none
   algorithm.  Implementations MUST verify the algorithm used against an
   allow-list declared in the trust anchor JWKS.

11.5.  Clock Skew

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

12.  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 [VC-DATA-MODEL] 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.



Nyakiso                  Expires 22 October 2026               [Page 15]

Internet-Draft                    HCAP                        April 2026


13.  IANA Considerations

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

13.1.  HTTP Authentication Scheme

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

   *  Scheme Name: Compliance

   *  Reference: This document.

13.2.  HTTP Header Field

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

   *  Field Name: Compliance-Presentation

   *  Status: Standard

   *  Reference: This document (Section 7)

   *  Comments: Request-only.

13.3.  Well-Known URI

   Registration in the "Well-Known URIs" registry:

   *  URI Suffix: compliance

   *  Change Controller: IETF

   *  Reference: This document (Section 4)

13.4.  Media Type

   Registration in the "Media Types" registry:

   *  Type Name: application

   *  Subtype Name: compliance-manifest+json

   *  Reference: This document (Section 4.2)





Nyakiso                  Expires 22 October 2026               [Page 16]

Internet-Draft                    HCAP                        April 2026


13.5.  HCAP Error Code Registry

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

13.6.  HCAP Evidence Tier Registry

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

14.  References

14.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7517>.

   [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
              DOI 10.17487/RFC7518, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7518>.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7519>.

   [RFC7800]  Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
              Possession Key Semantics for JSON Web Tokens (JWTs)",
              RFC 7800, DOI 10.17487/RFC7800, April 2016,
              <https://www.rfc-editor.org/rfc/rfc7800>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/rfc/rfc8446>.

   [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
              (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
              <https://www.rfc-editor.org/rfc/rfc8615>.




Nyakiso                  Expires 22 October 2026               [Page 17]

Internet-Draft                    HCAP                        April 2026


   [RFC8725]  Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
              Current Practices", BCP 225, RFC 8725,
              DOI 10.17487/RFC8725, February 2020,
              <https://www.rfc-editor.org/rfc/rfc8725>.

   [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Semantics", STD 97, RFC 9110,
              DOI 10.17487/RFC9110, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9110>.

   [VC-DATA-MODEL]
              Sporny, M., Longley, D., and G. Cohen, "Verifiable
              Credentials Data Model v2.0", 2025,
              <https://www.w3.org/TR/vc-data-model-2.0/>.

14.2.  Informative References

   [CABF-BR]  CA/Browser Forum, "Baseline Requirements for the Issuance
              and Management of Publicly-Trusted Certificates", n.d.,
              <https://cabforum.org/baseline-requirements-documents/>.

   [EIDAS]    European Union, "Regulation (EU) No 910/2014 on electronic
              identification and trust services", 2014,
              <https://eur-lex.europa.eu/eli/reg/2014/910/oj>.

   [RFC6570]  Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
              and D. Orchard, "URI Template", RFC 6570,
              DOI 10.17487/RFC6570, March 2012,
              <https://www.rfc-editor.org/rfc/rfc6570>.

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/rfc/rfc6749>.

   [RFC9396]  Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
              Rich Authorization Requests", RFC 9396,
              DOI 10.17487/RFC9396, May 2023,
              <https://www.rfc-editor.org/rfc/rfc9396>.

   [RFC9449]  Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
              Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
              Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
              September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.

   [STATUS-LIST]
              Looker, T. and P. Bastian, "Token Status List", n.d.,
              <https://datatracker.ietf.org/doc/draft-ietf-oauth-status-
              list/>.



Nyakiso                  Expires 22 October 2026               [Page 18]

Internet-Draft                    HCAP                        April 2026


Appendix A.  Examples

A.1.  Full Handshake

   Initial request:

   GET /customers/42 HTTP/1.1
   Host: api.example.com
   Authorization: Bearer eyJhbGc...

   Challenge:

   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"

   Caller fetches manifest (cached after first retrieval):

   GET /.well-known/compliance HTTP/1.1
   Host: api.example.com
   Accept: application/compliance-manifest+json

   Caller presents evidence to Registry (out-of-band protocol) and
   receives a Compliance Credential.

   Retry with Presentation:

   GET /customers/42 HTTP/1.1
   Host: api.example.com
   Authorization: Bearer eyJhbGc...
   Compliance-Presentation: eyJhbGc...

   Success:

   HTTP/1.1 200 OK
   Content-Type: application/json

   { "id": 42, "name": "..." }

A.2.  Ruleset Manifest






Nyakiso                  Expires 22 October 2026               [Page 19]

Internet-Draft                    HCAP                        April 2026


   {
     "ruleset_id": "https://rules.example.com/gdpr-processor/v2",
     "version": "2.1.0",
     "authority": "did:web:rules.example.com",
     "claims": [
       {
         "id": "art28",
         "description": "Processor agreement in place",
         "references": [
           "https://eur-lex.europa.eu/eli/reg/2016/679#art28"
         ]
       },
       {
         "id": "art32",
         "description": "Technical and organizational measures",
         "references": [
           "https://eur-lex.europa.eu/eli/reg/2016/679#art32"
         ]
       },
       {
         "id": "dpa",
         "description": "Signed data processing agreement on file"
       }
     ],
     "trust_anchors": [
       "https://trust.example.net/.well-known/jwks.json"
     ],
     "endpoints": [
       {
         "path_pattern": "/customers/{id}",
         "methods": ["GET", "PATCH"],
         "required_claims": ["art28", "art32"],
         "required_evidence_tier": "attested_by_officer"
       },
       {
         "path_pattern": "/customers/{id}/pii",
         "methods": ["GET"],
         "required_claims": ["art28", "art32", "dpa"],
         "required_evidence_tier": "third_party_audit"
       }
     ],
     "accepted_equivalents": [
       "https://rules.example.com/ccpa-service-provider/v1"
     ]
   }






Nyakiso                  Expires 22 October 2026               [Page 20]

Internet-Draft                    HCAP                        April 2026


Appendix B.  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 (Section 1.4).  A companion document or
       industry operational baseline is expected to address these
       concerns separately.  Candidate models include the CA/Browser
       Forum Baseline Requirements [CABF-BR], the eIDAS qualified trust
       service provider framework [EIDAS], 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.

Author's Address







Nyakiso                  Expires 22 October 2026               [Page 21]

Internet-Draft                    HCAP                        April 2026


   Lawrance Nyakiso
   RuleMesh
   Stockholm
   Sweden
   Email: lawrance.ny@rulemesh.com














































Nyakiso                  Expires 22 October 2026               [Page 22]
