[Use Case] Citizen's AI assistant applies for a public service, with an operator-attested number and later change of AI provider
fg-tida-use-cases-use-case-citizens-ai-assistant-applies-for-a-public-service-with-an-operator-attested-number-and-later-change-of-ai-provider-64
| Type | FG-TIDA document |
|---|---|
| Group | Trust and Identity for Humans and Agentic AI |
| State | Submitted |
| Authors | Not entered |
| Last updated | 2026-10-23 15:11 UTC |
Formats and resources
Abstract
1. Identification
Title: Citizen's AI assistant applies for a public service, with an operator-attested number and later change of AI provider
Submitting organization: PAX S&T Co., Ltd. (Republic of Korea)
Contact name: Jaedoo Kim
Contact email: jdookim0307@gmail.com
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
- [ ] Critical infrastructure
- [ ] Smart home / IoT
- [x] Other (specify): Public services / e-government
2. The situation
Plain language description (required, 3 sentences max): A citizen asks an AI assistant to apply for a public service, with a rule that any fee above a threshold needs the citizen's confirmation. The public institution's service agent must decide whether the assistant really acts for this citizen and within what limits, separately from whether the citizen is eligible for the service. Some months later the citizen switches to an assistant from another AI provider and expects not to re-establish identity with the institution.
Actor (every party involved): Citizen (principal); citizen's AI assistant (AI provider X), later replaced by an assistant from AI provider Y; telecom operator (trust source via subscriber identification, at the assurance level it provides); public institution (principal for its own service, and relying party) and its service agent.
Action: The assistant discovers the institution, verifies it, submits the application within the delegated scope, and returns the result and evidence to the citizen.
Decision required: "Does this assistant act for this citizen, for this service, within these limits, and is that delegation valid now?"
Problem encountered (why that decision cannot be made today): The assistant's identity and the citizen's session are typically held within the AI provider's or platform's ecosystem; we have not identified, among the specifications reviewed, a common profile through which the institution can verify a citizen-issued, bounded delegation independently of that provider, and the citizen's relationship with the institution may not carry over when the provider changes.
Current mitigation: The citizen logs in personally to the e-government portal; the assistant can only prepare forms; screen-scraping or credential sharing in some cases.
Residual gap: Working hypothesis, to be tested in the gap analysis: no common profile yet lets a public relying party verify, independently of the AI provider, a principal-anchored delegation that reuses an existing identity source, with continuity of the principal's relationships across a change of AI provider.
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
- [ ] 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
- [ ] Other (specify):
Mandates in this case (required)
| Grantor | Grantee | What is conferred | Governing regime |
|---|---|---|---|
| Citizen | AI assistant (provider X) | Apply for one specified public service; fixed validity period; fees above a threshold require the citizen's confirmation; no re-delegation | Administrative law of the jurisdiction; civil law on agency |
| Citizen | AI assistant (provider Y) | Same mandate re-issued after provider change | As above |
| Public institution | Service agent | Process applications for the service under the institution's rules | Administrative law; institution's internal rules |
Cross-border?
- [ ] Yes — jurisdictions involved:
- [x] No
Embodied (physical actuation or sensing)?
- [ ] Yes — physical context:
- [x] No
Agent action type (required)
- [x] Read-only
- [x] Consequential (reversible)
- [ ] Irreversible
Crosses organisational boundary? (required)
- [x] Yes (specify): between the citizen, the AI provider, the telecom operator and the public institution
- [ ] No
Risk level (required)
- [ ] Low
- [x] Medium
- [ ] High
4. Theme relevance
| Theme | Yes | Primary | Justification (required if checked) |
|---|---|---|---|
| Dynamic Identity | [x] | [x] | The assistant is replaced by one from another provider while the citizen, the delegation structure and the relationship with the institution continue. |
| Continuous Trust and Attestation | [ ] | [ ] | |
| Delegation | [x] | [ ] | The institution must verify a bounded, citizen-issued mandate with a human-approval condition. |
| Discovery and Cross-Border Trust | [x] | [ ] | The assistant discovers and verifies the institution first, then its service agent (principal-first discovery). |
| Runtime Enforcement (Control Plane) | [ ] | [ ] | |
| Embodied AI Identity and Trust | [ ] | [ ] |
Related theme proposals: [Theme] Subject-Anchored Identity, Delegation and Discovery for Agentic AI (FG-TIDA/themes#45); FG-TIDA/themes#25 (trusted root via telecom identity, portable revocation); FG-TIDA/themes#34 ATHENA.
5. Requirements
| # | Type (choose one) | Requirement description | Criticality (choose one) |
|---|---|---|---|
| 1 | Technical | An existing trust source (operator subscriber identification) can attest the subscriber of record at the assurance level it provides, current control of the number can be checked (recognizing that such checks are exposed to SIM swap and need recency checks), and both can be bound to a machine-verifiable identifier without a new national or global registry; where the subscriber of record may differ from the user, this is established separately. | Must |
| 2 | Technical | The relying party verifies the chain principal → delegation → assistant and its current validity independently of the assistant's AI provider. | Must |
| 3 | Technical | A change of AI provider does not require re-establishing the principal's identity with the institution; the principal re-issues the delegation, revokes the old one, and holds records independently of the provider or in exportable form, and the institution verifies the new assistant under its own rules. | Must |
| 4 | Legal | Verification of the delegation establishes only the assistant's authority to act for the citizen; eligibility, any legal limits on representation and required evidence are decided separately under the institution's rules. | Must |
| 5 | Technical | Discovery can start from the institution as a verified principal and then locate its service agent. | Should |
| 6 | Legal | Results and evidence are attributable to the citizen and remain available after the original assistant ceases to exist. | Should |
6. Assessment criteria
Success criteria: The institution accepts the assistant's authority to act for the citizen on the basis of the verified delegation, and processes the application where the citizen meets the service's eligibility and evidence requirements. After the provider change, the new assistant is accepted without the citizen re-establishing identity with the institution.
Measurable metric: Relying parties requiring the citizen's identity to be re-established after a provider change (target: zero). Registration and authentication of the new assistant and transfer of task state are outside this metric.
7. Duplication check
Existing standards or SDOs: National eID schemes and wallets; operator subscriber identification, including CAMARA Number Verification and SIM Swap; W3C DIDs and VCs; OAuth 2.0 / OpenID Connect.
Overlap notes: These authenticate the citizen or carry credentials. The working hypothesis, to be tested in the gap analysis, is that no common profile yet defines a provider-independent, principal-anchored delegation to an AI assistant that a public relying party can verify, with continuity across a change of AI provider. The content of national eID schemes is not addressed.
8. Maturity
Pilot status
- [x] Hypothetical
- [ ] Pilot in progress
- [ ] Deployed in production
Reference implementation: n/a (architecture described in the HWW white paper and HCTP Core Specification Draft 1.0, https://www.hww.kr)
9. IP and confidentiality
Confidentiality level
- [x] Public
- [ ] FG-internal only
- [ ] Redact before publication
IP notes (optional): PAX S&T Co., Ltd. holds Korean Patent No. 10-2990000 and International Patent Application PCT/KR2026/012600, which may relate to the architecture referenced here. It intends to license on RAND terms and will submit an ITU-T General Patent Statement and Licensing Declaration; this note does not replace that declaration and does not imply that any patent is essential to a future Recommendation.
10. Assets
Link to assets:
- [ ] Dataset
- [ ] Code
- [ ] Protocol
- [x] Other: White paper and core specification draft (background only, not proposed for standardization), https://www.hww.kr
IP notes (optional): As above.
Revisions
- No file revisions have been uploaded.