Verifiable Agent Conversation Records

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

In this document, CDDL [RFC8610] is used to describe the data formats of agent conversations for JSON and CBOR (with no optimization for CBOR, currently).¶

The reader is assumed to be familiar with the vocabulary and concepts defined in [RFC9334] and [I-D.ietf-scitt-architecture].¶

2.1. Applicable Requirement Frameworks

The following frameworks were analyzed for their requirements on AI agent traceability and session logging:¶

2.2. Common Requirements Intersection

The analysis of the frameworks listed above results in eleven categories of requirements that appear across ALL or MOST frameworks. These categories frame and represent a minimum baseline that verifiable agent conversation records MUST support.¶

2.3. Framework-Specific Requirements

2.4. Compliance Mapping Table

The following table maps this specification's data elements to compliance requirements:¶

2.5. Security Requirements addressing Regulatory Compliance

2.6. Related Standards and Emerging Work

The ISO/IEC JTC 1/SC 42 committee is developing [ISO_IEC_DIS_24970], a draft international standard specifically addressing AI system logging requirements. This work aligns with and complements the verifiable agent conversation format defined in this document.¶

Research on emergent misalignment [EMERGENT_MISALIGNMENT_2025] demonstrates that narrow fine-tuning can produce broadly misaligned LLMs, underscoring the importance of comprehensive conversation logging for detecting behavioral anomalies that may not be apparent from individual interactions.¶

3.1. Common Types

The schema uses the following generic type definitions throughout.¶

abstract-timestamp:

An RFC 3339 date-time string or numeric epoch milliseconds. New implementations SHOULD use RFC 3339 strings; consumers MUST accept both forms.¶

session-id:

An opaque string uniquely identifying a conversation session. Values may be UUID v4, UUID v7, SHA-256 hashes, or other formats.¶

entry-id:

A per-entry unique reference within a session, enabling parent-child linking and tool call-result correlation.¶

3.2. The verifiable-agent-record Map

The CDDL definition for the verifiable-agent-record map is specified as follows:¶

verifiable-agent-record = {
    version: tstr
    id: tstr
    session: session-trace
    ? created: abstract-timestamp
    ? file-attribution: file-attribution-record
    ? vcs: vcs-context
    ? recording-agent: recording-agent
    * tstr => any
}

The verifiable-agent-record is the top-level container for all data produced by or about an agent conversation. It unifies two complementary perspectives: the session trace captures how code was produced (the full conversation replay), while file attribution captures what code was produced (which files were modified and by whom).¶

The following describes each member of this map.¶

version:

The schema version string following semantic versioning (e.g., "3.0.0-draft"). Consumers use this field to select the appropriate parser or validation logic.¶

id:

A unique identifier for this record, typically a UUID. Distinguishes records when multiple are stored or transmitted together.¶

session:

The full conversation trace including all entries, tool calls, reasoning steps, and system events.¶

created:

The timestamp when this record was generated. Distinct from session timestamps, which record when the conversation occurred.¶

file-attribution:

Structured data about which files were modified and which line ranges were written by the agent.¶

vcs:

Version control metadata at the record level (repository, branch, revision).¶

recording-agent:

Identifies the tool or agent that generated this record, as distinct from the agent that conducted the conversation.¶

3.3. The session-trace Map

The CDDL definition for the session-trace map is specified as follows:¶

session-trace = {
    ? format: tstr
    session-id: session-id
    ? session-start: abstract-timestamp
    ? session-end: abstract-timestamp
    agent-meta: agent-meta
    ? environment: environment
    entries: [* entry]
    * tstr => any
}

A session-trace captures the full conversation between a user and an autonomous agent. It contains an ordered array of entries representing messages, tool invocations, reasoning steps, and system events. The session-trace preserves the complete interaction history including all native agent metadata, enabling both replay and audit of the conversation.¶

The following describes each member of this map.¶

format:

Classifies the session style, such as "interactive" (human-in-the-loop) or "autonomous" (fully automated). Informative only; does not change the structure.¶

session-id:

