[Use Case] Layered governance architecture for digital identifiers, registration, discovery and digital credentials in agent internet infrastructure

1. Identification

Title: Layered governance architecture for digital identifiers, registration, discovery and digital credentials 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, decentralized identity governance and verifiable trust services

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 agent internet ecosystem uses digital identifiers and digital credentials across several infrastructure roles: registration services, discovery services and third-party credential issuers. A relying party must decide whether a discovered agent resource is controlled by the claimed controller, registered by an authorized registrar, indexed by an authorized discovery provider and supported by valid third-party credentials. Today there is no common governance architecture that tells independently operated nodes how to express, verify and revoke these chained authorities without collapsing them into one central registry or one agent protocol.

Actor (every party involved):
A federated set of governance authorities or infrastructure roots; registrars; discovery providers; third-party credential issuers or attestors; resource controllers; agent resources or infrastructure nodes; relying parties; and optional auditors or status-service operators.

Action:
A federated governance arrangement authorizes registrars, discovery providers and credential issuers within stated scopes, and publishes how participating governance authorities recognize one another and resolve conflicts. The governance arrangement does not require every participant to share one operator or one ledger. A controller registers an agent-related resource through an authorized registrar; the resource is then indexed by discovery providers and may present third-party digital credentials. A relying party verifies the chain from governance authorization to registrar registration, controller control, discovery provenance and credential status before accepting the resource.

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 resource be accepted as currently authorized, controlled by the claimed controller and supported by valid registration, discovery and credential evidence under the applicable infrastructure governance rules?

Problem encountered (why that decision cannot be made today):
Different systems define registrar authority, discovery authority, credential issuer authority, controller control and delegation chains in different places. A signed identifier document, a registration credential, a discovery result and a third-party digital credential can each verify cryptographically while still failing to prove that the whole chain is authorized, current and scoped to the action.

Current mitigation:
Deployments use bilateral trust lists, static allow lists, issuer-specific policies, manual audits, platform registries or centralized discovery operators. Some systems publish credentials or status APIs, but the governance roles and verification order remain local conventions.

Residual gap:
FG-TIDA lacks a layered governance use case for decentralized agent infrastructure that separates registration, discovery and credential issuer roles; expresses chained authorization and revocation; supports controller-based identity control; and gives relying parties an interoperable verification path.

Key terms used in this proposal:
- Digital identifier: a machine-readable identifier for a subject, service, organization or infrastructure role. It may be implemented by a DID method, a domain or certificate system, a platform identifier, or another identifier scheme.
- Digital credential: a machine-verifiable claim issued by one party about a subject, authority, capability, status or other fact. It may use a verifiable-credential format, certificate, signed token or another credential mechanism; proof validity does not by itself establish issuer authority or legal effect.
- Governance authority (or infrastructure root): the authority that defines a participation domain and grants scoped authority to registrars, discovery providers and credential issuers. It may be federated; the term does not require one global root or one blockchain.
- Federated governance: cooperation among independently operated governance authorities that publish recognition, scope, status and conflict-resolution rules for one another.
- Digital-credential issuer profile: the declared class and method of a third-party credential issuer, such as a capability certifier, reputation evaluator or identifier community; authorization to issue one profile does not authorize all other claims.
- Registrar: a service authorized to accept registration material and issue or reference evidence that a subject is registered within a stated scope. Registration does not automatically authorize every action by that subject.
- Discovery provider: a service that indexes and returns resource descriptions. It supplies discovery provenance but does not become the sole authority for the resource.
- Third-party credential issuer/attestor: an independent party that issues a digital credential or attestation about a subject or fact, such as an audit, qualification or operational status. A valid signature does not make an issuer authorized for every claim.
- Controller: the identity or organization authorized to make specified changes or decisions for a subject. Delegated controller means a subordinate identity with a narrower, time-bounded scope.
- Chained authorization: verification of each grant in sequence (for example, governance authority → registrar → registration → controller) and of its scope, audience, time and status. A cryptographically valid link is insufficient when an earlier grant is expired, revoked or out of scope.
- Relying party: the party that decides whether to accept, invoke or delegate to the discovered subject.

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): Infrastructure root or governance authority, registrar, discovery provider, credential issuer, controller, status-service operator and auditor

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: The base case is jurisdiction-neutral; cross-border operation occurs when governance authority, registrar, discovery provider, issuer, controller and relying party are under different legal regimes.
- [ ] 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): Governance authority, registrar, discovery provider, issuer, controller, resource operator and relying party may be separately governed.
- [ ] No

