2026-07-29-preparation-meeting-1/TIDA July 26

Auto-reporting tools 
Agenda Opening remarks and  agenda adoption ; What happened so far : establishment of the Focus Group, Terms of Reference, launch; What is happening next , and the objective for the first meeting (Paris, 1–4 December); Open discussion on initial deliverables  from the Terms of Reference annex and from ad-hoc discussions, IETF meetings, etc.; Working Group structure  and organization; Tools  and working methods; Next milestones , next meetings and proposed cadence; AOB and agreement on next steps.
THANK YOU!! 17
4 Workshops led us to today 9  Jul  2026 Designing the trust management for Agentic AI Hiroshima Process outcome to embed into standardization/technical req First elements of trustworthiness for the design of the controls/control planes shared 12 May 2026 X.509  day Pervasive X.509 referenced in nearly every March presentation Federation of  trust doesn’t work today     X.dpki  as a proposal 30-31 Mar  2026 Globally Interoperable Digital Identity for Humans and Agents Agentic ID contested We lack terminology on Agentic Discovery and delegation are open problems Global interoperability for trust management of digital identity for Humans and Agents Trust management for verifiers and wallets is an open problem Trust management of Agentic works only within enterprise domain 2 Jun 2026
What is a Focus Group in ITU? TIDA Focus Group is An  Open Community  ( no need to be member of ITU to participate)  conducting  pre-standardization work
Why creating TIDA? As AI agents begin to negotiate, transact, and act autonomously on our behalf, the world lacks  common international foundations  to establish who these agents are, when they can be trusted, and how humans remain in control: FG-TIDA was created to build that foundation before agentic AI becomes ubiquitous Our objective is to define architectural models and interoperability frameworks that establish trust in agentic AI. As part of the UN, we bring together an inclusive, global community of Member States, academia, and industry to build this foundation together.
9 July 2026: the launch of FG-TIDA The initial supporters, called one by one to the AI for Good Centre Stage 54 countries in the consensus 48 companies 11 universities 37 initial supporters on stage Open to all, free of charge, no ITU membership required. FG-TIDA at ITU    ·    tida.community    ·    Terms of Reference
What is happening next? 7 Sep 2026 2nd SG17 Content Week, Chongqing (China) Two SG17 workshops: ITS/CAV security · Secure Agentic AI 7 Oct 2026 Interim SG17 plenary (virtual) Progress checkpoint 1–4 Dec 2026 FG-TIDA 1st meeting, Paris With the Digital Trust Convention at the OECD on 4 December 9 Dec 2026 Interim SG17 plenary (virtual) Progress checkpoint 25* Jan 2027 SG17 workshop, Geneva Open to all participants 26* Jan 2027 FG-TIDA meeting, Geneva Focus Group working session 18–29* Jan 2027 6th SG17 Plenary, Geneva Next full plenary * = TBD depending on ME situation
Our Objective for  1-4 Dec meeting Formally announce the Focus Group's structure and leadership Publish an initial definition of deliverables on GitHub  Advance the technical work during the in-person meeting
How to get there?  4 virtual meetings from now to 1-4 Dec (today) 29th of July @2pm CET  2nd of September @2pm CET 30th of September @2pm CET 4th of November @ 2pm CET
Current TIDA Structure
Let us  brainstorm  together on  ideas for Working Groups
1 Design-based agent identity Encoding immutable design traits into a structured naming scheme P The problem Classical security ties access rights to a verified, stable identity. But an AI agent is not a deterministic workload, it reasons, generalizes, and keeps changing (“metamorphing”). A verified identity therefore says very little about how the agent will actually behave on a given task. Identity ≠ predictable behavior A Proposed approach Instead of a flat identity string, encode an agent’s immutable design traits, stakeholders, software components, models and tools, and the relationships between them, directly into the naming scheme. Identity is anchored to design, not to operational behavior. D Deliverables Task 1: Study of AI agent design and typical relationships across popular agents; feasible assurances and corresponding trust models Task 2: Requirements and mechanism for a naming scheme that formally and deterministically packages these assurances into an identity string usable for access rights FOOD FOR THOUGHTS What immutable traits can realistically be captured for a pure software entity with no physical anchor? How would this scheme interoperate with existing identity carriers (WIMSE, AAuth, X.509)? Who validates or certifies the claimed design traits?
2 Intent-based security policies Rethinking access control beyond the identity-bound matrix P The problem Classical access control formalizes rights around an access control matrix (DAC, RBAC, etc.), attached directly or indirectly to a verified identity. If identity says little about an agent’s behavior, policies built on that matrix inherit the same weakness and revoking an identity does not reliably stop unwanted behavior. Policies that hold regardless of identity A Proposed approach Express security policies as intents, properties that must be preserved at all times, regardless of which actor or agent is involved rather than rights bound to an identity. This embraces the agent’s own reasoning capability, accepting an intrinsic fuzziness alongside existing strict models. D Deliverables Task 1: Study of how a security policy can be expressed as an “intent” independent of the involved actors and agents; understand its features and limits Task 2: Study of coexistence between classical, identity-bound security policies and intent-based security policies DISCUSSION QUESTIONS FOR TOMORROW How do we test or verify compliance with a fuzzy, intent-based policy? Can intent-based and classical models compose, or do they need separate enforcement points? What is a minimal viable use case to pilot this approach?
3 Remote attestation for agentic AI P The problem AI agents widen the trust surface Remote Attestation was built for, platform, runtime, model, tools, policy, identity, and behavior all need attesting, not just boot-time hardware state.  Strong platform trust A Proposed approach Reuse existing RATS building blocks (EAT, CMW, CoRIM → EAR) rather than build a parallel agent stack. Extend them with an agent profile, and resolve three integration questions specific to agentic protocols: what to attest (trust vector), how evidence is discovered and conveyed inside A2A/MCP, and when to attest (risk-keyed freshness tied to protocol events like tool calls and delegation). D Deliverables Task 1: State-of-the-art survey of RA standardization (IETF RATS, TCG,  GlobalPlatform ) and a proposed agent EAT/CoRIM profile covering configuration, policy, and behavior Task 2: Study of RA integration with agentic protocol primitives, discovery, conveyance, authorization, freshness triggers, unveiling gaps and a standardization roadmap DISCUSSION QUESTIONS FOR TOMORROW Scope to IETF only, or also engage TCG / GlobalPlatform for the platform layer? Should evidence be conveyed payload-embedded (survives relay) or transport-bound (fresher, single-hop) — same tension as agent identity carriage? What's the minimal viable agent EAT profile to propose first: configuration, policy, or behavioral evidence?
4 Sovereign discovery for agentic AI Multi-path discovery as a condition for the digital commons P The problem Discovery and access are inseparable, the ability to list or de-list an entity is itself a form of access control, and how discovery works determines who can participate in the digital commons. Access is sovereign in the digital space: no single discovery mechanism should hold exclusive control over what is findable. Competing approaches (DNS-based, registry-based) already exist with no shared framework for when each applies. De-listing is access control A Proposed approach Treat discovery as multi-path from the outset, not retrofitted onto one centralized mechanism later. Build a requirements and compliance framework comprehensive enough that different use cases can choose the right path, DNS answer, registry answer, or other, while remaining interoperable.  D Deliverables Task 1: Requirements and compliance framework for discovery mechanisms, broad enough to let use cases choose among competing approaches (e.g. DNS-based DNS-AID, registry-based, or other), building on IETF DAWN’s problem statement and requirements drafts Task 2: Study of the discovery–access relationship and a sovereignty model for digital-commons participation, with multi-path resilience designed in from the start rather than added later DISCUSSION QUESTIONS FOR TOMORROW Align directly with IETF DAWN's requirements work, or develop complementary requirements specific to trust and identity? What does sovereignty over discoverability mean in practice — who can de-list an agent, and under what governance? DNS-based (e.g. DNS-AID), registry-based, or hybrid — should the framework favor a path or stay mechanism-agnostic?
5 Bridging trust management for Digital ID across borders Making digital ID trust portable without forcing one global system P The problem Every country and organization builds its digital ID ecosystem independently, its own trust anchors, issuance rules, and assurance levels. That works within a jurisdiction. It breaks the moment identity needs to cross a border or organizational boundary: there is no shared way to compare or recognize another ecosystem's guarantees, so users re-prove their identity from scratch and protection varies by whichever rules happen to apply. Trust doesn't cross borders by default A Proposed approach Define a common reference model for expressing what a digital ID ecosystem actually guarantees, so two ecosystems can be compared on the same terms  then a mutual-recognition framework for how one ecosystem decides how much to trust a credential from another. Not a single global authority: sovereign ecosystems interoperate on their own terms, the way treaties recognize foreign degrees or licenses without merging the underlying systems. D Deliverables Task 1: A common vocabulary for what an ecosystem guarantees — issuer accountability, assurance level, revocation freshness, data protection regime — enabling apples-to-apples comparison across ecosystems Task 2: A mutual-recognition and equivalence framework, including compensating controls for when two ecosystems' guarantees don't fully match DISCUSSION QUESTIONS FOR TOMORROW Should recognition be bilateral (country-to-country agreements) or mapped onto one shared reference framework? How do we preserve sovereignty — data residency, legal control — while still enabling cross-border trust? What's the minimal viable pilot: one credential type (e.g. professional license, education credential, age verification) across two jurisdictions?
6 The agent identity and trust stack P The problem The AI Agent Ecosystem is genuinely complex: Builders, Deployers/Owners, Agent Instances, Users, Infra Providers, and Attestors all interact, often across administrative and trust boundaries. Standards efforts risk jumping straight to protocol-level work (A2A, MCP, or others) before the industry agrees on the underlying identity and trust functions every agentic system actually needs. Agree on the stack before the protocol A Proposed approach Define a common, protocol-agnostic identity and trust stack, the functions every agentic system needs to establish who's who and whether to trust them: Agent Authentication, Agent Discovery, User Identification, Agent Identification, Agent Attestation, Agent Authorization, and Agent Delegation. Agent Interaction, the communication mechanics themselves, sits adjacent to this stack, not inside it, and is out of scope here. D Deliverables Task 1: A reference model of the AI Agent Ecosystem's roles — Builder, Deployer/Owner, Agent Instance, User, Infra Provider, Attestor — and how they interact, as shared vocabulary ahead of any standardization effort Task 2: A protocol-agnostic identity and trust stack covering authentication, discovery, identification, attestation, authorization, and delegation, against which specific protocols can be assessed for completeness DISCUSSION QUESTIONS FOR TOMORROW Should the stack's function list be fixed now, or start minimal and expand as gaps surface? How does this reference stack relate to our other proposed WGs — identity naming, intent-based policy, attestation, discovery? Which body should host this reference model — IETF, FG-TIDA itself, or a neutral industry consortium?
Tools and Working Methods GitHub Space WG Charter model Specs beautifier Tool
How to move forward 3 virtual meetings We can start the work in GitHub! Meeting/Panel in Dubai GISEC?  https://gisec.ae/
A strong base, a clear boundary ITU-T SG17 · Security & Trust 13 25 Agentic AI work items already underway at SG17, across 5 Questions (Q1, Q2, Q7, Q10, Q16) a lead no other SDO has today The boundary is written in the Terms of Reference "The subject is not already addressed by work underway in ITU-T study groups…" (Rec. ITU-T A.7) "FG Chair and SG17 Chair will resolve on a case by case basis." No duplication: the FG supports, complements and informs SG17. Worked example: XSTR.magAI-behavior As SG17 Chair, I would consider proposing it to FG-TIDA: it needs broad community feedback, and it must be enriched against the FG frameworks and architectures to avoid blind spots. The real pressure is speed: we are far ahead of other SDOs, not of Agentic AI itself. We will resolve it with precision and collegiality. SG17 is a mature group, built for exactly this.
THANK YOU FOR YOUR PARTICIPATION