Unique identifier for this session.¶

session-start:

When the session began.¶

session-end:

When the session ended.¶

agent-meta:

Metadata about the agent and model that conducted this conversation.¶

environment:

Execution environment context, such as working directory and version control state.¶

entries:

An ordered array of conversation entries.¶

3.4. The agent-meta Map

The CDDL definition for the agent-meta map is specified as follows:¶

agent-meta = {
    model-id: tstr
    model-provider: tstr
    ? models: [* tstr]
    ? cli-name: tstr
    ? cli-version: tstr
    * tstr => any
}

The agent-meta type identifies the coding agent and language model used during a conversation session. Agent identification is essential for provenance tracking: knowing which model produced which output enables auditing, capability assessment, and compliance verification.¶

The following describes each member of this map.¶

model-id:

The primary language model identifier, using the naming convention of the provider (e.g., "claude-opus-4-5-20251101", "gemini-2.0-flash").¶

model-provider:

The provider of the primary model (e.g., "anthropic", "google", "openai").¶

models:

List of all model identifiers used during the session. Relevant for multi-model sessions where the agent switches between models.¶

cli-name:

The name of the CLI tool or agent framework (e.g., "claude-code", "gemini-cli", "codex-cli").¶

cli-version:

The version of the CLI tool.¶

3.5. The recording-agent Map

The CDDL definition for the recording-agent map is specified as follows:¶

recording-agent = {
    name: tstr
    ? version: tstr
    * tstr => any
}

The recording-agent map identifies the tool that generated this verifiable agent record, as distinct from the agent that conducted the conversation. This distinction matters for provenance chains: the recording tool's version affects how native data is translated into the canonical CDDL data definition specified in this document.¶

The following describes each member of this map.¶

name:

The name of the recording tool or agent.¶

version:

The version of the recording tool.¶

3.6. The environment Map

The CDDL definition for the environment map is specified as follows:¶

environment = {
    working-dir: tstr
    ? vcs: vcs-context
    ? sandboxes: [* tstr]
    * tstr => any
}

The environment type captures execution context for the conversation: where the agent was running, what version control state was active, and whether sandboxing was in effect. This context is important for reproducibility and for understanding the scope of file modifications.¶

The following describes each member of this map.¶

working-dir:

The primary working directory path. File paths in tool calls are typically relative to this directory.¶

vcs:

Version control state at the time of the session (branch, revision, etc.).¶

sandboxes:

Paths to sandbox mount points. Some agents run in sandboxed environments where the working directory is a temporary mount.¶

3.7. The vcs-context Map

The CDDL definition for the vcs-context map is specified as follows:¶

vcs-context = {
    type: tstr
    ? revision: tstr
    ? branch: tstr
    ? repository: tstr
    * tstr => any
}

The vcs-context type captures version control metadata for reproducibility. Knowing the exact repository, branch, and commit at the time of a conversation enables consumers to reconstruct the codebase state and verify file attributions.¶

The following describes each member of this map.¶

type:

The version control system type (e.g., "git", "jj", "hg", "svn").¶

revision:

The commit SHA or change identifier at session time.¶

branch:

The active branch name.¶

repository:

The repository URL.¶

3.8. Entry Types

The CDDL definition specifies five entry types representing the different kinds of events in an agent conversation. Each type uses a type field as the discriminator. All entry types support optional children for hierarchical nesting and * tstr => any for preserving native agent fields that do not map to canonical fields.¶

entry = message-entry
      / tool-call-entry
      / tool-result-entry
      / reasoning-entry
      / event-entry

message-entry = {
    type: "user" / "assistant"
    ? content: any
    ? timestamp: abstract-timestamp
    ? id: entry-id
    ? model-id: tstr
    ? parent-id: entry-id
    ? token-usage: token-usage
    ? children: [* entry]
    * tstr => any
}

tool-call-entry = {
    type: "tool-call"
    name: tstr
    input: any
    ? call-id: tstr
    ? timestamp: abstract-timestamp
    ? id: entry-id
    ? children: [* entry]
    * tstr => any
}

