Skip to content
UHPUHPDeveloper Guide
Independent developer guide. Not affiliated with HarnessRouter or the official UHP project.

UHP vs Agent Identity Protocol (AIP)

UHP standardizes complete-harness execution. AIP is an overloaded name used by multiple independent agent-identity proposals, so the exact draft must be qualified before comparing semantics.

Page reviewed 4 Oct 2026 Source and review policy

UHP: 2026-09-28AIP: three active drafts; one expired & archived

Qualify the identity contract before integrating it

Section titled “Qualify the identity contract before integrating it”

The current OpenA2A Datatracker entry now serves draft-fane-opena2a-aip-03, updated 2 October 2026. The repository still identifies OpenA2A AIP 1.2.0-draft. These are distinct submitted/document-development coordinates, not a finalized standard. The other AIP lineages and UHP 2026-09-28 Draft were checked on 4 October 2026.

Question to settleWhy it changes an integration
Which named proposal and revision?Registry keys, DIDs and invocation-bound capabilities are different contracts
Which identity is verified?Agent identifier, provider identity and presenting caller need not be the same principal
Is the credential bearer or proof-of-possession?A valid credential does not always authenticate its presenter
Which action/resource is authorized?Identity verification alone does not grant execution or storage access
How are revocation and delegation evaluated?A once-valid identity can lose authority or exceed its scope

For a UHP server protected by an identity gateway, retain the verified external subject and the explicit mapping to the UHP authenticated principal. Then enforce UHP object scope. Do not derive one namespace from another by matching display names or transport addresses. Routing identity explains why those shortcuts cause cross-session ownership errors; authorization envelopes address a separate mandate/constraint layer.

The one-sentence difference

Section titled “The one-sentence difference”

UHP standardizes how a client asks a server to run a selected, configured complete harness; the proposals currently called Agent Identity Protocol (AIP) focus on identifying agents, expressing or delegating authority, and verifying or enforcing that identity at other trust boundaries.

Those concerns can coexist in one system, but they are not interchangeable. A UHP Response or Session is an execution object. An AIP identity, credential, delegation or signed tool-call token is an identity/authorization object whose exact form depends on which AIP proposal is meant.

“AIP” currently names more than one proposal

Section titled ““AIP” currently names more than one proposal”

There is no single canonical Agent Identity Protocol represented by the bare acronym AIP. As of this review, the AIP label spans at least four individual Internet-Draft lineages reviewed here: three remain active, while draft-aip-agent-identity-protocol-00 expired and was archived on 17 Sep 2026. The IETF Datatracker explicitly states for each that an Internet-Draft may be submitted by anyone, is not endorsed by the IETF, and has no formal standing in the IETF standards process.

ProposalCurrent observed draftMain identity modelStatus at this review
Cao / Arango Gutierrezdraft-aip-agent-identity-protocol-00Registry-bound agent public keys plus per-tool-call signatures and an enforcement proxy that can allow, deny or hold callsExpired & archived individual Internet-Draft; expired 17 Sep 2026; latest revision 16 Mar 2026
Singladraft-singla-agent-identity-protocol-03W3C DIDs, capability-based authorization and cryptographic delegation chains for decentralized multi-agent workflowsActive individual Internet-Draft; last updated 9 Jun 2026; expires 12 Dec 2026
Prakashdraft-prakash-aip-01Invocation-Bound Capability Tokens (IBCTs): compact JWT/Ed25519 for single-hop authority or chained Biscuit/Datalog delegation for multi-hop attenuationActive individual Internet-Draft; published 19 Aug 2026; expires 20 Feb 2027
OpenA2A AIPDatatracker: draft-fane-opena2a-aip-03; repository: 1.2.0-draftProvider-scoped did:web identity, capabilities, challenge-response verification, behavioral trust scoring, governance, lifecycle and audit; did:opena2a is scoped to the ecosystem trust fabric-03 is the submitted active Internet-Draft (Datatracker updated 2 Oct 2026). Repository 1.2.0-draft is unreleased; do not collapse the two source scopes

The naming collision is operationally important. Documentation, configuration or architecture diagrams should identify the author/project or exact draft identifier rather than saying only “AIP.” OpenA2A’s own specification makes the same disambiguation explicit by using OpenA2A AIP.

