Signed Memory Projection Records for Verifiable AI Context Delivery
draft-ferro-schrock-memory-projection-record-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Andrea Ferro , Iman Schrock | ||
| Last updated | 2026-08-04 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ferro-schrock-memory-projection-record-01
Network Working Group A. Ferro
Internet-Draft ApertoMemory
Intended status: Experimental I. Schrock
Expires: 4 February 2027 EMILIA Protocol, Inc.
3 August 2026
Signed Memory Projection Records for Verifiable AI Context Delivery
draft-ferro-schrock-memory-projection-record-01
Abstract
Encrypted and signed memory objects can establish source integrity,
authorship, and read-time trust without establishing which exact
bytes a memory adapter selected and delivered to a downstream AI
system. This document specifies a provider-neutral signed Memory
Projection Record. The record commits to the recall request and
selection policy, the read-time keyring snapshot, the ordered source
objects and exact context fragments delivered, the complete
projection bytes, and summarized exclusions. It deliberately does
not claim that a model received, used, or weighted the projection,
that an action was authorized, or that an outcome occurred.
ApertoMemory is one source profile; other memory formats can use the
same projection boundary.
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 4 February 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Ferro & Schrock Expires 4 February 2027 [Page 1]
Internet-Draft Memory Projection Records August 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Scope and Nonclaims . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Memory Projection Record . . . . . . . . . . . . . . . . . . 4
4.1. Identity and Time . . . . . . . . . . . . . . . . . . . . 5
4.2. Selection Context . . . . . . . . . . . . . . . . . . . . 6
4.3. Delivered Entries and Projection Bytes . . . . . . . . . 6
4.4. Exclusions . . . . . . . . . . . . . . . . . . . . . . . 7
5. ApertoMemory Source Profile . . . . . . . . . . . . . . . . . 7
5.1. Trust Snapshot . . . . . . . . . . . . . . . . . . . . . 7
5.2. Context Fragment . . . . . . . . . . . . . . . . . . . . 8
6. Canonicalization and Signature . . . . . . . . . . . . . . . 8
7. Producer Algorithm . . . . . . . . . . . . . . . . . . . . . 9
8. Verifier Algorithm . . . . . . . . . . . . . . . . . . . . . 9
9. Composition with Downstream Systems . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
13. Implementation Status . . . . . . . . . . . . . . . . . . . . 11
14. Changes Since -00 . . . . . . . . . . . . . . . . . . . . . . 12
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
16. Normative References . . . . . . . . . . . . . . . . . . . . 12
17. Informative References . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
A memory-object format and a context-delivery record answer different
questions. A memory-object format can prove that an object verified
under a key accepted at read time. It does not, by itself, identify
the set, order, framing, or exact bytes selected for a particular AI
request. Conversely, a projection record cannot repair invalid
source provenance. It can only preserve the source decision and bind
it to the bytes emitted by a named adapter.
Ferro & Schrock Expires 4 February 2027 [Page 2]
Internet-Draft Memory Projection Records August 2026
This document defines the join between those layers. A projection
producer signs one closed record after the projection bytes and their
ordered fragments are finalized. A verifier recomputes the source-
object, fragment, and complete-projection commitments and verifies
the adapter signature under a relying-party-pinned key. The
resulting fact is narrow: the producer attests that it emitted the
committed projection under the committed selection context.
The source memory profile remains authoritative for its own object,
cryptographic, trust, authorship, and custody semantics. In
particular, ApertoMemory [I-D.ferro-apertomemory] remains
authoritative for sealed Memory Objects and its read-time trust
derivation. This document does not redefine those semantics. It
defines a joint, provider-neutral artifact above that boundary.
1.1. 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.
2. Scope and Nonclaims
A conforming Memory Projection Record establishes all of the
following:
* the adapter identity and pinned signing key used to produce the
record;
* commitments to the recall request, selection policy, source-
profile trust snapshot, and framing profile;
* the ordered list of source objects selected, with the trust and
authorship results supplied by the source profile;
* the exact bytes of each framed context fragment and of the
complete emitted projection; and
* the number of objects excluded for each closed exclusion reason.
A projection record does not establish transport receipt, insertion
into a model context window, model use or weighting, action linkage,
action authorization, execution, or outcome. A downstream system MAY
bind the projection digest into a separate request, authorization, or
outcome protocol. Such a binding is outside this document.
Ferro & Schrock Expires 4 February 2027 [Page 3]
Internet-Draft Memory Projection Records August 2026
3. Terminology
Source profile The independently governed memory format and
verification rules from which object identity, trust, authorship,
and custody facts are derived.
Projection producer The adapter that selects source objects, frames
exact context fragments, constructs the complete projection, and
signs the Memory Projection Record.
Projection The exact byte string emitted by the producer for
downstream context delivery.
Context fragment The exact framed bytes contributed by one selected
source object at one position in the projection.
Trust snapshot A commitment to the source-profile trust state used
when the selection decision was made. For ApertoMemory this is a
read-time keyring snapshot, because trust is derived rather than
stored in the object.
b64u Unpadded base64url encoding as defined in Section 5 of
[RFC4648].
4. Memory Projection Record
MEMORY-PROJECTION-RECORD-v1 is a closed I-JSON object [RFC7493]. The
top-level members are shown below. Member order in a JSON
serialization has no significance. Unknown members MUST be refused
until a later version defines an extension mechanism.
{
"@version": "MEMORY-PROJECTION-RECORD-v1",
"source_profile": "draft-ferro-apertomemory-02",
"projection_id": "urn:memory-projection:example:1234",
"created_at": "2026-07-29T17:00:01.000Z",
"adapter": {
"id": "urn:memory-adapter:example:1",
"key_id": "adapter-key-2026-07"
},
"selection_context": {
"recall_request_digest": "sha256:...",
"selection_policy_digest": "sha256:...",
"trust_snapshot_digest": "sha256:...",
"trust_evaluated_at": "2026-07-29T17:00:00.000Z",
"context_frame_profile": "urn:apertomemory:context-frame:v0"
},
"delivered": [
Ferro & Schrock Expires 4 February 2027 [Page 4]
Internet-Draft Memory Projection Records August 2026
{
"position": 0,
"object": {
"format_version": 2,
"sealed_object_digest": "sha256:..."
},
"context_fragment_digest": "sha256:...",
"derived_trust": "trusted",
"authorship": "attested",
"author_key_id_b64u": "0FMJy9O1Xzs",
"custody_present": true
}
],
"exclusions": {
"total": 2,
"by_reason": {
"authentication_failed": 1,
"schema_invalid": 0,
"policy_filtered": 0,
"context_limit": 1
}
},
"projection": {
"encoding": "utf-8",
"byte_length": 314,
"digest": "sha256:..."
},
"nonclaims": {
"model_use": "NOT_ESTABLISHED",
"action_linkage": "NOT_ESTABLISHED",
"action_authorization": "NOT_ESTABLISHED",
"execution_outcome": "NOT_ESTABLISHED"
},
"proof": {
"alg": "Ed25519",
"key_id": "adapter-key-2026-07",
"signature_b64u": "..."
}
}
4.1. Identity and Time
@version MUST equal MEMORY-PROJECTION-RECORD-v1. projection_id MUST
be a globally unique URI. created_at and trust_evaluated_at MUST be
UTC timestamps conforming to [RFC3339]. adapter.id identifies the
producer; adapter.key_id selects a key from relying-party policy.
proof.key_id MUST equal adapter.key_id.
Ferro & Schrock Expires 4 February 2027 [Page 5]
Internet-Draft Memory Projection Records August 2026
The relying party MUST set a maximum acceptable interval between
trust_evaluated_at, created_at, and its verification time. A valid
signature does not make a stale trust decision current.
4.2. Selection Context
recall_request_digest is SHA-256 over the exact request bytes under a
profile that defines their serialization. selection_policy_digest is
SHA-256 over the exact policy bytes that determined eligibility,
filtering, ordering, and limits. trust_snapshot_digest is SHA-256
over the source-profile-defined trust snapshot. context_frame_profile
names the deterministic transformation from one opened source object
and its labels to one context fragment.
The cleartext request, policy, and trust snapshot need not be carried
in the record. A verifier that relies on any of them MUST possess
the exact bytes and their applicable serialization profiles and MUST
recompute the corresponding digest.
4.3. Delivered Entries and Projection Bytes
delivered is an array in projection order. position MUST equal the
zero-based array index and MUST NOT repeat. sealed_object_digest is
SHA-256 over the exact complete source-object bytes as supplied,
without parsing or reserialization. format_version is interpreted
only by the named source profile.
context_fragment_digest is SHA-256 over the exact bytes of the
fragment emitted for that entry, including framing labels,
separators, and line endings. The complete projection is the
bytewise concatenation of those fragments in ascending position.
projection.byte_length and projection.digest MUST equal the length
and SHA-256 digest of that complete byte string. This version
supports only UTF-8 projection bytes; projection.encoding MUST equal
utf-8.
derived_trust, authorship, author_key_id_b64u, and custody_present
preserve the source-profile result used at selection time. They MUST
NOT be recomputed under rules invented by the projection producer.
For an ApertoMemory source, the source profile remains solely
authoritative for those values. Unverified content MUST use
authorship unknown and a null author key. Attested authorship
requires custody_present true.
Ferro & Schrock Expires 4 February 2027 [Page 6]
Internet-Draft Memory Projection Records August 2026
4.4. Exclusions
exclusions.total MUST equal the sum of the closed by_reason counters.
authentication_failed counts objects refused by source
authentication; schema_invalid counts source objects the source
profile refuses; policy_filtered counts otherwise valid objects
excluded by policy; and context_limit counts otherwise eligible
objects omitted due to a projection limit. A producer MUST NOT map
an unknown reason into a semantically different counter. This
version does not disclose excluded object identifiers, reducing
correlation and content-oracle risk.
5. ApertoMemory Source Profile
This section defines the source-profile processing used when
source_profile equals draft-ferro-apertomemory-02 and
context_frame_profile equals urn:apertomemory:context-frame:v0. The
source-native outputs remain governed by [I-D.ferro-apertomemory].
The projection producer MUST preserve those outputs and MUST NOT
upgrade or reinterpret them.
The embedded requirements below reproduce the ratified
[AMEM-TRUST-SNAPSHOT-PROFILE] and [AMEM-CONTEXT-FRAME-PROFILE]
profiles pinned at ApertoMemory commit 48be525.
5.1. Trust Snapshot
The ApertoMemory trust snapshot MUST be encoded as deterministic CBOR
using the preferred serialization rules in Section 4.2 of [RFC8949].
It is a two-member map. Integer key 1 maps to the vault owner's
signing-key identifier as an eight-byte CBOR byte string. Integer
key 2 maps to an array containing the accepted author key
identifiers, each as an eight-byte CBOR byte string.
Each key identifier is the first eight bytes of SHA-256 over the raw
Ed25519 signing public key. The accepted-key array MUST represent
the exact known_keys set at trust_evaluated_at: duplicate identifiers
are removed and the remaining raw byte strings are sorted in
ascending unsigned-byte order. The owner identifier is retained when
it is also present in known_keys. Integer key 2 MUST be present even
when the set is empty. A producer MUST NOT sort base64url or
hexadecimal representations in place of the raw bytes.
trust_snapshot_digest is the lowercase hexadecimal SHA-256 digest of
those exact deterministic-CBOR bytes, prefixed by sha256:.
Ferro & Schrock Expires 4 February 2027 [Page 7]
Internet-Draft Memory Projection Records August 2026
single accepted key:
a2014863c1e89c009c5ad7028148d05309cbd3b55f3b
sha256:ad677e36d1ac311f758cefeb41069704d1bc995612db0bc1029e239ecfcc2b5d
two accepted keys, raw-byte order:
a201480102030405060708028248000000000000000148d000000000000000
sha256:a6cec9a790d68dda6df60477c802cd3738650cd8f1b38fcc21125de51762e231
empty accepted-key set:
a2014863c1e89c009c5ad70280
sha256:eddde59fb79cca10fdadf0c5bfc7c3b7e466cab79dcb95a5c4ea165fc8eb5bf0
5.2. Context Fragment
The producer obtains derived_trust, authorship, author key, custody
state, and body bytes from the source-native open_sealed result. It
MUST NOT reproduce ApertoMemory trust logic inside the projection
adapter. The body is used as exact UTF-8 with no trimming, newline
conversion, or Unicode normalization.
The context fragment is the UTF-8 byte sequence produced by the
following exact concatenation. Every shown line ending is one LF
byte (0x0A), including the final line ending.
"[ApertoMemory trust=" + trust
+ " authorship=" + authorship
+ " author_key=" + author_key
+ " custody=" + custody
+ "]\n"
+ body
+ "\n[/ApertoMemory]\n"
trust is self, trusted, or unverified. authorship is signed,
attested, or unknown. author_key is the unpadded base64url encoding
of the native eight-byte author key identifier, or the literal none
when the source result has no author. custody is the lowercase
literal true or false. Fields and values MUST appear in the order
shown.
6. Canonicalization and Signature
Every member except proof is inside the signature boundary. The
producer removes proof, canonicalizes the remaining object with JCS
[RFC8785], prefixes the following UTF-8 domain string and one zero
octet, and signs the resulting bytes with Ed25519 [RFC8032]:
MEMORY-PROJECTION-RECORD-v1\0 || JCS(record without proof)
Ferro & Schrock Expires 4 February 2027 [Page 8]
Internet-Draft Memory Projection Records August 2026
proof.alg MUST equal Ed25519. signature_b64u is the unpadded
base64url encoding [RFC4648] of the 64-byte signature. The public
key MUST come from relying-party policy or an authenticated key-
distribution mechanism outside the record. A key carried with the
record is not a trust anchor.
7. Producer Algorithm
1. Open and verify candidate objects using their native source
profile. Record the trust snapshot and evaluation time.
2. Commit to the recall request and complete selection policy before
selecting objects.
3. Apply authentication, schema, policy, ordering, and size rules.
Count every excluded candidate under exactly one exclusion
reason.
4. Construct each final context fragment, hash its exact bytes, and
append its entry in order. After this step the fragments MUST
NOT be mutated without rebuilding the record.
5. Concatenate the fragments, compute projection.byte_length and
projection.digest, construct the nonclaims, and sign the closed
record.
6. Return or make available the projection bytes and record as one
logical result. A failure after signing but before downstream
delivery MUST NOT be reported as proof that a model received the
bytes.
8. Verifier Algorithm
1. Require the exact top-level and nested member sets defined by
this version. Validate types, enumerations, timestamps, and
digest syntax.
2. Resolve adapter.key_id under relying-party policy, verify that it
is current for created_at, and verify the Ed25519 signature over
the domain-separated JCS bytes.
3. Enforce freshness policy for created_at and trust_evaluated_at
and reject a duplicate projection_id when policy requires single
use.
4. If relying on the request, policy, or trust snapshot, recompute
its digest under the named profile.
Ferro & Schrock Expires 4 February 2027 [Page 9]
Internet-Draft Memory Projection Records August 2026
5. Verify each exact source-object digest under its native source
profile. Preserve, rather than reinterpret, the native trust,
authorship, and custody result.
6. Require sequential positions. Recompute every fragment digest
from the exact fragment bytes, concatenate those bytes in order,
and verify the complete length and digest.
7. Verify that exclusions.total equals the sum of the closed reason
counters and that all four nonclaims equal NOT_ESTABLISHED.
A verifier MUST refuse mutation, omission, duplication, or reordering
of a delivered entry; a fragment or projection mismatch; an unpinned,
expired, or compromised adapter key; a stale trust evaluation; a
count mismatch; an unknown field; an altered nonclaim; or an invalid
signature.
9. Composition with Downstream Systems
A downstream protocol may bind projection.digest and projection_id
into a model invocation, action proposal, authorization, admission
decision, execution receipt, or outcome record. That downstream
protocol is authoritative for its own semantics. The Memory
Projection Record MUST remain valid and useful without requiring any
particular agent, authorization, or outcome framework.
EMILIA Trusted Context, AEC, Gate, and Outcome Binding are one
consumer profile. They may use the projection as one evidence leg
and independently bind the actual action and consequence. They are
not part of the neutral projection-record wire format and do not
authorize changes to the source profile or projection record.
10. Security Considerations
A signed projection can preserve poisoned content with high
integrity. Producers MUST therefore apply the native source profile
fail closed and MUST keep unverified content distinguishable from
self or trusted content. The projection signature proves an adapter
statement, not the correctness of a memory, trust policy, keyring,
framing policy, or model behavior.
Stable object identifiers and excluded-object lists create
correlation and membership oracles. This version commits to exact
source bytes and carries aggregate exclusion counts rather than
cleartext source identifiers. Deployments SHOULD use pairwise
adapter identifiers where appropriate and SHOULD minimize retention
of request, policy, and projection material.
Ferro & Schrock Expires 4 February 2027 [Page 10]
Internet-Draft Memory Projection Records August 2026
Replay can cause an old but valid projection to be applied under a
new request. Relying parties MUST enforce freshness and SHOULD
register projection_id atomically when single use is required. A
stale or revoked source keyring, adapter key, or policy MUST NOT be
made current merely by replaying a valid historical signature.
11. Privacy Considerations
Memory projections can contain highly sensitive personal facts and
can reveal selection behavior even when source objects remain
encrypted. Records SHOULD carry commitments rather than cleartext
requests, policies, trust snapshots, or excluded identifiers. The
projection bytes SHOULD be disclosed only to the intended downstream
recipient. Logs SHOULD avoid storing raw projection or fragment
bytes unless operationally required.
12. IANA Considerations
This document has no IANA actions.
13. Implementation Status
The Apache-2.0 implementation [AMEM-EMILIA-INTEROP] implements
MEMORY-PROJECTION-RECORD-v1. It produces and verifies the closed
neutral field set and v1 domain-separated Ed25519 signature,
recomputes the exact recall-request, policy, trust-snapshot, source-
object, fragment, and complete-projection commitments, preserves
source-native trust results, and exercises positive and hostile
mutation vectors.
ApertoMemory and EMILIA first independently reproduced five native
source-fact cases and matched their exact source-object digests and
native trust, authorship, signer, author, and custody results.
Separate producers then converged byte-for-byte on a frozen
Projection v1 example. That exercise exposed the two
underspecifications resolved in Section 5. ApertoMemory subsequently
published the exact context-frame and trust-snapshot profiles at
pinned commit 48be525, and EMILIA independently reproduced the three
deterministic CBOR examples and both checked context-frame digests
before adopting those bytes.
This is bounded reciprocal evidence for the checked source facts,
profile bytes, and Projection v1 cases. It is not blanket
ApertoMemory conformance, does not establish that every hostile case
has a second independent implementation, and establishes none of
model receipt, model use, action linkage, action authorization,
execution, or outcome.
Ferro & Schrock Expires 4 February 2027 [Page 11]
Internet-Draft Memory Projection Records August 2026
14. Changes Since -00
This revision makes no change to the MEMORY-PROJECTION-RECORD-v1 wire
field set or signature domain. It specifies the exact ApertoMemory
deterministic-CBOR trust snapshot and context-frame bytes, updates
the example to name that framing profile, and records the bounded
reciprocal implementation evidence completed after -00.
15. Acknowledgments
The authors thank Matteo Clementel for his review and contributions
to the memory-projection boundary.
16. 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/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
DOI 10.17487/RFC7493, March 2015,
<https://www.rfc-editor.org/info/rfc7493>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[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/info/rfc8174>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/info/rfc8785>.
Ferro & Schrock Expires 4 February 2027 [Page 12]
Internet-Draft Memory Projection Records August 2026
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
17. Informative References
[AMEM-CONTEXT-FRAME-PROFILE]
Ferro, A., "ApertoMemory Context Frame v0 Profile", 3
August 2026,
<https://github.com/apertomemory/apertomemory/blob/48be5250f26aea9e34bc4f8adaca22ac9016cc84/
interop/emilia/apertomemory-context-frame-v0-profile.md>.
[AMEM-EMILIA-INTEROP]
Schrock, I., "ApertoMemory / EMILIA Memory-to-Action
Composition Profile", July 2026, <https://github.com/
emilia-protocol/emilia-protocol/tree/main/interop/
apertomemory-emilia>.
[AMEM-TRUST-SNAPSHOT-PROFILE]
Ferro, A., "ApertoMemory Trust Snapshot v0 Profile", 3
August 2026,
<https://github.com/apertomemory/apertomemory/blob/48be5250f26aea9e34bc4f8adaca22ac9016cc84/
interop/emilia/apertomemory-trust-snapshot-profile.md>.
[I-D.ferro-apertomemory]
Ferro, A., "The ApertoMemory Format: Portable, Client-
Side-Encrypted AI Memory", Work in Progress, Internet-
Draft, draft-ferro-apertomemory-02, 22 July 2026,
<https://datatracker.ietf.org/doc/draft-ferro-
apertomemory/>.
Authors' Addresses
Andrea Ferro
ApertoMemory
Email: irn@irn3.com
Iman Schrock
EMILIA Protocol, Inc.
United States of America
Email: team@emiliaprotocol.ai
Ferro & Schrock Expires 4 February 2027 [Page 13]