UHP vs Signed Agent Identity Protocol (SAIP)

Separate identity verification from execution admission

The SAIP -11 draft remains an individual Internet-Draft in the official source reopened 4 October 2026. Its request identity signal is complementary to UHP 2026-09-28 Draft’s authenticated execution boundary.

Gate	Result to retain	What it cannot replace
Parse the assertion under the selected draft	Required fields and algorithm/model selection	Cryptographic verification
Verify freshness and replay policy	Timestamp/nonce decision	Permission to run the requested work
Verify request binding/signature	Which declared agent signed which request material	A trustworthy or safe agent implementation
Apply local authorization	Allowed action and resource scope	Actual execution completion

For a UHP-facing gateway, verify the identity signal before mapping it to a local principal. Then apply harness and object-access policy. A signature from a recognized publisher must not automatically authorize retrieval of another principal’s Session or artifacts. UHP security remains the source for those execution-resource rules.

A suggested fixture replays the same signed request and then presents a fresh valid request for an unauthorized object. These fail for different reasons and should remain distinguishable in logs without retaining reusable credentials. The current VICDM record still identifies revision -10, freshly checked on 4 October 2026; its delegation model and SAIP’s wire protocol remain separate scopes.

The one-sentence difference

UHP standardizes how a client asks a server to run a selected, configured complete harness; SAIP standardizes a cryptographic identity signal that lets a receiver verify which automated software agent is making an application-layer request.

The two protocols therefore address different trust boundaries. A UHP Response or Session is an execution object with lifecycle, workspace and event semantics. A SAIP identity assertion is a request-level identity signal authenticated with the cryptographic model named in alg. SAIP explicitly separates identification from authorization, so successful SAIP verification does not itself grant permission to perform an action.

Current SAIP status

The current observed revision is draft-jovancevic-saip-11, dated and last updated in the IETF Datatracker on 7 September 2026. It is an active individual Internet-Draft, not an IETF standard and not endorsed by the IETF. The Datatracker shows no RFC stream and no Intended RFC status, while the document header itself says “Intended status: Standards Track.” That author-declared intent does not give the draft standards standing. The draft expires 11 March 2027 unless replaced or refreshed.

Revision -11 describes itself as a reviewed and corrected revision: it fixes late typographical, editorial and consistency errors and clarifies protocol descriptions while stating that no change to SAIP’s architecture, trust model or intended security properties is intended.

SAIP is built around the separate Verifiable Identity Claims and Delegation Model (VICDM). The preserved September VICDM snapshot was draft-jovancevic-vicdm-10, then an active individual Internet-Draft last updated 28 August 2026. VICDM is a conceptual identity/delegation model; SAIP is a concrete protocol implementation of those principles.

What SAIP defines

SAIP is deliberately lightweight and protocol-agnostic. Its draft targets HTTP, SMTP and other header-based protocols without replacing their existing application semantics.

For HTTP, the core signal is a structured SAIP header carrying an agent identifier, alg, timestamp, nonce and sig, with optional public-key and telemetry fields. The recommended identifier shape is vendor-domain.type.instance; revision -11 makes the vendor component a registrable DNS domain that can be used directly to build the _saip.<vendor-domain> discovery name. The draft defines canonical request material and a processing model that validates required fields, freshness and nonce handling before verifying the request with the model named in alg and then applying local policy.

Four design points are especially relevant to agent infrastructure:

• Explicit cryptographic-model selection. alg names the algorithm/model actually used by the request: ed25519 for the DNS-Native and stateless pk= public-key models, ecdsa-p256 as the specified hardware fallback where Ed25519 is unavailable, and hmac-sha256 for the symmetric RKDF model. These are alternatives within SAIP; a verifier reads the model from the request rather than assuming one.
• RKDF is a symmetric per-request MAC model. In RKDF mode, a Rolling Key is derived with HMAC-SHA256 from the shared MasterKey and instance/sequence state, authenticates exactly one request, and is then destroyed. Verification requires a party that holds or can reach the MasterKey through the Registration Entity. This is distinct from the asymmetric DNS-Native/stateless pk= paths, where verification can use public-key material.
• Multiple public-key discovery paths. For the asymmetric models, the current priority order is an explicit pk= key in the request, DNS-based Attestation Discovery under _saip.<vendor-domain>, then Registration Entity lookup. A server may stop after finding a valid key and must reject the asserted identity if no valid key can be established through an available method. The RKDF hmac-sha256 path does not perform public-key discovery; it derives or retrieves the Rolling Key state through the RE.
• Identity is not authorization. SAIP says its result answers who the automated agent is. Authorization remains with mechanisms such as OAuth 2.0, JWT-based application policy, ACLs or other access-control systems.

