Theme Name

Subject-Anchored Identity, Delegation and Discovery for Agentic AI

Proposer(s)

Jaedoo Kim, PAX S&T Co., Ltd. (Republic of Korea)

Summary

Anchor identity, authority and accountability to the principal (the Subject), not to the agent.

Where an agent receives its identity and trust record only from the platform that runs it, then as agents multiply, spawn sub-agents and change providers, trust tends to become attached to the most volatile entities in the system and to be held by whoever operates them. This theme proposes the inverse: the Subject (a person, organization or institution) is the persistent root, and every agent is a bounded, replaceable delegate whose authority is traced back to the Subject at the moment it acts.

Three consequences follow:

1. No global agent identity is required. Agent identifiers may be local or ephemeral; what must be common across domains is the delegation chain from the Subject to the action. Once two Subjects have verified each other, their agents need only a protocol to talk; existing agent protocols serve there unchanged, apart from carrying the delegation artefact.
2. Change the AI provider, keep the relationships. When the provider changes, the Subject re-issues its delegations to the new agent and revokes the old ones; its identity does not have to be re-established with each counterparty, much as a subscriber keeps a number under number portability. Records and pending state need to be held or exportable independently of the provider, and the new agent may still need to be registered and authenticated. This rests on a Subject continuity root: recovery conditions are registered before they are needed, and the remaining procedural detail is among the items for study below.
3. Reuse the trust that already exists. Existing trust sources such as operator subscriber identification, business registries and enterprise IAM attest the Subject, at the assurance level each provides, and are bound to machine-verifiable identifiers such as DIDs. The identifiers people already use (E.164 numbers, e-mail addresses, domain names) remain how people reach a Subject and how its internal identifier is found; the relationship and its verification rest on the internal identifier — so presenting a number proves nothing by itself, and the security boundary shifts to the verification of the Subject binding, key control, trusted evidence and currently valid authority. No new user-facing identifier, and no new global registry of agents.

The test case: can a relying party in another country decide, at the moment of an order and under its own rules, that this agent may commit this company, without having to trust the agent's AI provider?

This theme proposes requirements and architectural semantics, not a protocol. Existing mechanisms such as OAuth token exchange, DIDs and Verifiable Credentials are building blocks; the question, to be tested in the gap analysis, is whether a common profile across them already meets these requirements.

Scope / Items for study

• Delegation chain: the minimum semantics a relying party in another domain must be able to read: who delegates, to which agent, for what purpose and counterparty, within which limits and period, whether re-delegation is allowed (it can never exceed its source), and how it is revoked; plus binding of the delegation to the authenticated agent and to the request, so that it cannot be replayed elsewhere, and, separately, ensuring that the same request is not executed twice.
• Validity at the moment of action: re-checking authority before a consequential action; distinguishing when authority ends from when a verifier can observe it; revocation that reaches every sub-agent; cumulative limits held in an authoritative place when several agents act concurrently.
• Continuity of the Subject: keeping the Subject's identity and relationships intact when numbers, devices, agents or AI providers change (delegations are re-issued); who operates the continuity root and how it avoids becoming a new single point of control; defining in advance the conditions for recovery after key loss or compromise.
• Subject-first discovery: results are Subjects, whether the counterparty is known or found by intent or capability; the agents acting for the selected Subject are then located under it, including across borders. Finding is followed by verification under the relying party's own rules.
• For study: how a relying party accepts foreign trust sources under its own rules; who publishes and indexes Subjects for discovery, and how its neutrality is ensured; where an agent identifier needs global scope at all.

Related Work

• W3C Decentralized Identifiers (DIDs) v1.0; Verifiable Credentials Data Model v2.0; Bitstring Status List v1.0
• IETF RFC 6749 (OAuth 2.0), RFC 8693 (Token Exchange), RFC 9396 (Rich Authorization Requests), RFC 7662 and RFC 7009; OpenID Connect Core 1.0
• A2A Agent Card; MCP authorization
• Workload identity (SPIFFE, including SPIFFE Federation)
• Recommendation ITU-T E.164; Recommendation ITU-T X.1252 (identity management terms)
• Also to be covered by the gap analysis: attenuable capability tokens (UCAN, ZCAP-LD, macaroons, Biscuit); Agent Payments Protocol (AP2) v0.2 mandates; OpenID Federation 1.0; OAuth Transaction Tokens and IETF WIMSE; WebFinger (RFC 7033); CAMARA Number Verification and SIM Swap
• Background: HWW white paper and HCTP Core Specification, Draft 1.0, October 2026, PAX S&T (https://www.hww.kr). HCTP is background only and is not proposed here. A full input document is being prepared for the Paris meeting.

Related Themes

• 25 Age-Aware Identity and Delegated Authority for Agentic AI (trusted root, scoped delegation, portable revocation)

• 34 ATHENA: Telco-Grade Identity and Delegation Architecture for Agentic AI

• 23 Authorization and privilege lifecycle management of AI agents

• 14 Agent-to-Principal Legal Binding

• 2 Sovereign Discovery ++ Modularity

• 9 Authority that was never crisply authored (joint thread of #5, #1, #6): this theme treats a natural-language goal as intent, not as a grant of authority

• Agent Identity and Trust Stack (candidate theme 6 from the 1st preparation meeting, https://github.com/FG-TIDA/themes/blob/main/candidate-themes-from-2026-07-29.md)
• Use cases FG-TIDA/use-cases#9 (authority traced to a principal) and FG-TIDA/use-cases#6 (authority applicability under changed context)

We are open to merging this theme into a Delegation or a Discovery and Cross-Border Trust working group, and will contribute use cases and draft text.

Discussion