tool-result-entry = {
    type: "tool-result"
    output: any
    ? call-id: tstr
    ? status: tstr
    ? is-error: bool
    ? timestamp: abstract-timestamp
    ? id: entry-id
    ? children: [* entry]
    * tstr => any
}

reasoning-entry = {
    type: "reasoning"
    content: any
    ? encrypted: tstr
    ? subject: tstr
    ? timestamp: abstract-timestamp
    ? id: entry-id
    ? children: [* entry]
    * tstr => any
}

event-entry = {
    type: "system-event"
    event-type: tstr
    ? data: { * tstr => any }
    ? timestamp: abstract-timestamp
    ? id: entry-id
    ? children: [* entry]
    * tstr => any
}

3.9. The token-usage Map

The CDDL definition for the token-usage map is specified as follows:¶

token-usage = {
    ? input: uint
    ? output: uint
    ? cached: uint
    ? reasoning: uint
    ? total: uint
    ? cost: number
    * tstr => any
}

The token-usage type captures token consumption metrics for a model response. Token usage data is essential for cost tracking, quota management, and understanding model behavior. All fields are optional because different agents report different subsets of token metrics.¶

Editor's Note: add a non-empty generic here¶

The following describes each member of this map.¶

input:

The number of input tokens consumed by this response.¶

output:

The number of output tokens generated.¶

cached:

The number of input tokens served from cache rather than reprocessed.¶

reasoning:

Tokens consumed by chain-of-thought or reasoning computation.¶

total:

The total token count.¶

cost:

The monetary cost in US dollars for this response.¶

3.10. File Attribution Types

NOTE: This section is specified but not yet validated against real session data. Implementation is pending.¶

File attribution captures what code was produced: which files were modified, which line ranges were changed, and who authored them.¶

file-attribution-record = {
    files: [* file]
}

file = {
    path: tstr
    conversations: [* conversation]
}

conversation = {
    ? url: tstr .regexp uri-regexp
    ? contributor: contributor
    ranges: [* range]
    ? related: [* resource]
}

range = {
    start-line: uint
    end-line: uint
    ? content-hash: tstr
    ? content-hash-alg: tstr
    ? contributor: contributor
}

contributor = {
    type: "human" / "ai" / "mixed" / "unknown"
    ? model-id: tstr
}

resource = {
    type: tstr
    url: tstr .regexp uri-regexp
}

3.11. Signing Envelope Types

The signing envelope provides cryptographic integrity protection for verifiable agent records using COSE_Sign1 ([STD96]).¶

signed-agent-record = #6.18([
    protected: bstr .cbor protected-header
    unprotected: unprotected-header
    payload: bstr / null
    signature: bstr
])

trace-metadata = {
    session-id: session-id
    agent-vendor: tstr
    trace-format: trace-format-id
    timestamp-start: abstract-timestamp
    ? timestamp-end: abstract-timestamp
    ? content-hash: tstr
    ? content-hash-alg: tstr
}

5.1. Information Disclosure

User prompts captured in message entries may contain personal identifiers, business confidential information, credentials inadvertently included in prompts, or behavioral patterns. Agent responses and reasoning traces may reveal inference results that expose information about users not explicitly provided, confidential information retrieved by tools, or system architecture details through tool names and parameters. Implementations MUST treat user-provided content as potentially containing personally identifiable information.¶

Record metadata exposes operational details that may have privacy implications. Model identifiers reveal AI capabilities, CLI versions enable targeted attacks against known vulnerabilities, working directories expose file system structure, and VCS context discloses repository names and commit timing. Token usage patterns may enable inference about conversation content even when the content itself is protected.¶

5.2. Sensitive Content in Records

Reasoning entries may contain inferences that constitute special category data, including health-related inferences from user queries, political opinions derived from conversation context, or biometric data processed by AI systems. The reasoning-entry.encrypted field reflects that some model providers encrypt chain-of-thought content; when reasoning is encrypted, audit capabilities depend on the provider's cooperation.¶