Risk level (required)
- [ ] Low
- [ ] Medium
- [x] 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 work on identity/trust/discovery architecture, trust lifecycle, machine-readable trust metadata and standardization recommendations.

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 verify a positive chain from an authorized governance domain and registrar to a registered resource, its controller, discovery provenance, third-party digital credential issuer authority and current status.
2. A registrar whose authorization is suspended or revoked can no longer create acceptable new registration evidence for relying-party verification.
3. A discovery provider can index and return a resource while preserving evidence needed for independent verification; discovery ranking alone never confers trust.
4. A third-party digital credential from an unauthorized or out-of-scope issuer is rejected even if its cryptographic signature is valid.
5. A controller chain can prove scoped control of a resource, while missing, expired, replayed or audience-mismatched controller proofs fail closed.
6. Identifier lifecycle, registration lifecycle, package lifecycle and digital-credential lifecycle are checked independently and reported distinctly.
7. A relying party can distinguish a federated governance recognition decision from a registrar registration decision, a controller authorization decision and a third-party digital credential claim.
8. Credentials from reputation, capability-certification and external-identifier community issuers are evaluated according to their declared profiles and do not receive authority beyond their scope.

Measurable metric:

• Pass/fail rate on frozen positive, boundary and rejection cases for registrar authorization, discovery provenance, credential issuer authority, controller proof, nonce, timestamp, audience, status and revocation.
• Number of governance roles whose authorization and status can be verified by an independent relying party.
• False-acceptance rate for valid signatures with invalid authority chain, stale status, revoked issuer, wrong audience or mismatched controller.
• Time from authorization-status change to relying-party rejection in a reference test environment.
• Percentage of verification decisions that retain issuer, subject, scope, status source, verification time and failed-link explanation.
• False-acceptance rate for cross-governance recognition conflicts, out-of-profile digital-credential claims and controller chains that exceed their delegated scope.

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, Data Integrity and related controller and verification-method concepts.
• IETF RATS architecture and EAT for evidence, appraisal, attesters and relying parties.
• X.509 PKI, certificate revocation, DNS, WebPKI and workload identity systems such as SPIFFE/SPIRE.
• OAuth 2.0, OpenID Connect, GNAP and token exchange for authorization and delegation patterns.
• Trust-over-IP, DIF, OIDC4VC and related trust registry or credential presentation work.
• ITU-T SG17 work on identity management, authentication, cybersecurity, trust, PKI and DLT-related security, and FG-TIDA Terms of Reference clauses 3.3-3.5, 4.1-4.5 and Annex A.7.

Overlap notes (why the work named above does not already solve this):
Existing work defines identifiers, controller fields, credentials, signatures, certificates, attestation concepts, token delegation or trust-registry patterns. DID and verifiable-credential specifications are examples of such work, alongside certificate, token and other digital-credential mechanisms. This use case does not replace those standards, define a new agent protocol, specify AI governance or create a national digital identity framework. It does not require DID, a particular verifiable-credential format, blockchain or a single registry; those are possible implementation choices. The unresolved issue is how agent-infrastructure governance roles should compose these mechanisms across identifier and digital-credential schemes so registration, discovery, third-party credential issuance, controller-based control, chained authorization and lifecycle verification remain interoperable across independently operated agent internet 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 use case and requirements contribution. Any linked implementation, design document, schema or test vector should carry separate license, authorship and version information. No conformity, certification, legal-compliance finding or ITU endorsement is asserted.

10. Assets

Link to assets:
- [ ] Dataset
- [ ] Code
- [ ] Protocol
- [x] Other: Candidate governance role model, credential profiles, controller-proof flow and verification test vectors may be linked after contributor review.

IP notes (optional):
Assets, if provided, are non-normative supporting material and should remain separable from FG-TIDA deliverables.