The proposals are also at different lifecycle states: three remain active individual Internet-Drafts, while the Cao / Arango Gutierrez -00 draft is expired and archived. There is a second versioning distinction inside OpenA2A AIP itself: the IETF Datatracker and the project’s repository are not at the same revision. At the September snapshot the Datatracker still served draft-fane-opena2a-aip-02, while repository main identifies AIP-SPEC.md as 1.2.0-draft. The project changelog says rendered -03 carries the 1.1.0-draft text but was not submitted at the September cutoff, and a future -04 is intended to pair with 1.2.0-draft once that change set closes. Those coordinates should not be collapsed into one version label.

What the proposals actually standardize

Section titled “What the proposals actually standardize”

Cao / Arango Gutierrez: signed identity plus an enforcement proxy

Section titled “Cao / Arango Gutierrez: signed identity plus an enforcement proxy”

draft-aip-agent-identity-protocol-00 separates identity from enforcement. An AIP Registry binds an agent identifier to its public key and accountable principal. The agent signs outbound tool calls, and an AIP Proxy verifies the signature, evaluates an AgentPolicy, and returns an allow, deny or human-approval hold decision before the tool server is reached.

The draft names MCP as its primary tool-call interface but says the mechanism can apply to other structured tool invocation. It also explicitly does not replace service-level authentication such as OAuth or mTLS and does not define a new general transport protocol.

Singla: decentralized identity and delegation

Section titled “Singla: decentralized identity and delegation”

draft-singla-agent-identity-protocol-03 takes a broader decentralized approach. Its core model combines DIDs, capability manifests, credential tokens, principal tokens, registration and resolution, revocation, endorsements and cryptographic delegation rules. Its stated goal is secure and auditable agent delegation without relying on a centralized identity provider.

Prakash: invocation-bound capability tokens and attenuating delegation

Section titled “Prakash: invocation-bound capability tokens and attenuating delegation”

draft-prakash-aip-01 defines Invocation-Bound Capability Tokens (IBCTs) that combine identity, delegated authority, scope constraints and provenance. Compact mode uses JWT with Ed25519 signatures for single-hop interactions; chained mode uses Biscuit append-only blocks plus Datalog policy evaluation so each delegation hop can only narrow the authority it received. The draft specifies bindings for MCP, A2A and generic HTTP APIs and defines an ordered normative verification algorithm (V1–V7) for chain integrity, root binding, depth, structural attenuation, policy evaluation, expiry and revocation.

The draft also draws a security boundary that matters when comparing identity systems: an AIP token is a bearer credential. A valid chain establishes the authority conveyed by the delegation and that no hop widened its predecessor’s authority, but it does not authenticate the party presenting the token. Deployments requiring proof of possession must compose AIP with a transport/message-layer mechanism such as mTLS, HTTP message signatures or workload proof tokens. The draft similarly treats workload identity systems such as SPIFFE as complementary rather than interchangeable.

OpenA2A AIP: provider identity plus ecosystem trust

Section titled “OpenA2A AIP: provider identity plus ecosystem trust”

Historically, the September review compared submitted draft-fane-opena2a-aip-02 with newer repository text. The current submitted revision is -03; the following revision comparison preserves that earlier evidence. The current repository specification identifies itself as 1.2.0-draft. At the September cutoff its changelog said the then-unsubmitted rendered -03 carried the preceding 1.1.0-draft text, while -04 is planned to pair with 1.2.0-draft after that change set closes.

The repository’s post-1.0.1-draft identity scoping is the material architectural correction. At the AIP layer, an identity provider is specified to issue provider-scoped identifiers using a did:web profile, for example did:web:<provider-host>[:<path>]:agents:<id>. OpenA2A AIP now says it defines no DID method of its own. The separate did:opena2a method is ecosystem-scoped to the broader ATP/ATX trust fabric and Registry participants rather than being the identifier namespace that every AIP provider serves.

That means the older Datatracker -02 is historically important but no longer mirrors repository architecture on this point: -02 describes OpenA2A AIP with did:opena2a examples, whereas the repository changelog explicitly says -02 predates the later DID-method scoping. For current project intent, use the repository revision and identify each submitted revision separately rather than treating them as identical documents.

The current 1.2.0-draft work also sharpens terminology around trust. Its changelog renames the five AIP behavioral levels to behavioral tiers (behaviorTier, formerly trustLevel) so trustLevel can refer to ATP’s provenance-oriented trust level without overloading the same field name. The three AIP deployment conformance levels remain Local, Managed and Federated.