Tool inputs and outputs warrant particular attention. Tool call inputs may contain credentials, API keys, or file contents. Tool results may contain query results with personal data from databases or external services. Implementations SHOULD provide configurable redaction rules for common patterns and support selective entry type recording based on deployment requirements.¶

5.3. Retention Considerations

Multiple frameworks impose retention requirements that may conflict with data minimization principles. Organizations must balance compliance obligations requiring extended retention against privacy principles requiring timely deletion.¶

Compliant data management may require separating raw personal data from audit trail metadata, implementing automated deletion for personal data after compliance-minimum periods, and maintaining cryptographic commitments enabling verification without retaining content.¶

5.4. Correlation and Inference

Presentations of the same record to multiple parties can be correlated by matching on the signature component. Session identifiers enable linking of records across time, potentially revealing long-term behavioral patterns or organizational structure. Implementations SHOULD use unlinkable session identifiers where correlation is not required.¶

Without accessing record content, observers may infer conversation frequency and duration patterns, types of tools used, error rates, or timing correlations with external events. Metadata exposure in unprotected headers warrants careful consideration; the trace-metadata in the COSE unprotected header reveals session identifiers, agent vendor, and timestamps even when the payload is encrypted.¶

5.5. Authority Access

Regulatory frameworks may require provision of records to authorities upon request. Access to records has to be logged, capturing who accessed which records, when access occurred, what legal basis justified access, and what data was disclosed. This creates a recursive consideration: access logs may themselves contain personal data requiring protection.¶

6.1. Record Integrity

The signed-agent-record envelope provides cryptographic integrity protection for the serialized record payload. A valid signature establishes that the claimed signer produced the record but does not guarantee the truthfulness of its contents. Modifications to the record structure after signing invalidate the signature, but modifications before signing cannot be detected. Implementations generating records incrementally during a conversation MUST sign only after the conversation concludes or at defined checkpoints.¶

6.2. Signing Key Protection

The security of signed records depends critically on the protection of private signing keys. If an attacker obtains a signing key, they can forge records indistinguishable from genuine ones. Protection mechanisms range from operating system process isolation in development environments to hardware security modules with physical tampering resistance in high-assurance deployments. Compromised signing keys require rejection of records signed after the compromise date and notification to Relying Parties.¶

Key provisioning processes must guarantee that exclusively valid attestation key material is established. Off-device key generation requires confidentiality protection during transmission, creating recursive security dependencies. On-device key generation eliminates transmission risks but requires chain-of-custody integrity to prevent attackers from obtaining endorsement for keys they control.¶

6.3. Timestamp Integrity

Timestamps establish temporal ordering of events within records. Attackers who can manipulate timestamps can backdate records, freeze participants in chosen time periods to evade freshness checks, or manipulate perceived temporal relationships between entries. Timestamps within records are attested by the signer, not independently verified. Implementations requiring independent timestamp verification SHOULD use external timestamping services or transparency logs such as those defined in [I-D.ietf-scitt-architecture].¶

6.4. Adversarial Content

Processing verifiable agent conversation records involves parsing content that may be produced by adversaries. This applies both to user-supplied prompts and to model outputs that may have been influenced by adversarial inputs. The open extensibility (* tstr => any) in record types allows arbitrary additional fields; implementations MUST NOT assume that unrecognized fields are safe to process or display.¶

Records may contain content designed to exploit downstream systems. Malicious prompts preserved in records may execute if records are subsequently processed by AI systems. Tool results may contain executable content that executes if rendered unsafely in web interfaces. File paths in tool calls or file attribution entries may attempt directory traversal. Implementations MUST apply appropriate sanitization before rendering content, executing it in agent contexts, or using paths for file system operations.¶

6.5. Non-Repudiation

The signed-agent-record envelope alone provides authenticity and integrity, not non-repudiation. A signer can claim key compromise or dispute the signing time without independent evidence. Non-repudiation requires additional infrastructure such as transparency services [I-D.ietf-scitt-architecture] that provide independent timestamp proof via registration receipts, append-only logs preventing retroactive denial, and third-party witnesses to the signing event.¶

