An Interoperable Attestation Format for Policy-as-Code Compliance Evidence

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 9 February 2027.¶

Copyright Notice

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

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

Policy-as-code (PaC) expresses organizational, security, and regulatory rules as machine-evaluable code rather than prose. Engines such as those using the Rego language evaluate these policies against structured inputs at decision points in CI/CD pipelines, admission controllers, and runtime gateways. A single deployment may evaluate thousands of policy decisions per day.¶

Each decision produces evidence: the policy that was evaluated, the input it was evaluated against, the resulting decision, and contextual metadata such as time and evaluator identity. Auditors, downstream tools, and independent verifiers increasingly need to consume this evidence. Today it is emitted in formats that differ across engines and vendors, which prevents portable audit trails and cross-tool correlation.¶

This document analyzes the interoperability gap and describes a common attestation structure for representing PaC compliance evidence. The goal is to enable evidence to be exchanged, aggregated, and verified across otherwise incompatible tools.¶

2. Terminology

Policy decision:

The outcome of evaluating one policy against one input.¶

Attestation:

A signed or verifiable statement binding a policy decision to its evidentiary context.¶

Evidence:

The data supporting a policy decision, including the policy identity and a digest of the input.¶

Verifier:

A party that consumes attestations to confirm a decision occurred as claimed.¶

Policy Decision Point (PDP) / Policy Enforcement Point (PEP):

The components that, respectively, evaluate policy and enforce its outcome.¶

3. Requirements Language

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

4. Problem Statement

The absence of a common evidence format produces three concrete problems.¶

First, audit trails are locked to the tool that produced them. An organization that changes PaC engines cannot easily correlate historical evidence with new evidence.¶

Second, evidence cannot be aggregated across heterogeneous tools. A large environment may run several engines at different enforcement points; without a shared format, a unified compliance view requires bespoke adapters for each.¶

Third, independent verification is difficult. A third party, such as an external auditor, cannot readily confirm that a decision occurred as claimed when the evidence format is proprietary and undocumented.¶

5. Survey of Existing Approaches

Several adjacent formats inform this work without directly solving the problem. Decision logs emitted by PaC engines capture per-decision data but are engine-specific. Software supply-chain attestation frameworks bind statements to subjects and provide a useful structural analogy. Software bill-of-materials and vulnerability-exchange documents demonstrate the value of portable, machine-readable evidence in the supply-chain domain. This document draws on these patterns while focusing specifically on PaC compliance decisions.¶

6. Attestation Model

An attestation binds a policy decision to its evidentiary context. It contains, at minimum:¶

• a subject identifying what the decision concerns;¶

• a policy identity, including a version or content digest;¶

• a digest of the evaluated input, rather than the input itself, to avoid exposing sensitive data;¶

• the decision outcome;¶

• a timestamp; and¶

• the identity of the evaluating component.¶

The use of digests, rather than raw inputs, allows evidence to be shared and verified without disclosing potentially sensitive evaluation data.¶

7. Serialization Considerations

Attestations can be represented using widely deployed structured-data encodings. This document describes the model in terms of existing media types and does not define a new one. Implementations SHOULD prefer encodings that support deterministic serialization to enable reproducible digests and signatures.¶

8. Mapping to Regulatory Frameworks

The attestation model is framework-neutral but maps naturally to concrete regimes. For example, a control requirement can be expressed as one or more policies, and each evaluation produces an attestation demonstrating that the control was checked. This provides an auditable link between a regulatory obligation and the automated evidence of its enforcement.¶

9. Verification and Aggregation

A verifier consumes attestations to confirm that a claimed decision occurred. Because attestations are self-describing and reference policy and input by digest, they can be aggregated across tools into a single compliance view and independently checked without access to the original evaluation environment.¶

10. References

Appendix A. Security Considerations

Attestations assert that a policy decision occurred; their value depends on integrity and authenticity. Implementations SHOULD protect attestations against tampering and SHOULD support verification of the evaluator's identity. Because attestations reference inputs by digest, they avoid disclosing potentially sensitive evaluation data. This document describes a data model and introduces no new protocol behavior; it presents no new operational risk to the Internet.¶

Appendix B. IANA Considerations

This document requests no IANA actions.¶

Appendix C. Privacy Considerations

Evaluation inputs may contain sensitive information. For this reason the attestation model references inputs by digest rather than embedding them. Implementations SHOULD avoid placing sensitive data in attestation fields that are intended for wide distribution.¶

Appendix D. Acknowledgements

The author thanks the reviewers who contributed to this document.¶

Author's Address