Implementation status is intentionally separate from specification intent. The AIM reference-implementation main checked in the preserved September review was fcfa9c608864acbf226ae9817170c57fd32e956d; its AgentDIDPrefix still builds did:aip:aim_<uuid> identifiers. That matches the repository specification’s own warning that the reference resolver still serves the deprecated alias form rather than the target did:web route. A repository specification change therefore must not be reported as already-deployed resolver behavior.

OpenA2A AIP continues to describe itself as complementary to communication/tool protocols including A2A and MCP. That is a useful architectural cue: identity can be layered around an execution or communication protocol without replacing that protocol’s task, message or transport semantics.

Architectural comparison

Section titled “Architectural comparison”
DimensionUHPAIP proposals
Primary concernExecute a selected configured complete harness behind one server contractEstablish and verify agent identity, authority, delegation, trust or policy enforcement
Typical boundaryProduct/client ↔ UHP server ↔ harnessAgent/principal ↔ identity/verification infrastructure; in some proposals, agent ↔ policy proxy ↔ tool/server
Core objectsHarnesses, Responses, Sessions, Containers, Files and streamed EventsVaries by draft: identities, keys, DIDs, credentials, capabilities, delegations, policies, attestations and audit records
Transport roleHTTP resource API with SSE event streamingVaries; identity is generally layered over existing interactions rather than replacing every application transport
Authentication scopeUHP requires authenticated endpoints except discovery and scopes server objects to the authenticated principalAIP proposals try to make the agent actor itself cryptographically identifiable and/or constrain delegated authority
Tool-call controlUHP can restrict configured harness tools and exposes execution events, but does not define a portable agent-identity signature for every downstream tool callCao/Arango explicitly signs and gates tool calls; Prakash carries attenuating delegated authority in IBCTs; other AIP drafts express capabilities/delegation through their own credential models
Task/session semanticsNormative UHP Response and Session lifecycleNot a replacement for UHP task/session lifecycle
Current maturityUHP 2026-09-28 Draft with a 85-check conformance suite; optional Harness Plugins adds an Agent Plugins 1.0.0 package bindingThree active individual Internet-Drafts plus one expired/archived draft in the four lineages reviewed here; OpenA2A additionally has a newer repository draft that is not yet submitted to the Datatracker; none should be described as an IETF standard

Where UHP and an AIP can coexist

Section titled “Where UHP and an AIP can coexist”

A deployment could use both layers without changing UHP’s external execution contract. For example:

  1. A client authenticates to a UHP server and creates a task against a configured harness.
  2. The UHP server owns the Response, Session, workspace and event lifecycle required by UHP.
  3. The executing harness or delegated subagent carries an AIP-style cryptographic identity when it reaches a downstream tool or another agent.
  4. A verifier or enforcement proxy evaluates that identity/delegation independently of the UHP task object.

That composition could improve attribution or delegated-authority controls, but it would be an implementation architecture. No standardized UHP ↔ AIP binding is established by the sources reviewed here. A current HarnessRouter repository search also found no Agent Identity Protocol or OpenA2A integration surface, so this guide does not claim HarnessRouter support for any AIP proposal.

UHP already has security rules, but not an AIP identity model

Section titled “UHP already has security rules, but not an AIP identity model”

UHP 2026-09-28 requires authentication for every endpoint except GET /v1/uhp, scopes every server object to the principal that created it, requires cross-scope object requests to return 404, and defines credential, artifact, transport and error-hygiene requirements. The current release retains optional Harness Plugins and their third-party execution requirements, and adds shared read-only Environments. Those rules govern the hosted harness/package boundary; they do not create a portable identity or delegation model for the autonomous agent itself. UHP also gives clients controls such as disabledTools, task budgets and a visible event stream.

Those rules protect the UHP server boundary. They do not define how a portable cryptographic identity for an autonomous agent is issued, resolved, delegated or presented to every downstream tool or peer. That is the gap the AIP proposals are trying to address in different ways.

What not to infer

Section titled “What not to infer”
Section titled “Related pages”

Read UHP security for the protocol’s own trust-boundary requirements, UHP vs MCP for the tool/context boundary, UHP vs A2A for agent-to-agent communication, UHP vs ACP for editor/client-to-agent interaction, and the ecosystem map for other adjacent standards.

Primary sources

Section titled “Primary sources”