N-AALP: The Native Agentic Application Layer Protocol

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

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

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

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

4. Object Model

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 )

5. Cryptographic Constructions

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

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

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

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

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

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

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

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