UHP vs Signed Agent Identity Protocol (SAIP)

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 signed request-level identity signal. 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-10, dated 29 August 2026 and last updated in the IETF Datatracker on 28 August 2026. It is an active individual Internet-Draft, not an IETF standard and not endorsed by the IETF. The draft expires 2 March 2027 unless replaced or refreshed.

Revision -10 describes itself as a reviewed and corrected version of -09: it fixes editorial and consistency issues and clarifies descriptions without intending to change the architecture, trust model or security properties.

SAIP is built around the separate Verifiable Identity Claims and Delegation Model (VICDM), whose current observed revision is also draft-jovancevic-vicdm-10. 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, signing algorithm, timestamp, nonce and signature, with optional public-key and telemetry fields. The draft defines canonical request material for signature verification and a processing model that checks required fields, timestamp freshness, nonce handling, key discovery and the request signature before local policy is applied.

Three design points are especially relevant to agent infrastructure:

• Per-request rolling keys. The draft derives a rolling signing key from a master key and sequence state, uses that rolling key for one request, then destroys it. Servers maintain a bounded look-ahead sequence window and can return SAIP-Next-Seq after successful verification.
• Multiple key-discovery paths. The current discovery order is an explicit public key in the request, DNS-based attestation discovery under _saip.<domain>, then Registration Entity lookup. The draft requires rejection when no valid key can be found through the available methods.
• 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 optional tm telemetry field is explicitly opt-in and commitment-based; the draft says 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-08-11 Draft	draft-jovancevic-saip-10, 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 identity header, instance identity, keys, 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 per-request rolling-key and sequence mechanisms
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 signed SAIP identity assertion.
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-08-11 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, rolling-key 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-10. 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 a signed application-layer identity signal, rolling-key state and request-verification discovery paths.

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.
• 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-10
• IETF Datatracker — VICDM draft-jovancevic-vicdm-10
• UHP 2026-08-11 security considerations
• UHP 2026-08-11 architecture