6.6. Detection and Trust Boundaries

Verifiable agent conversation records primarily enable detection of anomalous behavior rather than prevention. Detection requires that records accurately reflect actual agent behavior; an agent that controls its own recording can omit or falsify entries. The recording-agent field distinguishes the recording tool from the conversing agent, enabling Relying Parties to assess trust in the recording process.¶

Trust boundaries exist between the agent runtime and recording system, between the recording system and storage, between storage and verification, and between verification and decision-making. Attacks at any boundary may compromise record integrity or confidentiality.¶

7.1. Media Type

IANA is requested to add "application/agent-conversation" as a new media type for Verifiable Agent Conversation Records to the "Media Types" registry [IANA.media-types] in the Standards Tree [RFC6838]:¶

Type name:

application¶

Subtype name:

agent-conversation¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

byte string¶

Security considerations:

See Security Considerations {secconsec}¶

Interoperability considerations:

N/A¶

Published specification:

RFCthis¶

Applications that use this media type:

Applications that need to describe AI agent conversation for verification and auditability.¶

Fragment identifier considerations:

N/A¶

Additional information:

Deprecated alias names for this type:

N/A¶

Magic number(s):

N/A¶

File extension(s):

acr¶

Macintosh file type code(s):

N/A¶

Person/email address to contact for further information:

TBD¶

Intended usage:

COMMON¶

Restriction on usage:

none¶

Author:

See Author's Addresses section¶

Change controller:

IETF¶

Provisional registration:

no¶

7.2. CoAP Content Format

IANA is requested to assign a Content-Format ID for Verifiable Agent Conversation Records in the "CoAP Content-Formats" registry, within the "Constrained RESTful Environments (CoRE) Parameters" registry group [IANA.core-parameters]:¶

If possible, TBD1 should be assigned in the 256...9999 range.¶

7.3. CBOR Tag

IANA is requested to allocate a tag for Verifiable Agent Conversation Records in the "CBOR Tags" registry [IANA.cbor-tags], preferably with the specific value requested:¶

7.4. COSE Header Parameter

IANA is requested to allocated the COSE header parameter defined in Table 19 in the "COSE Header Parameters" registry [IANA.cose_header-parameters].¶

8.1. Normative References

[AICPA_TSC_2017]

American Institute of Certified Public Accountants and Chartered Institute of Management Accountants, "Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (With Revised Points of Focus - 2022)", AICPA Trust Services Criteria, 2017, <https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022>.

[BCP26]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://doi.org/10.17487/RFC8126>.

[BSI_AI_FINANCE_2024]

Bundesamt fuer Sicherheit in der Informationstechnik, "Test Criteria Catalogue for AI Systems in Finance", BSI AI Finance Test Criteria, 2024, <https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KI/AI-Finance_Test-Criteria.pdf>.

[ETSI_TS_104223_2025]

European Telecommunications Standards Institute, "Securing Artificial Intelligence (SAI); Baseline Cyber Security Requirements for AI Models and Systems", ETSI TS 104 223, V1.1.1, April 2025, <https://www.etsi.org/deliver/etsi_ts/104200_104299/104223/01.01.01_60/ts_104223v010101p.pdf>.

[EU_AI_ACT_2024]

European Parliament and Council of the European Union, "Regulation (EU) 2024/1689 (Artificial Intelligence Act)", CELEX: 32024R1689, Official Journal of the European Union L 2024/1689, July 2024, <https://eur-lex.europa.eu/eli/reg/2024/1689/oj>.

[EU_CRA_2024]

European Parliament and Council of the European Union, "Regulation (EU) 2024/2847 (Cyber Resilience Act)", CELEX: 32024R2847, Official Journal of the European Union L 2024/2847, November 2024, <https://eur-lex.europa.eu/eli/reg/2024/2847/oj>.

[EU_NIS2_2022]

European Parliament and Council of the European Union, "Directive (EU) 2022/2555 (NIS 2 Directive)", CELEX: 32022L2555, Official Journal of the European Union L 333, December 2022.

