Disclosure Envelope Profile for Agent Action Capsules

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 30 March 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

Some Agent Action Capsule fields are, by design, digest-only: the field carries a [RFC8785] JSON-DIGEST commitment to a value, not the value itself. model_attestation.compute_attestation.agent_input_digest and .agent_output_digest ([I-D.mih-scitt-agent-action-capsule], Observation mode) are the motivating case — a producer commits to the exact agent input and output that produced an action without carrying that (potentially large, sensitive, or independently-lifecycled) content in the signed, anchored record.¶

A producer who later chooses to prove that committed content to a specific verifier needs a wire format for doing so. Sharing the raw content out-of-band already works informally, but an ad hoc format invites two failures this document exists to close: first, a viewer that renders a disclosed value without recomputing and checking its digest is asserting a match it never verified; second, a format that embeds the disclosed content inside the digest-bearing region of the Capsule itself changes the bytes that were signed, so the Capsule no longer content-addresses to its own capsule_id — the artifact silently stops being the thing that was anchored.¶

This document defines a companion wrapper, the Disclosure Envelope, that keeps the Capsule's bytes untouched and carries disclosed content as a sibling structure outside them, together with the verifier checks that recompute and compare each disclosure against its committed digest. The default posture is WITHHELD: a Disclosure Envelope with an absent or empty disclosures object is equivalent to sharing the Capsule alone, and disclosure of any one field is opt-in and independent of any other.¶

2. Conventions and Definitions

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

Disclosure Envelope:

A JSON object with a capsule member and an OPTIONAL disclosures member, as defined in Section 4.¶

Disclosable field:

A named entry in the disclosure-eligibility table (Section 4.2) pairing a disclosures member name with the Capsule field that carries its committed digest.¶

Disclosure:

The raw JSON value of one disclosable field, carried as the corresponding member of the disclosures object.¶

JSON-DIGEST:

As defined in [I-D.mih-scitt-agent-action-capsule]: the lowercase-hex SHA-256 digest of UTF8({{RFC8785}} JCS(value)). The whole JSON value is canonicalized recursively; no object-member allow-list, replacer array, or other key-filtering operation is applied at any depth. This document only applies to embedded Capsules that conform to the base profile's format-4 requirements.¶

JCS:

JSON Canonicalization Scheme per [RFC8785].¶

SHA-256:

The SHA-256 hash function per [RFC6234].¶

The terms "Capsule", "capsule_id", "Producer", and "Verifier" are as defined in [I-D.mih-scitt-agent-action-capsule].¶

3. Relationship to Selective Disclosure

[I-D.mih-scitt-agent-action-capsule-selective-disclosure] and this document both let a producer share less than the full Capsule content, but they solve different problems and share no vocabulary.¶

Selective disclosure conceals a payload field that would otherwise be carried in clear at signing time, replacing it with a salted-hash commitment in an _sd array; later disclosure reveals the concealed field and reconstructs the plain payload. The field's clear-text value was never in the signed record to begin with.¶

The Disclosure Envelope instead applies to a field that is a digest by design, unconditionally, in every Capsule that carries it — the field is never concealed, because it never carried the raw value in the first place. There is nothing to reconstruct and no _sd/_sd_alg structure; the Capsule is unmodified in both its disclosed and undisclosed states, and disclosure is a wrapper added around it, not a transformation of it.¶

The two mechanisms compose without conflict: a Capsule may simultaneously be an SD-Capsule (per the selective-disclosure profile) and be wrapped in a Disclosure Envelope (per this document). A verifier applies each mechanism's checks independently; neither mechanism's structure is visible to or interpreted by the other.¶

4. Disclosure Envelope Structure

{
  "capsule": { ... },
  "disclosures": {
    "agent_input": { ... },
    "agent_output": { ... }
  }
}

5. Verifier Checks

Verification of a Disclosure Envelope is performed in two independent phases: base Capsule verification ([I-D.mih-scitt-agent-action-capsule] §6, Class 1) over capsule alone, and Disclosure verification (Section 5.1) over the disclosures object. The two phases do not gate each other: a disclosure mismatch MUST NOT be reported as a capsule_id or Class 1 failure, and a Class 1 failure does not suppress disclosure verification. A verifier surface MUST report both results and MUST NOT conflate them — in particular, MUST NOT let a matching disclosure upgrade the Capsule's own verification status, and MUST NOT let the Capsule's own valid, anchored status be read as implying anything about a disclosure it has not itself recomputed and checked.¶

6. Security Considerations

7. IANA Considerations

This document reserves the wrapper member names capsule and disclosures (Section 4.3) and the disclosure-eligible field table (Section 4.2). Neither is a member of the Agent Action Capsule payload registries of [I-D.mih-scitt-agent-action-capsule] §12; both are wrapper-level names that are, by construction, never present in a Capsule payload. IANA is not requested to create a new registry for these members at this time. The interim registry of record is the REGISTRY.md file of the source repository of [I-D.mih-scitt-agent-action-capsule], updated to list the wrapper member names and the disclosure-eligible field table defined by this document.¶

8. Test Vectors

The following non-normative examples illustrate the mechanism. See the source repository's vectors/disclosure-envelope/pos-disclosure-envelope-match/ and vectors/disclosure-envelope/neg-disclosure-envelope-mismatch/ for frozen, machine-checked vectors covering these two cases (kept in a directory of their own, separate from the base profile's cross-language vectors/capsule/ corpus — see that directory's README).¶

{
  "capsule": { ... "agent_input_digest": "<D>" ... },
  "disclosures": { "agent_input": {"amount": "500.00"} }
}

9. References

Change Log

Since -00 (this document): initial publication.¶

Acknowledgments

The author thanks the SCITT working group for the Signed Statement and Transparency Service model this document's disclosure boundary is drawn against.¶

Author's Address