UHP vs N-AALP / N-PAMP
UHP standardizes complete-harness task and session execution. N-AALP proposes signed, effect-labeled application objects, while N-PAMP proposes the post-quantum multi-channel messaging substrate beneath them.
Page reviewed 4 Oct 2026 Source and review policy
Match each security requirement to its layer
Section titled “Match each security requirement to its layer”The N-AALP -01 and N-PAMP -02 documents remain individual Internet-Drafts; both are work in progress rather than RFCs. They were reopened alongside UHP 2026-09-28 Draft on 4 October 2026.
| Requirement | Relevant contract | Separate decision |
|---|---|---|
| Run a complete harness and retain its session/files | UHP | Server admission and runtime policy |
| Carry a signed application effect/approval object | N-AALP proposal | Verify the object and decide whether local policy admits its effect |
| Protect a multiplexed agent association | N-PAMP proposal | Authenticate peers and select acceptable cryptographic profiles |
| Carry foreign MCP/A2A material | Explicit carriage profile | Preserve the foreign protocol’s semantics and authorization |
A useful negative fixture presents a correctly protected N-PAMP frame containing an application action outside the recipient’s authority. The transport can authenticate the association while the application rejects the action. A second fixture presents an authentic N-AALP object whose effect requires approval that is absent. Both should fail at the layer responsible for authority.
These are proposed verifier fixtures, not executed conformance results. Post-quantum transport protection does not prove safe tool execution, and an N-AALP signature does not prove the declared effect accurately describes an implementation’s real behavior. Runtime attestation and tool-call finality address distinct evidence questions. A UHP deployment need not implement either proposed substrate to conform to UHP.
The one-sentence difference
Section titled “The one-sentence difference”UHP standardizes how a product asks a server to execute work through a selected, configured complete agent harness; N-AALP proposes how consequential agent application objects carry signed identity, effect, approval and audit semantics, while N-PAMP proposes a post-quantum multi-channel wire substrate for carrying agent traffic.
These are different architectural planes. A deployment could use UHP for the product-to-harness execution contract while separately using N-AALP objects or N-PAMP transport inside, beside or downstream of the harness. None of the primary sources reviewed establishes a standardized UHP binding or native HarnessRouter integration for either proposal.
Current status
Section titled “Current status”The current observed N-AALP revision is draft-bubblefish-naalp-01, dated 6 September 2026. The IETF Datatracker lists it as an active individual Internet-Draft, states that it is not endorsed by the IETF and has no formal standing in the IETF standards process, and currently shows no RFC stream. The document header says Intended status: Informational and expires 10 March 2027 unless updated or replaced.
The current observed N-PAMP revision is draft-bubblefish-npamp-02, also dated 6 September 2026. Datatracker likewise lists it as an active individual Internet-Draft with no RFC stream and no IETF endorsement; its document header also says Intended status: Informational and expires 10 March 2027.
Two layers in one proposed stack
Section titled “Two layers in one proposed stack”The two drafts deliberately separate application semantics from transport mechanics.
N-AALP (Native Agentic Application Layer Protocol) makes the object the unit of security and governance. Its objects are deterministically encoded CBOR structures signed with COSE. Under one signature, an object can bind content identity, signer identity, a closed effect label, approval/audit relationships and causal derivation. The draft defines object state machines, delivery stages, streaming, transport bindings and foreign-protocol carriage by class.
N-PAMP (Native Post-Quantum Agent Messaging Protocol) sits below application protocols. It defines a binary multi-channel wire format, fixed-size frame header, channel multiplexing, security-profile negotiation, hybrid X25519 + ML-KEM key establishment, authenticated encryption and a forward-secure key schedule. Revision -02 names QUIC as the primary transport, TCP with TLS 1.3 as fallback and n-pamp/3 as the ALPN identifier.
N-AALP explicitly says it can ride N-PAMP but does not require it: the same signed application object can also be carried over QUIC, WebSocket or HTTP. That separation is important when comparing the proposals with UHP, because UHP is itself an HTTP execution contract rather than a replacement wire-security protocol.
N-AALP’s key idea: signed effect as an authorization input
Section titled “N-AALP’s key idea: signed effect as an authorization input”N-AALP’s most distinctive boundary is not merely message signing. Its application envelope makes an object’s declared effect part of the governed signed object.
The reference repository exposes a closed four-value effect vocabulary:
read_onlyidempotent_writenon_idempotent_writedestructive
Unknown effects fail closed to destructive, and the project describes the effect as an authorization input rather than a hint. The proposal also defines self-certifying signer identity, content addressing, single-use approvals, receipt/audit chaining and causal relationships.
UHP has a different responsibility. It defines server-owned Responses and Sessions, lifecycle/events, continuation, cancellation, files/artifacts and complete-harness execution. UHP security requirements still matter, but UHP 2026-09-28 does not turn every application object into an N-AALP-style deterministic CBOR + COSE governance envelope.
Foreign-protocol carriage is wrapping, not adoption
Section titled “Foreign-protocol carriage is wrapping, not adoption”N-AALP includes foreign-protocol carriage by class. The draft can carry foreign payload bytes inside its governed signed envelope and defines additive families involving MCP tool calls and A2A task transitions.
That must not be overstated. The draft itself says it does not replace the foreign protocols it carries. The repository’s A2A material treats the task-state vocabulary as imported carriage rather than adoption, and a wrapped MCP/A2A payload does not make MCP or A2A identity automatically become N-AALP authorization identity.
The same boundary applies to UHP. An implementation could theoretically carry UHP-related payload material inside another signed envelope, but no current primary source defines a standard UHP ↔ N-AALP carriage profile. Foreign-protocol carriage support should therefore not be reported as native UHP adoption.
N-PAMP’s boundary is below UHP
Section titled “N-PAMP’s boundary is below UHP”N-PAMP addresses a wire/association problem that UHP deliberately does not own. Its current draft defines:
- a fixed 36-octet frame header;
- multiplexed semantic channels with independent sequence spaces;
- Standard, High and Sovereign security profiles;
- hybrid classical/post-quantum key establishment using X25519 plus ML-KEM;
- AEAD-protected payloads and forward-secure key updates;
- QUIC primary carriage and TCP/TLS 1.3 fallback;
- ALPN
n-pamp/3for the current cryptographic generation.
The draft explicitly says it does not define application-layer semantics and is not a general-purpose VPN. UHP, by contrast, defines application-level harness execution objects over HTTP/TLS and leaves the server-to-harness mechanism implementation-defined.
A UHP server therefore does not need N-PAMP to conform to UHP, and an N-PAMP endpoint does not become a UHP server merely because it provides a secure agent transport.
Architectural comparison
Section titled “Architectural comparison”| Dimension | UHP | N-AALP | N-PAMP |
|---|---|---|---|
| Primary concern | Complete-harness task/session execution | Signed, governed application objects | Agent messaging wire substrate |
| Current status | 2026-09-28 Draft with runnable conformance | draft-bubblefish-naalp-01, active individual I-D | draft-bubblefish-npamp-02, active individual I-D |
| Main boundary | Product/client ↔ UHP server ↔ configured harness | Agent/application object ↔ verifier/governance policy | Agent endpoint ↔ agent endpoint secure association |
| Core unit | Response / Session / event / file | Deterministic signed object | Binary frame / channel / association |
| Encoding | HTTP API objects; JSON/SSE surfaces | Deterministic CBOR + COSE signed object | Binary fixed-header frame + protected payload |
| Authorization emphasis | Server/principal/object and harness execution policy | Closed signed effect + approvals/capabilities/audit | Transport authentication, negotiated crypto profiles and channel protection |
| Lifecycle | Normative task/session continuation, cancellation, events and artifacts | Object/delivery/stream/approval/reconcile state machines | Association, handshake, channels, key update and close |
| Transport | HTTP over TLS; SSE for streaming | N-PAMP, QUIC, WebSocket or HTTP bindings | QUIC primary; TCP + TLS 1.3 fallback |
| PQ cryptography | Not a UHP protocol requirement | ML-DSA profile proposed for object signatures | X25519 + ML-KEM hybrid establishment and PQ-aware profiles |
| MCP/A2A relationship | Separate protocols; no implicit adoption | Foreign carriage/additive bindings proposed | Can carry application traffic; does not define its semantics |
| UHP conformance | Dedicated current 85-check suite | Separate project corpus; not UHP conformance | Separate project tests; not UHP conformance |
Reference implementation evidence is project evidence
Section titled “Reference implementation evidence is project evidence”The N-AALP repository is substantially more concrete than a prose-only proposal. At the checked cutoff it publishes reference implementations in ten languages and describes a 565-case conformance corpus, deterministic cross-language ML-DSA checks and byte-parity gates. The repository also contains integration packages for neighboring protocols and frameworks.
That is useful implementation evidence, but its scope must stay precise. The implementations, vectors and ecosystem packages are maintained within the same N-AALP project. They do not establish independent multi-vendor adoption, IETF consensus, UHP conformance or a production UHP↔N-AALP interoperability profile.
Similarly, N-PAMP publishes its own tagged draft and implementation line. Passing N-PAMP’s project tests would establish behavior against that proposal, not UHP’s separate conformance suite.
Where the layers could coexist
Section titled “Where the layers could coexist”A plausible architecture could compose the boundaries without merging them:
- A product submits a UHP Response to a UHP server selecting a configured complete harness.
- The UHP server owns task/session lifecycle, streaming, cancellation, files and artifacts.
- The harness produces or consumes a consequential inter-agent object.
- That object is represented as an N-AALP signed, effect-labeled object for downstream verification or governance.
- The object is carried over HTTP/QUIC directly, or over an N-PAMP association when that substrate is selected.
- UHP results remain UHP protocol objects; N-AALP signatures/approvals/audit and N-PAMP transport evidence remain evidence at their own layers.
This is an architectural composition example only. No standardized UHP↔N-AALP mapping, UHP-over-N-PAMP profile, HarnessRouter N-AALP/N-PAMP backend, or native UHP adoption by the BubbleFish projects was verified.
What not to infer
Section titled “What not to infer”Related pages
Section titled “Related pages”Read UHP architecture and Security for UHP’s own execution boundary, UHP vs MCP for tool/context interoperability, UHP vs A2A for agent-to-agent task communication, UHP vs Agent Authorization Envelope for portable action authorization, and Agent Control Delivery Evidence for evidence that a control reached and affected its intended target.