[FFIEC_IT_HANDBOOK_2024]

Federal Financial Institutions Examination Council, "Information Technology Examination Handbook", FFIEC IT Examination Handbook, August 2024, <https://ithandbook.ffiec.gov/>.

[IANA.cbor-tags]

IANA, "Concise Binary Object Representation (CBOR) Tags", <https://www.iana.org/assignments/cbor-tags>.

[IANA.core-parameters]

IANA, "Constrained RESTful Environments (CoRE) Parameters", <https://www.iana.org/assignments/core-parameters>.

[IANA.cose_header-parameters]

IANA, "COSE Header Parameters", <https://www.iana.org/assignments/cose>.

[IANA.cwt]

IANA, "CBOR Web Token (CWT) Claims", <https://www.iana.org/assignments/cwt>.

[IANA.jwt]

IANA, "JSON Web Token (JWT)", <https://www.iana.org/assignments/jwt>.

[IANA.media-types]

IANA, "Media Types", <https://www.iana.org/assignments/media-types>.

[ISO_IEC_42001_2023]

International Organization for Standardization and International Electrotechnical Commission, "Information technology - Artificial intelligence - Management system", ISO/IEC 42001:2023, December 2023, <https://www.iso.org/standard/42001>.

[NIST_AI_100_2_E2025]

National Institute of Standards and Technology, "Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations", NIST AI 100-2 E2025, March 2025, <https://csrc.nist.gov/pubs/ai/100/2/e2025/final>.

[NIST_SP_800_53_R5]

National Institute of Standards and Technology, "Security and Privacy Controls for Information Systems and Organizations", NIST Special Publication 800-53, Revision 5, September 2020, <https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final>.

[OMB_M_21_31]

Office of Management and Budget, "Improving the Federal Government's Investigative and Remediation Capabilities Related to Cybersecurity Incidents", OMB Memorandum M-21-31, August 2021, <https://www.whitehouse.gov/wp-content/uploads/2021/08/M-21-31-Improving-the-Federal-Governments-Investigative-and-Remediation-Capabilities-Related-to-Cybersecurity-Incidents.pdf>.

[PCI_DSS_V4_0_1]

PCI Security Standards Council, "Payment Card Industry Data Security Standard", PCI DSS Version 4.0.1, June 2024, <https://www.pcisecuritystandards.org/document_library/>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://doi.org/10.17487/RFC2119>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://doi.org/10.17487/RFC4648>.

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://doi.org/10.17487/RFC5280>.

[RFC6838]

Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://doi.org/10.17487/RFC6838>.

[RFC7252]

Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://doi.org/10.17487/RFC7252>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://doi.org/10.17487/RFC7515>.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://doi.org/10.17487/RFC7519>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://doi.org/10.17487/RFC8174>.

[RFC8610]

Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://doi.org/10.17487/RFC8610>.

[STD90]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://doi.org/10.17487/RFC8259>.

[STD94]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://doi.org/10.17487/RFC8949>.

8.2. Informative References

[EMERGENT_MISALIGNMENT_2025]

Betley, J., Tan, D., Warncke, N., Sztyber-Betley, A., Bao, X., Soto, M., Labenz, N., and O. Evans, "Emergent Misalignment: Narrow finetuning can produce broadly misaligned LLMs", PMLR 267:4043-4068, arXiv 2502.17424, February 2025, <https://arxiv.org/abs/2502.17424>.

[I-D.ietf-scitt-architecture]

Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", Work in Progress, Internet-Draft, draft-ietf-scitt-architecture-22, 10 October 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-scitt-architecture-22>.

[ISO_IEC_DIS_24970]

International Organization for Standardization and International Electrotechnical Commission, "Artificial intelligence - AI system logging", ISO/IEC DIS 24970, 2025, <https://www.iso.org/standard/88723.html>.

[RFC6973]

Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://doi.org/10.17487/RFC6973>.

[RFC9334]

Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://doi.org/10.17487/RFC9334>.

[STD96]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, <https://doi.org/10.17487/RFC9052>.