[Use Case] Digital identity requirements for semantic discovery and interoperable registration in agent internet infrastructure

1. Identification

Title: Digital identity requirements for semantic discovery and interoperable registration in agent internet infrastructure

Submitting organization: CAICT

Contact name: JINLIANG XU

Contact email: xujinliang@caict.ac.cn

Sector (tick all that apply; a cross-industry case may tick more than one):
- [ ] Education
- [ ] Displaced persons / humanitarian
- [ ] Health
- [ ] Financial services
- [x] Telecom
- [ ] Media and publishing
- [ ] Logistics
- [ ] Energy
- [x] Critical infrastructure
- [ ] Smart home / IoT
- [x] Other (specify): Cross-sector agent internet infrastructure, semantic discovery, identity and registration interoperability

2. The situation

Describe the functional interaction: who is acting, what they are trying to achieve, and what happens. The trust and security aspects are drawn out in Sections 3 to 5.

Plain language description (required, 3 sentences max):
An organization wants its agent service, tool API, skill package or infrastructure node to be discoverable by other parties through semantic search while remaining identifiable, routable, registerable and verifiable across independently operated systems. A relying party that receives a discovery result must decide whether the discovered resource identity, description, service endpoint, registration record and current authorization evidence refer to the same subject. Today these properties are often spread across different identifiers, package manifests, service directories and credentials, leaving no common identity requirements for agent internet infrastructure.

Actor (every party involved):
The resource controller or deployer; the agent resource or infrastructure node being identified; a registration authority or registrar; a discovery provider; a relying party that searches and invokes or downloads the resource; optional attestors or credential issuers; and an infrastructure operator that may provide routing or authorization context.

Action:
A natural person or legal entity may register and control one or more agent-related subjects. The controller registers one of three subject types: an agent resource, an infrastructure node, or a third-party credential/attestation issuer. A discovery provider indexes the subject's semantic description and service bindings. A relying party finds the subject through semantic search and verifies whether the identifier, metadata, endpoint, registration evidence, package or manifest hash and current status are coherent before use.

Decision required (at the moment the agent acts, what does the party on the receiving end have to decide? Write it as a question, e.g. "May this firm's agent be let into the house on the homeowner's authority?"):
May this discovered subject be treated as the same authorized and currently usable agent resource, infrastructure node or credential issuer described by the identifier, semantic metadata, service binding and registration evidence?

Problem encountered (why that decision cannot be made today):
Existing identifiers can establish names or keys, but they do not consistently define what semantic discovery metadata is identity-facing, how routing hints should be separated from authorization proof, which registration scenario is being represented, or how one infrastructure can remain compatible with DID, domain-based, certificate-based and other identifier schemes.

Current mitigation:
Implementations rely on local conventions: platform-specific IDs, DID methods, package manifests, domain names, certificates, registry entries, API documentation, allow lists or manually reviewed metadata. Some deployments add signed credentials or status APIs, but the expected relationship between these artifacts is not uniform.

Residual gap:
FG-TIDA lacks a use-case-driven requirement set for agent internet digital identity that connects semantic discovery, routing-aware identifier design, multiple registration scenarios and identifier-scheme interoperability while preserving the distinction between identity, metadata, routing, authorization and status.

Key terms used in this proposal:
- Agent resource: a discoverable software subject such as an agent service, tool API, skill package or protocol endpoint.
- DID (decentralized identifier): an identifier designed to be controlled and resolved without depending on a single centralized identifier provider; this proposal treats DID as one supported scheme among several.
- Infrastructure node: a service that registers, resolves, routes, indexes or otherwise supports agent resources; it is itself a subject that may need an identity and authorization.
- Designated infrastructure authority: an authority named by the applicable participation policy to authorize or oversee infrastructure services; this term does not imply a single global root.
- Semantic discovery: matching machine-readable capability and context metadata to a request, rather than searching only by an exact name or network address. Semantic attributes may include capability labels, capability descriptions, supported inputs and outputs, and use-case descriptions; they help produce candidates but do not by themselves prove capability or authorization.
- Registration evidence: a signed record or credential stating who registered a subject, under which scope and policy, when it was issued, and whether it is still valid. It does not by itself prove every legal or operational claim about the subject.
- Routing hint: information used to locate a resolver, registry or network path. A structured identifier may expose a governance or registration domain so that a resolver can locate the authoritative subject description. A routing hint is not proof that a subject is authorized or trustworthy and should remain updateable or recoverable when infrastructure changes.
- External identifier mapping: a verifiable binding between the local subject and an identifier issued by another system, including the source system, identifier type, resolution context, scope, validity and status. It is a mapping claim, not automatic mutual recognition.
- VC (verifiable credential): a tamper-evident, machine-verifiable claim issued by one party about a subject; the claim still requires an applicable trust and status decision.
- MCP (Model Context Protocol): one example of a tool or context-serving protocol whose endpoint may be represented as an agent resource; this proposal does not specify MCP.

3. Actors and context

Taxonomy roles involved
- [x] Principal — possesses the authority being exercised; source of the mandate
- [x] Relying party — must decide whether to accept the agent's authority
- [x] Builder
- [x] Deployer / Owner
- [x] Agent instance
- [x] User — interacts with the agent; may or may not be the principal
- [x] Infra provider
- [x] Attestor
- [x] Other (specify): Registrar, discovery provider, identity resolver, resource controller and package or service publisher

