N-AALP: The Native Agentic Application Layer Protocol
draft-bubblefish-naalp-00
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) | |
|---|---|---|---|
| Author | Shawn Edward Sammartano | ||
| Last updated | 2026-07-27 | ||
| 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-bubblefish-naalp-00
Network Working Group S. Sammartano
Internet-Draft BubbleFish Technologies, Inc.
Intended status: Informational 27 July 2026
Expires: 28 January 2027
N-AALP: The Native Agentic Application Layer Protocol
draft-bubblefish-naalp-00
Abstract
The Native Agentic Application Layer Protocol (N-AALP) is an
application-layer object protocol for autonomous software agents.
Every N-AALP object is a deterministically encoded CBOR structure
signed with COSE, carrying under one signature its content identity,
its originating signer, a closed effect label that is an
authorization input rather than a hint, optional approval and audit
bindings, and its causal derivation. Objects are transport-
independent: the identical signed object is carried, with identical
object-level guarantees, over the N-PAMP substrate, QUIC, WebSocket,
or HTTP. N-AALP defines a frozen envelope, a post-quantum signature
profile (ML-DSA with an optional Ed25519 hybrid), a self-certifying
identity with key rotation, a single-use approval ledger, a hash-
chained audit and causal- ordering model with a federated higher
tier, native streaming with a single per-stream commitment, foreign-
protocol carriage by class, and twenty tiered channel surfaces. This
document is an Independent Submission and does not represent IETF
consensus.
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 28 January 2027.
Sammartano Expires 28 January 2027 [Page 1]
Internet-Draft N-AALP July 2026
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Object Model . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Deterministic encoding . . . . . . . . . . . . . . . . . 5
4.2. The object body . . . . . . . . . . . . . . . . . . . . . 5
4.3. Content identity . . . . . . . . . . . . . . . . . . . . 5
4.4. Extensions and versioning . . . . . . . . . . . . . . . . 6
5. Cryptographic Constructions . . . . . . . . . . . . . . . . . 6
5.1. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Algorithms and profiles . . . . . . . . . . . . . . . . . 6
6. Identity . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Effects and Authorization . . . . . . . . . . . . . . . . . . 7
8. Approval . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Audit, Causal Graph, and Ordering . . . . . . . . . . . . . . 8
10. Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11. Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . 9
12. Transport Bindings . . . . . . . . . . . . . . . . . . . . . 9
13. Foreign Carriage by Class . . . . . . . . . . . . . . . . . . 9
14. Channel Surfaces . . . . . . . . . . . . . . . . . . . . . . 10
15. Security Considerations . . . . . . . . . . . . . . . . . . . 10
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
16.1. Media type application/naalp+cbor . . . . . . . . . . . 12
16.2. N-AALP Channel registry . . . . . . . . . . . . . . . . 13
16.3. N-AALP Object Kind registries . . . . . . . . . . . . . 13
16.4. N-AALP Effect registry . . . . . . . . . . . . . . . . . 13
16.5. N-AALP Carriage Protocol Id registry . . . . . . . . . . 13
16.6. N-AALP Error Code registry . . . . . . . . . . . . . . . 14
16.7. COSE algorithms . . . . . . . . . . . . . . . . . . . . 14
16.8. Designated Expert guidance . . . . . . . . . . . . . . . 14
17. Implementation Status . . . . . . . . . . . . . . . . . . . . 14
18. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 15
19. Specification License . . . . . . . . . . . . . . . . . . . . 15
Sammartano Expires 28 January 2027 [Page 2]
Internet-Draft N-AALP July 2026
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
20.1. Normative References . . . . . . . . . . . . . . . . . . 15
20.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Collected CDDL . . . . . . . . . . . . . . . . . . . 17
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
Autonomous agents increasingly exchange consequential messages --
tool invocations, memory writes, capability delegations, settlements
-- across trust and organizational boundaries. Existing agent
protocols secure the transport connection but leave the individual
message un-signed, its effect on the world undeclared, and its
authorization implicit. N-AALP makes the object, not the connection,
the unit of security and governance.
N-AALP is the application layer above the N-PAMP substrate [NPAMP]:
N-PAMP provides the post-quantum secure channel, channel identifiers,
and foreign-protocol Bridge; N-AALP provides the signed, effect-
labeled, audited object that rides any transport. The two compose
but N-AALP does not require N-PAMP: the same object is valid over
QUIC, WebSocket, or HTTP.
1.1. Scope
This document specifies: the object envelope and its deterministic
CBOR encoding (# Object Model); the COSE signing constructions and
crypto-agile profiles (# Cryptographic Constructions); self-
certifying identity and key lifecycle (# Identity); the closed effect
vocabulary and effect-to-authorization rule (# Effects and
Authorization); the approval object and single-use consume ledger (#
Approval); the audit receipt chain, causal graph, and tiered ordering
(# Audit, Causal Graph, and Ordering); delivery stages (# Delivery);
native streaming (# Streaming); the four transport bindings and the
confidentiality boundary (# Transport Bindings); foreign carriage by
class (# Foreign Carriage by Class); and the twenty tiered channel
surfaces (# Channel Surfaces).
1.2. Non-Goals
N-AALP does not define a transport handshake, key exchange, or record
layer; those are the substrate's (N-PAMP's, or the underlying TLS/
QUIC's). It does not define agent reasoning, planning, or model
behavior. It does not replace the foreign protocols it carries; it
wraps them.
Sammartano Expires 28 January 2027 [Page 3]
Internet-Draft N-AALP July 2026
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.
The following terms are used:
Object: a deterministically encoded CBOR map, signed with COSE, that
is the unit of N-AALP security and governance.
Content id: the multihash of the SHA-384 of an object's canonical
body excluding its own id field; it binds the object's bytes.
Signer id: a self-certifying identifier derived from a public
signing key (# Identity); no certificate authority is involved.
Effect: one closed value stating what an object does to the world,
aligned with the N-PAMP Bridge SafetyLabel and used as an
authorization input (# Effects and Authorization).
Channel: one of twenty application surfaces, identified by an N-PAMP
channel id (# Channel Surfaces).
Carriage: wrapping a foreign protocol's message octet-for-octet
inside a signed N-AALP object (# Foreign Carriage by Class).
3. Architecture
N-AALP separates three layers that MUST NOT be conflated:
1. The object (this document): self-secured, transport-independent.
2. The transport: provides confidentiality, connection
authentication, and framing; N-PAMP is the reference confidential
transport, but QUIC, WebSocket, and HTTP are equally valid
carriers of the identical object.
3. The application: the twenty channel surfaces, each a thin body
over the one object model.
Object-level guarantees (integrity, identity, non-repudiation,
effect, audit) are always present regardless of transport.
Confidentiality, forward secrecy, and connection authentication are
transport-provided and conditional (# Transport Bindings).
Sammartano Expires 28 January 2027 [Page 4]
Internet-Draft N-AALP July 2026
4. Object Model
4.1. Deterministic encoding
All N-AALP structures are encoded as deterministic CBOR per [RFC8949]
Section 4.2.1: shortest-form integer and length encoding, major-type
map keys sorted in bytewise-lexicographic order of their encoded
form, no indefinite-length items, and no duplicate keys. A non-
canonical encoding of any structure defined here MUST be rejected.
4.2. The object body
The signed payload is the object body, a CBOR map, expressed here in
CDDL [RFC8610]:
naalp-object = {
1 : bstr, ; id: multihash(0x20, SHA-384(body-without-1))
2 : uint, ; kind (per channel surface)
3 : 0..19, ; channel id
4 : uint, ; tier (0 = baseline)
5 : bstr, ; signer: self-certifying signer id
6 : uint, ; created: epoch ms (advisory)
7 : effect, ; closed effect value
8 : [* bstr], ; causes: content ids; may be empty
9 : profile, ; crypto profile
10 : any, ; body: kind-specific, validated by the surface
? 11 : { * uint => any }, ; ext: non-critical; unknown ignored
? 12 : { * uint => any }, ; cext: critical; unknown => reject
}
effect = &( read_only:0, idempotent_write:1,
non_idempotent_write:2, destructive:3 )
profile = &( public:1, enterprise:2, sovereign:3 )
4.3. Content identity
The id (field 1) is multihash(0x20, SHA-384(C)) where C is the
deterministic CBOR encoding of the body with field 1 removed, and
0x20 is the multiformats code for SHA-384. A verifier recomputes the
content id and MUST reject a mismatch (ContentIdMismatch). Because
the id binds the exact bytes, altering any field changes the id.
Sammartano Expires 28 January 2027 [Page 5]
Internet-Draft N-AALP July 2026
4.4. Extensions and versioning
Field 11 (ext) carries non-critical extensions a verifier that does
not recognize them MUST ignore. Field 12 (cext) carries critical
extensions a verifier that cannot honor them MUST reject the whole
object (fail-closed). Higher channel tiers add capability solely
through these fields and the tier field; the envelope does not change
across versions or tiers.
5. Cryptographic Constructions
5.1. Signing
An object is signed with COSE_Sign1 [RFC9052] over the deterministic-
CBOR object body as the payload. The protected header carries the
COSE algorithm and a pre-parse routing copy of the signer, profile,
and protocol version under a text-string label. A verifier MUST
reject an object whose header signer/profile copies disagree with
body fields 5 and 9 (HeaderBodyMismatch). On the wire the object is
a tagged COSE_Sign1 (CBOR tag 18); the optional hybrid uses tagged
COSE_Sign (tag 98) and is accepted only if all its signatures verify.
5.2. Algorithms and profiles
The mandatory-to-implement signature algorithm is ML-DSA [FIPS204]
using the deterministic variant (rnd = 0) so two implementations
produce byte-identical signatures. The classical hybrid leg is
Ed25519 [RFC8032]. Within the COSE algorithm framework [RFC9053],
the algorithm identifiers are those registered for ML-DSA [RFC9964]
and Ed25519 [RFC9864]; N-AALP does not define new COSE algorithm code
points and reuses the existing IANA COSE Algorithms registry. Three
profiles select a signature floor:
+============+=======+==========================+
| profile | value | signature floor |
+============+=======+==========================+
| public | 1 | ML-DSA-65 (NIST level 3) |
+------------+-------+--------------------------+
| enterprise | 2 | ML-DSA-65 (NIST level 3) |
+------------+-------+--------------------------+
| sovereign | 3 | ML-DSA-87 (NIST level 5) |
+------------+-------+--------------------------+
Table 1
Sammartano Expires 28 January 2027 [Page 6]
Internet-Draft N-AALP July 2026
A verifier for a profile MUST reject a signature below the profile's
floor (ProfileDowngrade) and an unknown algorithm (UnknownAlg). The
optional Ed25519+ML-DSA hybrid (COSE_Sign) is accepted only when both
legs verify (HybridIncomplete otherwise). Digests use SHA-384
[FIPS180].
6. Identity
The signer id (object field 5) is self-certifying: multibase(base32,
multihash(0x12, SHA-256(multicodec(mc, pubkey)))), identical in form
to the N-PAMP PeerHandle, where mc is the multiformats key-type code
(0xed ed25519-pub, 0x1211 mldsa-65-pub, 0x1212 mldsa-87-pub). A
verifier recomputes the id from the key and MUST reject a mismatch
(SignerMismatch). No certificate authority is involved.
Key lifecycle records are signed with the same COSE crypto: a
Rotation is co-signed by both the old and new key; a Revocation is
signed by the revoked key or a recovery key; a foreign-identity link
is cross-signed by the foreign identity's key. Identity strings that
carry human text MUST be Unicode NFC (NonNFC otherwise). A receipt
signed under a superseded key remains attributable to the durable
identity thread across rotations.
7. Effects and Authorization
Every object carries, under signature, one value from a closed four-
value effect vocabulary aligned 1:1 with the N-PAMP Bridge
SafetyLabel: read_only (0), idempotent_write (1),
non_idempotent_write (2), destructive (3). The values form a lattice
with destructive at the top.
An unrecognized effect value MUST be treated as destructive and MUST
NOT fail open. Unlike a SafetyLabel that "describes intent and does
not replace authorization", the N-AALP effect IS an authorization
input: an endpoint grants a maximum effect (a capability) to an
authenticated signer id, and an object is authorized only if its
effect does not exceed the grant (EffectNotAuthorized otherwise). No
layer MUST treat transport metadata, a foreign header, or a client-
supplied name as an authorization identity; the authorizing principal
is the object's signature-verified signer id.
An object MAY carry an optional signed safety label (a non-critical
ext) { risk, scope }; it is an accountable claim attributable to the
signer, not a guarantee that the content is safe.
Sammartano Expires 28 January 2027 [Page 7]
Internet-Draft N-AALP July 2026
8. Approval
An Approval object binds, under signature, the content id of the
exact canonical argument object it approves, so approving one action
cannot authorize another (ApprovalMismatch if the args are mutated).
It carries the approver signer id, the granted effect, an anti-replay
nonce, and an expiry.
The consume ledger is a durable, hash-chained set keyed by approval
content id. Consume is an atomic compare-and-set: the first consumer
appends a ledger entry and wins; a second consume for the same
approval id is rejected (AlreadyConsumed). Atomicity is provided by
a write-ahead log written before the acknowledgment and a single-
writer-per-approval-id discipline; under concurrency exactly one
consumer succeeds. An approval past its expiry is rejected
(ApprovalExpired). An approval-required-but-not-granted outcome is a
distinct signed non-success result, never a silent success or denial.
9. Audit, Causal Graph, and Ordering
An ordering authority records each accepted object by appending a
signed Receipt { prev, obj, seq, at } where prev is the SHA-384 of
the previous receipt body (genesis is zero) and obj is the object
content id. The chain is tamper-evident: reordering, omission, or
substitution breaks a prev link or a seq (ChainBroken). The
authority MUST NOT mutate the origin object to order it; ordering is
an outer signed layer.
Every object MAY name its causes by content id (field 8). This is a
signed partial order: an edge "A causes B" is proven by B's signature
over A's content id, checkable offline with no ordering authority
present. An object MUST NOT name a cause it could not have seen (a
cause whose ordering position exceeds the effect's, or a cycle),
which is rejected (CausalViolation). A total order is a policy
layered over this partial order.
An independent auditor detects equivocation -- two receipts by one
authority at one seq naming different objects -- from the signed
receipts alone (Equivocation). A receipt whose signature does not
verify is rejected (ReceiptUnsigned).
Ordering is tiered. The baseline tier is a single authority's
monotonic receipt chain. The higher tier is federated: multiple
independent authorities each order their own scope and reconcile
deterministically over the shared causal graph (a topological
linearization tie-broken by content id). Because the merge depends
only on the causal graph, both tiers order the identical signed
objects and moving to federated ordering requires no envelope change.
Sammartano Expires 28 January 2027 [Page 8]
Internet-Draft N-AALP July 2026
10. Delivery
Delivery is four distinct, monotonic, separately-observable stages,
each a signed delivery update naming the object content id and the
stage reached: persisted_origin (0), accepted_relay (1),
persisted_target (2), presented (3). There is no single "sent" flag.
An endpoint MUST durably persist an object before emitting the
acknowledgment that advances its stage (persist-before-acknowledge),
so a crash immediately after an acknowledgment loses nothing. A
stage earlier than the one already reached is rejected
(StageOutOfOrder). A relay that holds an object only in transit MAY
write an audit trail over content ids while retaining no payload.
11. Streaming
A native stream is three signed objects plus unsigned chunks.
StreamOpen binds the stream identity, effect, and (where it causes an
effect) approval; a stream whose effect is not authorized is refused
before any chunk. Chunks are raw data frames the transport
authenticates; they are not individually signed. StreamCommit
carries a single rolling SHA-384 over the chunks in absolute-offset
order, making the whole stream non-repudiable with one signature;
altering any delivered byte invalidates it (StreamDigestMismatch).
Optional signed StreamCheckpoints let a verifier confirm a prefix
without the end. The same three objects map onto QUIC streams,
WebSocket messages, and HTTP chunked/event streams; the commitment
verifies identically across transports.
12. Transport Bindings
A binding carries exactly one signed object as one message unit, with
identical object semantics over N-PAMP, QUIC, WebSocket, and HTTP.
The object is self-secured; the binding adds only framing and, from
the transport, confidentiality and connection authentication. The
media type is application/naalp+cbor (one object per representation).
The confidentiality boundary is normative: an object marked sensitive
MUST NOT be emitted in cleartext over a non-confidential transport;
the binding refuses it (ConfidentialTransportRequired) and directs
the deployment to a confidential transport. A transport lacking peer
authentication where policy requires it is refused
(PeerUnauthenticated).
13. Foreign Carriage by Class
N-AALP carries a foreign agent protocol by wrapping its message,
octet-for-octet, in a signed carriage object interpreted by a
carriage class:
Sammartano Expires 28 January 2027 [Page 9]
Internet-Draft N-AALP July 2026
naalp-carriage-body = {
1 : uint, ; protocol_id (N-AALP protocol registry)
2 : carriage-class, ; 0 JSONRPC .. 5 OPAQUE
3 : uint, ; content_type (foreign encoding)
4 : bstr, ; correlation token
5 : tstr, ; method (advisory routing key)
6 : bstr, ; foreign message, carried octet-for-octet
}
carriage-class = &( jsonrpc:0, http:1, msg:2,
stream:3, doc:4, opaque:5 )
The foreign field is carried verbatim and MUST NOT be re-serialized,
canonicalized, summarized, or rewritten. The carriage object's
signer remains the authority: a foreign protocol's identity, header,
or metadata MUST NOT become an N-AALP authorization identity. The
OPAQUE class carries any protocol, including an undefined one, on an
experimental protocol id with no registration. A below-foreign
failure uses a defined structured error and MUST NOT report an
undelivered message as delivered; an N-AALP semantic a foreign
protocol cannot represent surfaces a typed mapping error, never a
silent drop.
14. Channel Surfaces
N-AALP defines twenty channel surfaces (channel ids 0x0000..0x0013):
Control, Memory, Capability, Identity, Governance, Immune,
Federation, Settlement, Compliance, Sensory, Telemetry, Audit,
Stream, Bridge, Commerce, Interaction, Discovery, Workflow,
Knowledge, and Spatial. Each surface adds only object kind codes and
their declared effects over the one object model; it introduces no
channel-local encoding, signature, or identity. Every channel has a
complete frozen baseline surface. Higher tiers add capability under
the frozen envelope through the tier field and critical/non-critical
extensions. The complete kind/effect table is the N-AALP Channel and
Object Kind registries (# IANA Considerations).
15. Security Considerations
Mandatory-to-implement algorithms and post-quantum rationale: N-AALP
signs with ML-DSA [FIPS204], a post-quantum signature, because N-AALP
objects (receipts, approvals, audit chains) are long-lived non-
repudiable records subject to store-now-verify-later forgery risk
from a future cryptographically relevant quantum computer; a
classical-only signature on such records would be a latent forgery
exposure. An optional Ed25519 hybrid provides defense-in-depth
during the transition and is accepted only when both legs verify.
Sammartano Expires 28 January 2027 [Page 10]
Internet-Draft N-AALP July 2026
Downgrade and negotiation: algorithm agility is expressed by the COSE
algorithm identifier bound under the signature and checked against
the profile floor; a signature below the floor is rejected, so
agility cannot become a downgrade.
Replay and reordering: approvals bind a nonce and expiry and are
single-use through the consume ledger; the audit receipt chain binds
each object into a hash chain so reordering, omission, and
substitution are detectable; delivery stages are monotonic.
Identity and trust: the signer id is a pure function of the public
key, so a forged id cannot recompute; there is no certificate
authority to compromise. Compromise of a signing key is bounded by
rotation and revocation, and attribution survives rotation. A non-
injective or forgeable identity function would collapse this
property; the SHA-256 multihash over the multicodec-tagged key
provides collision and second-preimage resistance.
Effect and authorization: the effect is an authorization input, not a
hint; an unrecognized effect fails closed to destructive;
authorization is never derived from transport metadata or a foreign
principal. This closes the gap a pure intent label leaves open.
Denial of service: an object requires one signature verification and
one deterministic decode; verification is fail-closed and performed
before any state change or effect. Streaming amortizes one signature
over many chunks. Implementations SHOULD bound object and stream
sizes by policy.
Confidentiality: object-level guarantees do not include
confidentiality; a sensitive object MUST use a confidential transport
(# Transport Bindings), enforced by refusal.
What N-AALP does NOT defend against: it does not provide
confidentiality by itself (that is the transport's); it cannot force
an ordering authority to deliver events it chooses to withhold (a
chain reveals equivocation and omission-of-known-events but cannot
compel delivery); it does not police the semantic correctness of a
carried foreign message beyond octet-exact carriage; and it does not
defend against a signer that is itself authorized and malicious (it
makes that signer's actions attributable and auditable, not
impossible).
Sammartano Expires 28 January 2027 [Page 11]
Internet-Draft N-AALP July 2026
16. IANA Considerations
This document is an Independent Submission. All registries requested
below use registration policies that do not require IETF Review or
Standards Action, consistent with the Independent stream: media-type
registration under [RFC6838], and per-registry Specification Required
with a Designated Expert per [RFC8126]. Numeric values shown are the
values this specification defines; where IANA assignment is requested
the placeholder TBD is used.
16.1. Media type application/naalp+cbor
IANA is requested to register the following media type in the
standards tree per [RFC6838], using the +cbor structured syntax
suffix defined in [RFC8949] and registered in the IANA Structured
Syntax Suffixes registry (whose mechanism is established by [RFC6838]
and populated by [RFC6839]):
* Type name: application
* Subtype name: naalp+cbor
* Required parameters: none
* Optional parameters: none
* Encoding considerations: binary (CBOR per [RFC8949])
* Security considerations: see (# Security Considerations) of this
document
* Interoperability considerations: objects are deterministic CBOR;
see (# Object Model)
* Published specification: this document
* Applications that use this media type: autonomous-agent
application-layer messaging
* Fragment identifier considerations: as specified for application/
cbor
* Additional information: Magic number(s): none; File extension(s):
.naalp; Macintosh file type code(s): none
* Person & email address to contact for further information: the
author (front matter)
Sammartano Expires 28 January 2027 [Page 12]
Internet-Draft N-AALP July 2026
* Intended usage: COMMON
* Restrictions on usage: none
* Author: S. Sammartano
* Change controller: the author (BubbleFish Technologies, Inc.)
16.2. N-AALP Channel registry
IANA is requested to create the "N-AALP Channels" registry.
Registration policy: Specification Required (a Designated Expert
confirms a stable public specification and non-collision). Columns:
Channel Id (uint 0..19), Name, Reference. Initial contents: the
twenty channels of (# Channel Surfaces), ids 0x0000..0x0013, this
document.
16.3. N-AALP Object Kind registries
IANA is requested to create, per channel, an "N-AALP Object Kinds
(channel N)" registry. Registration policy: Specification Required.
Columns: Kind Code (uint), Name, Effect (one of the four closed
effect names, or "variable"), Reference. Initial contents: the
sixty-five baseline kinds of this document.
16.4. N-AALP Effect registry
IANA is requested to create the "N-AALP Effects" registry.
Registration policy: Specification Required (this closed set is not
expected to grow; additions require a stable specification and MUST
preserve the fail-closed lattice). Columns: Value (0..3), Name,
Reference. Initial contents: read_only 0, idempotent_write 1,
non_idempotent_write 2, destructive 3, this document.
16.5. N-AALP Carriage Protocol Id registry
IANA is requested to create the "N-AALP Carriage Protocol Ids"
registry, a one-octet space partitioned: standards 0x01-0x0F
(Specification Required), experimental 0x10-0x7F (no registration),
private 0x80-0xFF (no registration). Columns: Protocol Id, Name,
Carriage Class, Reference. Initial standards-range contents: 0x01
MCP (JSONRPC), 0x02 A2A (JSONRPC), 0x03 HTTP (HTTP), 0x04 WebSocket
(STREAM), this document.
Sammartano Expires 28 January 2027 [Page 13]
Internet-Draft N-AALP July 2026
16.6. N-AALP Error Code registry
IANA is requested to create the "N-AALP Error Codes" registry.
Registration policy: Specification Required. Columns: Name,
Retryable, Reference. Initial contents: the named errors of this
document (ContentIdMismatch, HeaderBodyMismatch, UnknownCriticalExt,
UnknownKind, RangeError, NonCanonical, NonNFC, ProfileDowngrade,
UnknownAlg, HybridIncomplete, BadSignature, SignerMismatch,
RotationUnauthorized, KeyRevoked, EffectNotAuthorized,
UnauthenticatedPrincipal, ApprovalMismatch, ApprovalExpired,
AlreadyConsumed, ApprovalRequired, ChainBroken, Equivocation,
CausalViolation, ReceiptUnsigned, StageOutOfOrder,
StreamDigestMismatch, ConfidentialTransportRequired,
PeerUnauthenticated, NotDelivered, MappingError,
ScopeOverlapConflict, CapExceedsParent, TransformCycle,
InputGateBypass).
16.7. COSE algorithms
N-AALP reuses the existing IANA COSE Algorithms registry for ML-DSA
[RFC9964] and Ed25519 [RFC9864] and requests no new COSE code points.
16.8. Designated Expert guidance
For each Specification-Required registry the Designated Expert
confirms: (1) a stable, publicly available specification documents
the value; (2) the value does not collide with an existing entry; (3)
the name is protocol-neutral and carries no vendor product name; and
(4) for object kinds, the declared effect is one of the closed set
and preserves the fail-closed model.
17. Implementation Status
RFC-Editor: please remove this section and the reference to [RFC7942]
before publication.
This section records the status of known implementations at the time
of posting, per [RFC7942]. Listing here does not imply endorsement.
Two independent reference implementations exist, in Go and in Rust,
from a single codebase but separate language runtimes. For every
construction carrying a security or interoperability claim
(deterministic CBOR and content id; COSE_Sign1 and the ML-DSA/Ed25519
profiles; the object envelope; signer id; effect authorization;
approval and the consume ledger; audit chain, causal graph, and
federated reconcile; delivery; streaming; transport bindings; foreign
carriage; and the twenty channel surfaces), the two implementations
produce byte-identical output and are cross-validated against an
Sammartano Expires 28 January 2027 [Page 14]
Internet-Draft N-AALP July 2026
independent oracle whose expected values come from the relevant RFC,
FIPS, or NIST vector or a from-scratch constructor, never from the
implementation under test. A runnable conformance harness grades
every construction and validates the CDDL module against the
committed vectors. Coverage and known gaps are tracked in the
project's parity ledger.
18. Conformance
A conforming implementation MUST implement the object model, the
signing constructions, identity, effects and authorization, and the
baseline surfaces of every channel, and MUST reject a non-conforming
object whole with its named error and no state change (fail-closed).
Conformance is demonstrated against the machine-gradable vector
corpus and the CDDL module (Appendix A). This specification
recommends, but does not require for Independent-stream publication,
two independent interoperating implementations; two exist (#
Implementation Status).
19. Specification License
This specification may be implemented by anyone, royalty-free. This
right to implement is granted independently of the license of any
reference implementation (the reference code is licensed separately).
Contributions to this document are subject to BCP 78 and the IETF
Trust's Legal Provisions Relating to IETF Documents.
20. References
20.1. Normative References
[FIPS180] National Institute of Standards and Technology, "Secure
Hash Standard (SHS) (FIPS 180-4)", 2015.
[FIPS204] National Institute of Standards and Technology, "Module-
Lattice-Based Digital Signature Standard (FIPS 204)",
2024.
[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>.
[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://www.rfc-editor.org/rfc/rfc6838>.
Sammartano Expires 28 January 2027 [Page 15]
Internet-Draft N-AALP July 2026
[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/rfc/rfc8032>.
[RFC8126] 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://www.rfc-editor.org/rfc/rfc8126>.
[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>.
[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://www.rfc-editor.org/rfc/rfc8610>.
[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/rfc/rfc8949>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/rfc/rfc9052>.
[RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
August 2022, <https://www.rfc-editor.org/rfc/rfc9053>.
[RFC9864] Jones, M.B. and O. Steele, "Fully-Specified Algorithms for
JSON Object Signing and Encryption (JOSE) and CBOR Object
Signing and Encryption (COSE)", RFC 9864,
DOI 10.17487/RFC9864, October 2025,
<https://www.rfc-editor.org/rfc/rfc9864>.
[RFC9964] Prorock, M. and O. Steele, "ML-DSA for JSON Object Signing
and Encryption (JOSE) and CBOR Object Signing and
Encryption (COSE)", RFC 9964, DOI 10.17487/RFC9964, May
2026, <https://www.rfc-editor.org/rfc/rfc9964>.
20.2. Informative References
Sammartano Expires 28 January 2027 [Page 16]
Internet-Draft N-AALP July 2026
[NPAMP] Sammartano, S., "N-PAMP: Native Post-Quantum Agent
Messaging Protocol", Work in Progress, Internet-Draft,
draft-bubblefish-npamp (work in progress), 2026,
<https://datatracker.ietf.org/doc/html/draft-bubblefish-
npamp (work in progress)>.
[RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type
Structured Syntax Suffixes", RFC 6839,
DOI 10.17487/RFC6839, January 2013,
<https://www.rfc-editor.org/rfc/rfc6839>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/rfc/rfc7942>.
Appendix A. Collected CDDL
The complete, machine-validated CDDL module is maintained with the
reference implementation as spec/naalp-draft-00.cddl and is normative
for the byte-level wire format. It is validated for well-formedness
and against the conformance vectors by the project's conformance
harness. The object body, effect, and profile productions of (#
Object Model) and the carriage body of (# Foreign Carriage by Class)
are reproduced there in full, together with the COSE wrapper,
protected header, identity records, safety label, approval and
consume records, receipt, delivery update, stream objects, and the
federated reconcile record.
Appendix B. Acknowledgments
N-AALP builds on the N-PAMP substrate.
Author's Address
Shawn Sammartano
BubbleFish Technologies, Inc.
Email: naalp-editor@bubblefish.sh
Sammartano Expires 28 January 2027 [Page 17]