The RKDF sequence model uses a bounded look-ahead window and SAIP-Next-Seq after successful verification. The optional tm telemetry field is explicitly opt-in and commitment-based; its construction follows the selected cryptographic model, and raw metadata must not simply be exposed in that field. SAIP also does not claim anonymity: a verified id intentionally creates an attributable identity signal, while the draft treats privacy-preserving anonymous bot authentication as a complementary approach.

Architectural comparison

Dimension	UHP	SAIP
Primary concern	Execute a configured complete harness through a common server contract	Verify the identity of an automated software agent making a request
Current status	UHP 2026-09-28 Draft	draft-jovancevic-saip-11, active individual Internet-Draft
Main boundary	Product/client ↔ UHP server ↔ harness runtime	Automated client/agent ↔ receiving application or service
Core objects/signals	Harnesses, Responses, Sessions, Containers, Files and streamed Events	Signed/MACed identity header, instance identity, algorithm model, key/sequence state and discovery records
Lifecycle semantics	Normative task/session execution and continuation	No replacement for UHP task/session lifecycle
Identity scope	UHP authenticates its server endpoints and scopes objects to the authenticated principal	SAIP adds a portable cryptographic identity assertion for the automated requester itself
Authorization	UHP server authorization/object-scope rules apply at the UHP boundary	Explicitly out of scope as a grant mechanism; SAIP identity feeds separate authorization policy
Transport/application role	HTTP resource API plus SSE event streaming	Application-layer identity signal designed to coexist with HTTP, SMTP and similar protocols
Replay/key controls	UHP defines its own authentication, transport and object-security requirements	Timestamp/nonce checks plus algorithm-selected asymmetric verification or symmetric RKDF sequence/key controls
Conformance relationship	UHP has a dedicated conformance suite	SAIP does not become UHP conformance by being present in the same deployment

Where UHP and SAIP could coexist

A deployment can conceptually use both without collapsing their scopes:

1. A product authenticates to a UHP server and creates a task against a configured harness.
2. The UHP server owns the UHP Response, Session, workspace, files and event lifecycle.
3. The running harness or one of its downstream automated components makes an HTTP request to another service.
4. If that component and receiver implement SAIP, the downstream request can carry a SAIP identity assertion using the selected SAIP cryptographic model.
5. The receiving service verifies that identity and then applies its own authorization or policy rules.

That composition is an architecture possibility, not a standardized binding. No UHP ↔ SAIP binding is defined by the current UHP or SAIP sources reviewed here, and no native HarnessRouter SAIP integration is established by this review.

UHP already protects its server boundary, but that is a different identity problem

UHP 2026-09-28 requires authentication on every endpoint except discovery (GET /v1/uhp), scopes server objects to the principal that created them, requires cross-scope object requests to return 404, protects provider credentials, and requires TLS except on loopback.

Those rules protect access to the UHP server and its objects. They do not define the SAIP-style request header, algorithm-selected signature/MAC verification, RKDF sequence state, DNS attestation discovery or portable agent-instance identity that a downstream non-UHP service could independently verify.

SAIP is not another AIP draft

The site separately tracks several proposals named Agent Identity Protocol (AIP). SAIP is a different named proposal with a different draft identifier: draft-jovancevic-saip-11. Documentation should not collapse SAIP into the overloaded AIP acronym merely because both concern agent identity.

The practical distinction is also useful: the AIP proposals tracked on this site include registry, DID, capability-token and delegation-chain models, whereas SAIP is centered on an application-layer identity signal with algorithm-selected verification, discovery and request-level replay/key controls.

What not to infer

Caution

• SAIP is not an IETF standard. It is an active individual Internet-Draft and may change, be replaced or expire.
• The draft header’s “Standards Track” intent is not IETF endorsement or standards-process standing.
• A valid SAIP identity does not grant authorization; authorization remains a separate application concern.
• SAIP does not replace UHP Responses, Sessions, harness configuration, files, events or conformance classes.
• UHP authentication does not automatically create a SAIP identity for a harness or subagent.
• The existence of both protocols does not establish a standardized UHP↔SAIP binding.
• No primary source reviewed establishes native SAIP support in HarnessRouter or native UHP adoption by SAIP.

Related pages

Read UHP security for the protocol’s own trust-boundary requirements, UHP vs AIP for other agent-identity proposals, UHP vs A2A for agent-to-agent communication, UHP vs MCP for tool/context interoperability, and the ecosystem map for adjacent standards.

Primary sources

• IETF Datatracker — SAIP draft-jovancevic-saip-11
• SAIP draft-jovancevic-saip-11 archived HTML
• IETF Datatracker — VICDM draft-jovancevic-vicdm-10
• UHP 2026-09-28 security considerations
• UHP 2026-09-28 architecture