Mandates in this case (required)

List each grant of authority. State the legal regime governing each one: the regime fixes what could be conferred, at what moment standing may change, and with what continuing effect. A single-regime case is entirely valid. Actor above lists every party; this table covers only the authority relationships between them.

Cross-border?
- [x] Yes — jurisdictions involved: Cross-border operation is possible when discovery, registration and relying parties are in different jurisdictions; the base case is jurisdiction-neutral.
- [ ] No

Embodied (physical actuation or sensing)?
- [ ] Yes — physical context:
- [x] No

Agent action type (required; tick all that apply. Where several apply, the most consequential governs the case)
- [x] Read-only
- [x] Consequential (reversible)
- [ ] Irreversible

Crosses organisational boundary? (required)
- [x] Yes (specify): The controller, registrar, discovery provider, credential issuer and relying party may be independently operated.
- [ ] No

Risk level (required)
- [ ] Low
- [x] Medium
- [ ] High

4. Theme relevance

Check every theme this situation exercises, mark the single primary theme, and justify each checked theme against Section 2 above. If the case maps to a specific theme proposal, link it below.

Related theme proposals: N/A. This proposal maps to FG-TIDA's identity, trust management, agent discovery and interoperable infrastructure scope. Links to theme issues can be added after theme alignment.

5. Requirements

One row per requirement. Add rows as needed. Type: Legal / Business / Technical. Technical requirements are the primary output; include legal or business requirements where they bear on a technical decision. Criticality: Must / Should / Nice-to-have.

6. Assessment criteria

Success criteria:

1. A relying party can determine whether a semantic discovery result, identifier, endpoint, package or manifest reference, registration credential and current status describe the same subject.
2. A discovery result with a good semantic match but missing, expired, mismatched or revoked registration evidence is rejected or marked unresolved.
3. A routing hint is never accepted as authorization or trust proof in the test cases.
4. The same resource can expose DID-based identity material and external identifiers such as domains, platform IDs or certificates without ambiguous subject merging.
5. Agent resource, infrastructure-node and third-party credential-issuer registration cases can be represented without changing the core identity model.
6. A subject registered by a natural person or legal entity can expose one or more external identifiers with their source and verification context preserved.
7. A resolver can follow the routing information associated with an identifier while a relying party can still detect stale, changed or unauthorized routing information.

Measurable metric:

• Pass/fail rate on positive, boundary and rejection test vectors covering identifier syntax, semantic metadata, service binding, routing hint interpretation, registration evidence, status checking and external-identifier disambiguation.
• Number of supported identifier-scheme mappings that preserve source context and verification semantics.
• False-acceptance rate for discovery results with mismatched endpoint, package hash, issuer, status or routing hint.
• Percentage of resource records that expose the minimum verification material needed by a relying party without a provider-specific manual process.
• False-acceptance rate when semantic metadata, routing information or external-identifier mappings are validly formatted but not authorized, current or attributable.

7. Duplication check

Required under ITU-T Recommendation A.7 clause 7: the Focus Group does not duplicate work underway in ITU-T study groups or other bodies.

Existing standards or SDOs (which existing work touches this case):

• W3C DID Core, DID Resolution, DID Method Registry, Verifiable Credentials Data Model 2.0 and Data Integrity specifications.
• IETF RATS architecture and Entity Attestation Token work for evidence, appraisal and relying-party separation.
• X.509 PKI, WebPKI, DNS, domain verification and workload identity systems such as SPIFFE/SPIRE.
• OAuth 2.0, OpenID Connect, GNAP and related authorization or presentation mechanisms.
• Model Context Protocol, Agent-to-Agent protocols and other agent interaction protocols, where identities may be used by higher-level protocols.
• ITU-T SG17 identity, authentication, cybersecurity and trust-related work, and FG-TIDA Terms of Reference clauses on identity, trust management, agent discovery and interoperable infrastructure.

Overlap notes (why the work named above does not already solve this):
Existing standards provide identifier formats, credential formats, attestation concepts, certificates, workload identity or interaction protocols. This use case does not redefine DID Core, VC, PKI, RATS, OAuth, MCP, A2A or national digital identity. The remaining gap is an agent-internet-specific requirement set that composes identity, semantic discovery metadata, routing-aware registration, status evidence and multi-identifier compatibility in a way that relying parties can test across independently operated infrastructure.

8. Maturity

Pilot status

• [ ] Hypothetical
• [x] Pilot in progress
• [ ] Deployed in production

Reference implementation: OpenAgenet website · OpenAgenet GitHub organization. These links identify an implementation-informed public reference; they are provided for context and evaluation only and do not ask FG-TIDA to adopt OpenAgenet, its architecture, a specific DID method or any of its services.

9. IP and confidentiality

Confidentiality level

• [x] Public
• [ ] FG-internal only
• [ ] Redact before publication

IP notes (optional):
The proposal is intended as an implementation-neutral requirements contribution. Any linked code, documents or test fixtures should identify their own license, authorship and version. No conformance, certification, legal-compliance finding or ITU endorsement is asserted.

10. Assets

Link to assets:
- [ ] Dataset
- [ ] Code
- [ ] Protocol
- [x] Other: Design documents and candidate test vectors may be linked after contributor review.

IP notes (optional):
Assets, if provided, are non-normative evidence for the use case and should remain separable from FG-TIDA deliverables.