# drafts

name: w3c-UAAG20-Reference
rev: 00
time: 20151215
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:35:53.738465+00:00
source: w3c
source_id: UAAG20-Reference
source_url: https://www.w3.org/WAI/UA/UAAG20-Reference/
doc_status: Note
title:
  UAAG 2.0 Reference: Explanations, Examples, and Resources for User Agent Accessibility Guidelines 2.0

abstract:
  This document provides explanation of the intent of UAAG 2.0 success criteria, examples of implementation of the UAAG 2.0 guidelines, best practice recommendations and additional resources for the guidelines.


name: w3c-agent-attributes
rev: 00
title: Client-Specific Web Services by Using User Agent Attributes
time: 19971230
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:35:53.741796+00:00
source: w3c
source_id: agent-attributes
source_url: https://api.w3.org/specifications/agent-attributes/versions/19971230
doc_status: Note
abstract:
  This document describes a simple framework for realizing client-specific web services. The proposed method uses the client properties such as screen size and colors, available input methods, web page capacity, secondary storage size, product category, CPU type, and etc., which we call "User Agent Attributes". We also describe an implementation of this framework by using the User-Agent header in HTTP. This enables the client-specific services for various Internet information appliances like Internet-TVs, PDAs, and smart phones.


name: w3c-imagemap
rev: 00
title: Imagemapped Images and Image-Incapable User Agents
time: 19961127
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:35:53.745112+00:00
source: w3c
source_id: imagemap
source_url: https://api.w3.org/specifications/imagemap/versions/19961127
doc_status: Note
abstract:
  This memo discusses appropriate handling of documents containing imagemapped images in cases where the user-agent cannot display or otherwise process inline images. Typical examples where this is so are (i) text-only browsers such as lynx, text-to-speech or braille browsers; (ii) graphical browsers with disabled image loading; or (iii) information-gathering robots that do not retrieve or process inlined image files.


name: draft-duda-dnsop-dns-did
rev: 00
title: A DNS-Based Framework for Privacy-Preserving Identity
time: 2026-03-03T00:36:50Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-04T00:36:50Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Policy/governance", "Autonomous netops"]
tags: []
fetched_at: 2026-03-08T15:14:54.116698+00:00
source: ietf
abstract:
  This document presents a framework for privacy-preserving identity
     management based on DNS, supporting large-scale management of users,
     IoT devices, and AI agents.  It introduces Self-Certifying
     Identifiers (SIDs), User/Service Trustees as trusted proxies, and
     leverages DNSSEC-secured TXT records to bind public keys to
     identities.  The framework enables privacy-by-design, where real
     identities are hidden behind trusted entities, through privacy-
     preserving intermediarie.  Credentials bound to SIDs support role-
     based access control, while ephemeral tokens ensure short-lived
     authorization.  Although initially DNS-dependent, the model can
     extend to other directories like DIDs or IPFS.  This approach aligns
     with zero-trust architectures and supports automated, AI-driven
     interactions in future networks.

full_text:
  DNSOP                                                            A. Duda
  Internet-Draft                                             M. Korczynski
  Intended status: Informational                                 O. Hureau
  Expires: 3 September 2026  Univ. Grenoble Alpes, CNRS, Grenoble INP, LIG
                                                                  J. Zhang
                                                                 H. Labiod
                                       Huawei Technologies France S.A.S.U.
                                                              2 March 2026


           A DNS-Based Framework for Privacy-Preserving Identity
                        draft-duda-dnsop-dns-did-00

  Abstract

     This document presents a framework for privacy-preserving identity
     management based on DNS, supporting large-scale management of users,
     IoT devices, and AI agents.  It introduces Self-Certifying
     Identifiers (SIDs), User/Service Trustees as trusted proxies, and
     leverages DNSSEC-secured TXT records to bind public keys to
     identities.  The framework enables privacy-by-design, where real
     identities are hidden behind trusted entities, through privacy-
     preserving intermediarie.  Credentials bound to SIDs support role-
     based access control, while ephemeral tokens ensure short-lived
     authorization.  Although initially DNS-dependent, the model can
     extend to other directories like DIDs or IPFS.  This approach aligns
     with zero-trust architectures and supports automated, AI-driven
     interactions in future networks.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 3 September 2026.






  Duda, et al.            Expires 3 September 2026                [Page 1]


  Internet-Draft                   DNS-DID                      March 2026


  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Framework for DNS-Based Identity  . . . . . . . . . . . . . .   2
     3.  Self-Certifying Identifiers, Credentials, and Ephemeral
             Tokens  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.  DNS as a Public Directory of Identifiers  . . . . . . . . . .   5
     5.  DNS-Based Identities for Agents . . . . . . . . . . . . . . .   6
     6.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
     10. Normative References  . . . . . . . . . . . . . . . . . . . .   7
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

  1.  Introduction

     In this draft, we present a framework for Privacy-Preserving Identity
     Management based on DNS supporting large scale management of users,
     IoT devices, or AI agents.  It defines new entities involved in
     Identity Management, specifies Self-Certifying Identifiers based on
     public keys, and offers public keys stored in DNS as trust anchors.
     This design draws inspiration from the architecture of Decentralized
     Identifiers (DIDs) [W3C.DID-Core], particularly in the use of
     cryptographic derivation of identifiers, though this document focuses
     on DNS as the initial resolution layer.

  2.  Framework for DNS-Based Identity

     We can observe that the standard Self-Sovereign Identity frameworks
     place the User at the center and gives the user the control over
     unveiling its personal information.  However, there is a tension
     between Privacy and Trust:




  Duda, et al.            Expires 3 September 2026                [Page 2]


  Internet-Draft                   DNS-DID                      March 2026


     • the User wants to remain anonymous and do not unveil its personal
     information, which may end up in the situation in which other
     entities in the system will not trust its - nobody wants to interact
     with an anonymous interlocutor;

     • if the User discloses its real identity, other entities in the
     system may trust him.  The conclusion is that we need an entity that
     separates the User from other entities, hides its private attributes
     or personal information, and represents him with respect to other
     actors.  Such an intermediary—referred to as a Trustee—acts as a
     privacy-preserving proxy.  It manages identifiers and credentials on
     behalf of users or services, enabling authentication without exposing
     real identities.  Unlike centralized identity providers, this
     framework relies on cryptographic identifiers and DNSSEC to ensure
     trust without depending on any single administrative authority.

     The proposed architecture for management of identities includes the
     following entities:

     • *Users* – Identity Owners – correspond to persons or device owners
     who use and control their identifiers.  They may also control the
     identifiers of devices/agents they own.  The User entity may delegate
     the management of its identifiers to a trusted entity: a User Trustee
     entity.

     • *User Trustee* – provides support for registering identifiers on
     behalf of Users.  It takes care of the credentials and acts as a
     trusted proxy with respect to other entities.  The advantage of
     introducing the User Trustee entity is double: i) this kind of
     organisms or companies may gain reputation and be recognized as a
     trust provider, so trusted by relying parties (for example, the User
     entity, the Service entity, and the Service Trustee), ii) it hides
     the User from all interactions and unveiling its personal
     information, thus providing privacy-by-design.  The User Trustee
     operates based on technical transparency and auditable operations,
     rather than legal mandates.  Its trustworthiness stems from
     cryptographic proofs and operational accountability, not state-
     granted privileges.

     • *Service (or Server)* – the entity with respect to which persons
     and devices/agents want to authenticate and access authorized
     resources - the User entity may request access to a Service provided
     by the Service entity.  It uses identifiers and public keys to
     authenticate and authorize an Identity Owner or her devices/agents.
     The Service needs to trust either a User, a User Trustee, or
     Credential Issuers (in the simplest case, the Service Trustee).





  Duda, et al.            Expires 3 September 2026                [Page 3]


  Internet-Draft                   DNS-DID                      March 2026


     • *Service Trustee* – provides support for registering identifiers
     and public keys on behalf of Service entities.  In a symmetric way to
     the User Trustee entity, the Service Trustee entity may help the
     Service entity to manage its identities and the relationship with
     User entities and other Trustee entities.  The Service Trustee may
     create, update, and cancel Service identifiers stored in an
     appropriate form.  The Service Trustee entity may also be configured
     to issue the Credential to the User entity.  Its role to verify the
     Credential on behalf of the Service entity and the Service entity is
     configured to authorize the access further based on the verification
     result provided by the Service Trustee entity.  Instead of presenting
     Credentials directly to the Service entity, the User entity may first
     authenticate to the User Trustee entity.  Upon successful
     authentication, the User Trustee entity presents the Credential
     either to the Service entity or to the Service Trustee entity,
     facilitating secure and privacy-respecting interactions.  The Service
     entity may verify the Credential and authorize access to the
     requested Service based on the role or attributes indicated in the
     Credential.  In this process, the Service entity interacts with the
     User Trustee entity rather than the User entity directly, thus
     balancing privacy and trust of user identity.  Entities store all
     public information on Identities (Identifiers and Public Keys) in DNS
     in the TXT record associated with the given Identifier.

  3.  Self-Certifying Identifiers, Credentials, and Ephemeral Tokens

     A Self-Certifying Identifier (SID) is a concatenation of the Context
     and the Context-dependent Identifier.  We assume that the User
     generates a pair of keys: public key P and secret key S.  The
     Context-dependent Identifier (CI) is derived from a public key - it
     is the hash of public key P: SID = Context | CI, CI =
     base32(RIPEMD160(SHA256(P))), where SHA256 and RIPEMD160 are hash
     functions resulting in 256 and 160 bits, respectively, and base32 is
     a binary-to-text encoding scheme.  The Context provides the
     information about the type of the cryptographic system used for
     generating the keys.  The identifiers of all entities may be
     represented as follows:

     • User entity: sid_u, derived from the pair of keys (P_u and S_u),

     • Service entity: sid_s, derived from the pair of keys (P_s and S_s),

     • User Trustee entity: sid_tu, derived from the pair of keys (P_tu
     and S_tu),

     • Service Trustee entity: sid_ts, derived from the pair of keys (P_ts
     and S_ts).




  Duda, et al.            Expires 3 September 2026                [Page 4]


  Internet-Draft                   DNS-DID                      March 2026


     The User Trustee keeps the following information on behalf of the
     User entity: sid_u, sid_c and C, where sid_u is the identifier of the
     user entity, sid_c is the identifier of the Credential, and C is the
     Credential.  The user identifier is for a given connection to the
     Service entity with the Credential.

     The Credential is defined as follows:

     C =[sid_u, sid_c, role, SHA256(sidu, sidc, role)S_ts],

     where sid_u is the user identifier, sid_c is the credential ID, role
     is an attribute of the user entity (e.g., role=admin), and the hash
     on this information is signed by the Service Trustee entity (in a
     case where the credential issuer is the Service Trustee entity) with
     its secret key S_ts.  The Credential is kept secret by the User
     Trustee entity and presented to the Service entity in a form
     encrypted by the public key of the Service entity upon connection so
     only the Service entity may read it.

     The Service entity is configured to authorize the access by
     generating an Ephemeral Token (ET) based on the Credential, and
     authorizing the access based on the ET.

     ET is a short-lived token that enforces security by leaving attackers
     with a tiny window exploit, for example, stolen credentials.  The
     idea is that SID identifiers are persistent (which may be stored in
     DNS) and only ET is used in the actual connection request to a
     service entity to authorize access by the user entity.  ET is defined
     as follows:

     ET = [SHA256(T, L, sid_u, sid_c, K_s)]S_ts,

     where T is the timestamp, L is the token lifetime, sid_u is the user
     identifier, sid_c is the credential ID, K_s is a shared key, and the
     hash on this information is signed by the service trustee entity with
     its secret key S_ts.

  4.  DNS as a Public Directory of Identifiers

     For the main entities of the framework: User, User Trustee, Server,
     and Server Trustee, their identifiers and the corresponding public
     keys are stored in DNS and are publicly available.  The identifiers
     and the corresponding public keys stored in the TXT record are
     cryptographically signed in DNS and when an entity receives a public
     key associated with a given identifier, DNSSEC provides trust
     comparable to conventional Public Key Infrastructures (PKI) used in
     HTTPS.




  Duda, et al.            Expires 3 September 2026                [Page 5]


  Internet-Draft                   DNS-DID                      March 2026


     Assume that the identifier of the user entity sid_u is registered
     under a user trustee-controlled domain, e.g., trustee.id.  So, sid_u
     may exist as the following fully qualified domain name (FQDN):
     1exq5yqbl6l48pf0fu7juhltjkrbu2rxf.trustee.id.

     Other identifiers and keys may be stored in the TXT DNS record
     associated with the FDQN in the format based on request for comments
     (RFC) 6376 used for domain keys identified mail (DKIM), which uses
     DNS TXT records to store lists of tag/value pairs encoded in the form
     of tag=value separated by a semi-colon (;).

     So, for a given SID user identifier:
     1exq5yqbl6l48pf0fu7juhltjkrbu2rxf,

     its associated identifiers and keys may be stored as the following
     TXT record:

     1exq5yqbl6l48pf0fu7juhltjkrbu2rxf TXT
     "sid=1exq5yqbl6l48pf0fu7juhltjkrbu2rxf;
     key=1caac9c64711f66e6ed71b37dc...;
     tid=16ed71b37dc5e69c5124fe93ee12446e1;
     cid=1g43wxdm35yxtjyuje72j64esenyneplk"

     Such publicly available and trusted information may allow other
     entities to authenticate the User entity, whose identifier being
     1exq5yqbl6l48pf0fu7juhltjkrbu2rxf, having the public key
     1caac9c64711f66e6ed71b37dc..., with respect to the Service entity
     represented by the Service Trustee entity
     16ed71b37dc5e69c5124fe93ee12446e1, using the Credential with the
     credential ID 1g43wxdm35yxtjyuje72j64esenyneplk.

  5.  DNS-Based Identities for Agents

     The identity framework can also support automated entities such as
     software agents or autonomous services.  These entities can be
     assigned SIDs and managed through User or Service Trustees, enabling
     secure and auditable interactions without human intervention.  Use
     cases include IoT automation, network management, and machine-to-
     machine (M2M) coordination, where accountability and role-based
     access control are required.











  Duda, et al.            Expires 3 September 2026                [Page 6]


  Internet-Draft                   DNS-DID                      March 2026


  6.  Conclusions

     We have presented a framework for Privacy-Preserving Identity
     Management based on DNS supporting large scale management of users,
     IoT devices, or AI agents.  Our approach to anchor trust is to rely
     on DNS as a directory of identities with DNSSEC guaranteeing the
     integrity of responses.  Note that this document is intended as an
     informational overview of a possible architecture.  It does not
     mandate any specific implementation, nor does it promote any
     commercial model.  Alternative directories such as DIDs or IPFS may
     also be used to store identifiers and public keys, enabling
     deployment in decentralized environments.  This framework is
     compatible with modern identity standards such as [W3C.DID-Core] and
     supports compact, secure token formats like [RFC8392], while
     leveraging DNSSEC in a manner consistent with [RFC8552].

  7.  Security Considerations

     TODO

  8.  IANA Considerations

  9.  Acknowledgements

     TODO

  10.  Normative References

     1.  *[W3C.DID-Core]* W3C, "Decentralized Identifiers (DIDs)", W3C
         Recommendation 10 July 2022, <https://www.w3.org/TR/did-core/
         (https://www.w3.org/TR/did-core/)>.

     2.  *[RFC8392]* Jones, M., Lengyel, T., and S.  Erdtman, "CBOR Web
         Token (CWT)", RFC 8392, DOI <https://doi.org/10.17487/RFC8392
         (https://doi.org/10.17487/RFC8392)>, May 2018.

     3.  *[RFC8552]* Finch, T., "SMTP Security via DANE TLS", RFC 8552,
         DOI <https://doi.org/10.17487/RFC8552 (https://doi.org/10.17487/
         RFC8552)>, April 2019.

  Authors' Addresses

     Andrzej Duda
     Univ. Grenoble Alpes, CNRS, Grenoble INP, LIG
     Email: Andrzej.Duda@imag.fr






  Duda, et al.            Expires 3 September 2026                [Page 7]


  Internet-Draft                   DNS-DID                      March 2026


     Maciej Korczynski
     Univ. Grenoble Alpes, CNRS, Grenoble INP, LIG
     Email: maciej.korczynski@grenoble-inp.fr


     Olivier Hureau
     Univ. Grenoble Alpes, CNRS, Grenoble INP, LIG
     Email: olivier@hureau.com


     Jun Zhang
     Huawei Technologies France S.A.S.U.
     Email: junzhang1@huawei.com


     Houda Labiod
     Huawei Technologies France S.A.S.U.
     Email: houda.labiod@huawei.com

































  Duda, et al.            Expires 3 September 2026                [Page 8]


name: itu-t-y-3172
rev: 00
title: ITU-T Y.3172: Architectural framework for machine learning in future networks including IMT-2020
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:27.742160+00:00
source: itu
source_id: Y.3172
source_url: https://www.itu.int/rec/T-REC-Y.3172
doc_status: published
abstract:
  ITU-T Recommendation Y.3172 on AI/ML architecture: Architectural framework for machine learning in future networks including IMT-2020


name: itu-t-y-3173
rev: 00
title: ITU-T Y.3173: Framework for evaluating intelligence levels of future networks including IMT-2020
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:27.769261+00:00
source: itu
source_id: Y.3173
source_url: https://www.itu.int/rec/T-REC-Y.3173
doc_status: published
abstract:
  ITU-T Recommendation Y.3173 on AI/ML architecture: Framework for evaluating intelligence levels of future networks including IMT-2020


name: itu-t-y-3174
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:27.776311+00:00
source: itu
source_id: Y.3174
source_url: https://www.itu.int/rec/T-REC-Y.3174
doc_status: published
title:
  ITU-T Y.3174: Framework for data handling to enable machine learning in future networks including IMT-2020

abstract:
  ITU-T Recommendation Y.3174 on AI/ML architecture: Framework for data handling to enable machine learning in future networks including IMT-2020


name: itu-t-y-3176
rev: 00
title: ITU-T Y.3176: Machine learning marketplace integration in future networks including IMT-2020
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:27.779368+00:00
source: itu
source_id: Y.3176
source_url: https://www.itu.int/rec/T-REC-Y.3176
doc_status: published
abstract:
  ITU-T Recommendation Y.3176 on AI/ML architecture: Machine learning marketplace integration in future networks including IMT-2020


name: itu-t-y-3177
rev: 00
title: ITU-T Y.3177: Architectural framework of AI-as-a-Service to enable AI services in future networks
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:27.782418+00:00
source: itu
source_id: Y.3177
source_url: https://www.itu.int/rec/T-REC-Y.3177
doc_status: published
abstract:
  ITU-T Recommendation Y.3177 on AI/ML architecture: Architectural framework of AI-as-a-Service to enable AI services in future networks


name: itu-t-y-3178
rev: 00
title: ITU-T Y.3178: Requirements and framework of federated machine learning
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:27.785501+00:00
source: itu
source_id: Y.3178
source_url: https://www.itu.int/rec/T-REC-Y.3178
doc_status: published
abstract:
  ITU-T Recommendation Y.3178 on Federated learning: Requirements and framework of federated machine learning


name: itu-t-y-3179
rev: 00
title: ITU-T Y.3179: Architectural framework for AI-based network automation
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:27.789259+00:00
source: itu
source_id: Y.3179
source_url: https://www.itu.int/rec/T-REC-Y.3179
doc_status: published
abstract:
  ITU-T Recommendation Y.3179 on Network automation: Architectural framework for AI-based network automation


name: itu-t-y-3180
rev: 00
title: ITU-T Y.3180: Framework for multi-domain ML pipeline in future networks
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:27.792438+00:00
source: itu
source_id: Y.3180
source_url: https://www.itu.int/rec/T-REC-Y.3180
doc_status: published
abstract:
  ITU-T Recommendation Y.3180 on AI/ML architecture: Framework for multi-domain ML pipeline in future networks


name: itu-t-y-3181
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:27.795471+00:00
source: itu
source_id: Y.3181
source_url: https://www.itu.int/rec/T-REC-Y.3181
doc_status: published
title:
  ITU-T Y.3181: Architectural framework for trustworthy networking based on machine learning technology

abstract:
  ITU-T Recommendation Y.3181 on Trustworthy AI: Architectural framework for trustworthy networking based on machine learning technology


name: itu-t-y-3530
rev: 00
title: ITU-T Y.3530: Cloud computing — Overview of machine learning in future networks
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:27.798882+00:00
source: itu
source_id: Y.3530
source_url: https://www.itu.int/rec/T-REC-Y.3530
doc_status: published
abstract:
  ITU-T Recommendation Y.3530 on Cloud AI: Cloud computing — Overview of machine learning in future networks


name: itu-t-y-3531
rev: 00
title: ITU-T Y.3531: Cloud computing — Functional architecture for machine learning as a service
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:27.801938+00:00
source: itu
source_id: Y.3531
source_url: https://www.itu.int/rec/T-REC-Y.3531
doc_status: published
abstract:
  ITU-T Recommendation Y.3531 on Cloud AI: Cloud computing — Functional architecture for machine learning as a service


name: itu-t-y-4907
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:27.807934+00:00
source: itu
source_id: Y.4907
source_url: https://www.itu.int/rec/T-REC-Y.4907
doc_status: published
title:
  ITU-T Y.4907: Reference architecture for intelligent transportation systems communication network using AI

abstract:
  ITU-T Recommendation Y.4907 on AI transport: Reference architecture for intelligent transportation systems communication network using AI


name: itu-t-x-1381
rev: 00
title: ITU-T X.1381: Framework for AI risk assessment in telecommunication networks
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:27.810935+00:00
source: itu
source_id: X.1381
source_url: https://www.itu.int/rec/T-REC-X.1381
doc_status: published
abstract:
  ITU-T Recommendation X.1381 on AI security: Framework for AI risk assessment in telecommunication networks


name: itu-t-x-1382
rev: 00
title: ITU-T X.1382: Security requirements for AI-based solutions in telecommunication networks
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:27.813943+00:00
source: itu
source_id: X.1382
source_url: https://www.itu.int/rec/T-REC-X.1382
doc_status: published
abstract:
  ITU-T Recommendation X.1382 on AI security: Security requirements for AI-based solutions in telecommunication networks


name: itu-t-x-1383
rev: 00
title: ITU-T X.1383: Assessment criteria for trustworthiness of AI-based telecommunication services
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:27.817003+00:00
source: itu
source_id: X.1383
source_url: https://www.itu.int/rec/T-REC-X.1383
doc_status: published
abstract:
  ITU-T Recommendation X.1383 on Trustworthy AI: Assessment criteria for trustworthiness of AI-based telecommunication services


name: itu-t-x-1384
rev: 00
title: ITU-T X.1384: Security threats and risk treatment measures for AI-based telecommunication systems
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:27.820101+00:00
source: itu
source_id: X.1384
source_url: https://www.itu.int/rec/T-REC-X.1384
doc_status: published
abstract:
  ITU-T Recommendation X.1384 on AI security: Security threats and risk treatment measures for AI-based telecommunication systems


name: iso-iec-42001-2023
rev: 00
title: ISO/IEC 42001:2023: Information technology — Artificial intelligence — Management system
time: 2023
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:30.876839+00:00
source: iso
source_id: ISO/IEC 42001:2023
source_url: https://www.iso.org/standard/ISO%2FIEC%2042001.html
doc_status: published
abstract:
  Specifies requirements for establishing, implementing, maintaining, and continually improving an AI management system within organizations.


name: iso-iec-38507-2022
rev: 00
abstract: Provides guidance on the governance implications of AI for governing bodies of organizations.
time: 2022
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:30.902549+00:00
source: iso
source_id: ISO/IEC 38507:2022
source_url: https://www.iso.org/standard/ISO%2FIEC%2038507.html
doc_status: published
title:
  ISO/IEC 38507:2022: Information technology — Governance of IT — Governance implications of the use of AI


name: iso-iec-5339-2024
rev: 00
title: ISO/IEC 5339:2024: Information technology — AI — Guidance for AI applications
time: 2024
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:30.909036+00:00
source: iso
source_id: ISO/IEC 5339:2024
source_url: https://www.iso.org/standard/ISO%2FIEC%205339.html
doc_status: published
abstract:
  Provides guidance on how to apply AI within organizations, including use case analysis and risk assessment.


name: iso-iec-2382-28-1995
rev: 00
abstract: <p>Defines basic concepts related to artificial intelligence and expert systems.</p>
time: 1995-12-27
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:30.929856+00:00
source: iso
source_id: ISO/IEC 2382-28:1995
source_url: https://www.iso.org/standard/ISO%2FIEC%202382-28.html
doc_status: 9599
title:
  ISO/IEC 2382-28:1995: Information technology — Vocabulary — Part 28: Artificial intelligence — Basic concepts and expert systems


name: iso-iec-2382-29-1999
rev: 00
time: 1999-08-19
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:30.932873+00:00
source: iso
source_id: ISO/IEC 2382-29:1999
source_url: https://www.iso.org/standard/ISO%2FIEC%202382-29.html
doc_status: 9599
title:
  ISO/IEC 2382-29:1999: Information technology — Vocabulary — Part 29: Artificial intelligence — Speech recognition and synthesis

abstract:
  ISO/IEC standard: Information technology — Vocabulary — Part 29: Artificial intelligence — Speech recognition and synthesis. Committee: ISO/IEC JTC 1.


name: iso-iec-2382-31-1997
rev: 00
time: 1997-12-25
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:30.935987+00:00
source: iso
source_id: ISO/IEC 2382-31:1997
source_url: https://www.iso.org/standard/ISO%2FIEC%202382-31.html
doc_status: 9599
title:
  ISO/IEC 2382-31:1997: Information technology — Vocabulary — Part 31: Artificial intelligence — Machine learning

abstract:
  ISO/IEC standard: Information technology — Vocabulary — Part 31: Artificial intelligence — Machine learning. Committee: ISO/IEC JTC 1.


name: iso-iec-2382-34-1999
rev: 00
time: 1999-08-19
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:30.939039+00:00
source: iso
source_id: ISO/IEC 2382-34:1999
source_url: https://www.iso.org/standard/ISO%2FIEC%202382-34.html
doc_status: 9599
title:
  ISO/IEC 2382-34:1999: Information technology — Vocabulary — Part 34: Artificial intelligence — Neural networks

abstract:
  ISO/IEC standard: Information technology — Vocabulary — Part 34: Artificial intelligence — Neural networks. Committee: ISO/IEC JTC 1.


name: iso-tr-15801-2004
rev: 00
time: 2004-01-16
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:30.941678+00:00
source: iso
source_id: ISO/TR 15801:2004
source_url: https://www.iso.org/standard/ISO%2FTR%2015801.html
doc_status: 9599
title:
  ISO/TR 15801:2004: Electronic imaging — Information stored electronically — Recommendations for trustworthiness and reliability

abstract:
  <p>ISO 15801:2004 describes the implementation and operation of information management systems which store information electronically and where the issues of trustworthiness, reliability, authenticity and integrity are important. The whole life cycle of a stored electronic document is covered, from initial capture to eventual destruction.</p><p>ISO 15801:2004 is for use with any information management system, including traditional document imaging, workflow and COLD/ERM technologies, and using any type of electronic storage medium including WORM and rewritable technologies.</p><p>ISO 15801:2004 does not cover processes used to evaluate the authenticity of information prior to it being stored or imported into the system. However, it can be used to demonstrate that output from the system is a true reproduction of the original document.</p>


name: iso-np-20319
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:30.973068+00:00
source: iso
source_id: ISO/NP 20319
source_url: https://www.iso.org/standard/ISO%2FNP%2020319.html
doc_status: 1098
title:
  ISO/NP 20319: Profiles of control network residing on Ethernet for real-time communication/autonomous decentralized system

abstract:
  ISO/IEC standard: Profiles of control network residing on Ethernet for real-time communication/autonomous decentralized system. Committee: ISO/TC 184/SC 5.


name: iso-24801-2-2007
rev: 00
time: 2007-02-09
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:30.979287+00:00
source: iso
source_id: ISO 24801-2:2007
source_url: https://www.iso.org/standard/ISO%2024801-2.html
doc_status: 9599
title:
  ISO 24801-2:2007: Recreational diving services — Safety related minimum requirements for the training of recreational scuba divers — Part 2: Level 2 — Autonomous diver

abstract:
  <p>ISO 24801-2:2007 specifies the competencies that a scuba diver has to have achieved in order for a training organization to award the scuba diver certification indicating that he has met or exceeded scuba diver level 2 -- 'Autonomous diver' and assessment of these competencies.</p><p>It also specifies conditions under which training has to be provided, in addition to the general requirements for recreational diving service provision specified in ISO 24803. </p><p>ISO 24801-2:2007 applies only to contractual training and certification in recreational scuba diving.</p>


name: iso-iec-42006-2025
rev: 00
time: 2025-07-07
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:30.982408+00:00
source: iso
source_id: ISO/IEC 42006:2025
source_url: https://www.iso.org/standard/ISO%2FIEC%2042006.html
doc_status: 6060
title:
  ISO/IEC 42006:2025: Information technology — Artificial intelligence — Requirements for bodies providing audit and certification of artificial intelligence management systems

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document specifies additional requirements to ISO/IEC 17021-1. The requirements contained in this document, when implemented, support the demonstration of competence, consistency and reliability by the bodies performing auditing and certification of an artificial intelligence management system (AIMS) according to ISO/IEC 42001 for organizations that provide, develop or use AI systems.</span></p><p class='MsoBodyText'><span lang='EN-GB'>Certification of AIMS is a third-party conformity assessment activity (as described in ISO/IEC 17000:2020, 4.5), and bodies performing this activity are third-party conformity assessment bodies.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document also provides the necessary information and confidence to customers about the way certification has been granted.</span></p><p class='Note'><span lang='EN-GB'>NOTE<span style='mso-tab-count: 1;'>            </span>This document can be used as a criteria document for accreditation or peer assessment.</span></p>


name: iso-22373-2025
rev: 00
time: 2025-11-19
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:30.985591+00:00
source: iso
source_id: ISO 22373:2025
source_url: https://www.iso.org/standard/ISO%2022373.html
doc_status: 6060
title:
  ISO 22373:2025: Security and resilience — Authenticity, integrity and trust for products and documents — Framework for establishing trustworthy supply and value chains

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document establishes a framework to support stakeholders in supply and value chains to ensure the chain of trustworthiness regarding the properties of their products and production processes.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document provides guidelines to identify information relevant to trustworthiness to be exchanged between supply and value chain stakeholders. It also provides an interoperable data structure that is required for supply and value chain stakeholders to negotiate and exchange information relevant to trustworthiness.</span></p><p class='MsoBodyText'><span lang='EN-GB'>The guidelines set out in this document are generic and are intended to be applicable to all organizations and products, regardless of type, size or nature.</span></p>


name: iso-tr-15801-2009
rev: 00
time: 2009-10-09
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:30.988533+00:00
source: iso
source_id: ISO/TR 15801:2009
source_url: https://www.iso.org/standard/ISO%2FTR%2015801.html
doc_status: 9599
title:
  ISO/TR 15801:2009: Document management — Information stored electronically — Recommendations for trustworthiness and reliability

abstract:
  <p>ISO/TR 15801:2009 describes the implementation and operation of document management systems that can be considered to store electronic information in a trustworthy and reliable manner.</p><p>ISO/TR 15801:2009 is for use by any organization that uses a document management system to store authentic, reliable and usable/readable electronic information over time. Such systems incorporate policies, procedures, technology and audit requirements that ensure that the integrity of the electronic information is maintained during storage.</p><p>ISO/TR 15801:2009 does not cover processes used to evaluate whether information can be considered to be authentic prior to it being stored or imported into the system. However, it can be used to demonstrate that, once the information is stored, output from the system will be a true and accurate reproduction of the original.</p>


name: iso-39003-2023
rev: 00
time: 2023-07-27
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:30.991240+00:00
source: iso
source_id: ISO 39003:2023
source_url: https://www.iso.org/standard/ISO%2039003.html
doc_status: 6060
title:
  ISO 39003:2023: Road traffic safety (RTS) — Guidance on ethical considerations relating to safety for autonomous vehicles

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document gives guidance on ethical considerations with regards to road traffic safety of autonomous vehicles (AVs).</span></p><p class='MsoBodyText'><span lang='EN-GB'>It is applicable to vehicles in level 5 mode according to SAE J3016 in 2022, as part of its report.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document does not apply to the technical method used to control the decision-making process, nor does it give any guidance on the desired outcomes of those decisions; it gives guidance on ethical aspects for consideration in the design of decision-making process.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document does not set requirements for the outcomes of ethical decisions, nor does it offer guidance on methodology. It only details aspects of the behaviour of AVs for which considerations may be made by the designer/manufacturer to ensure that key aspects are not overlooked or disregarded.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document does not offer the technical precision to prescribe the required controls but would, rather, offer a set of “protocol guidelines” that all decision makers regarding automated driving could choose to self-certify against to assure that the desired necessary ethical considerations were addressed during design and effectively controlled.</span></p>


name: iso-ts-12813-2009
rev: 00
time: 2009-11-04
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:30.994098+00:00
source: iso
source_id: ISO/TS 12813:2009
source_url: https://www.iso.org/standard/ISO%2FTS%2012813.html
doc_status: 9599
title:
  ISO/TS 12813:2009: Electronic fee collection — Compliance check communication for autonomous systems

abstract:
  <p>ISO/TS 12813:2009 defines requirements for short-range communication for the purposes of compliance checking in autonomous electronic fee-collecting (EFC) systems. Compliance checking communication (CCC) takes place between a road vehicle's on-board equipment (OBE) and an outside interrogator (road-side mounted equipment, mobile device or hand‑held unit), and serves to establish whether the data that are delivered by the OBE correctly reflect the road usage of the corresponding vehicle according to the rules of the pertinent toll regime.</p><p>The operator of the compliance checking interrogator is assumed to be part of the toll charging role as defined in ISO 17573. The CCC permits identification of the OBE, vehicle and contract, and verification of whether the driver has fulfilled his obligations and the checking status and performance of the OBE. The CCC reads, but does not write, OBE data. </p><p>ISO/TS 12813:2009 is applicable to OBE in an autonomous mode of operation; it is not applicable to compliance checking in dedicated short-range communication (DSRC)-based charging systems. It defines data syntax and semantics, but does not define a communication sequence. All the attributes defined herein are required in any OBE claimed to be compliant with ISO/TS 12813:2009, even if some values are set to “not defined” in cases where a certain functionality is not present in an OBE. The interrogator is free to choose which attributes are read, as well as the sequence in which they are read. In order to achieve compatibility with existing systems, the communication makes use of the attributes defined in ISO 14906 wherever possible. </p><p>The CCC is suitable for a range of short‑range communication media. Specific definitions are given for the CEN DSRC specified in EN 15509, as well as for the use of ISO CALM IR, UNI DSRC and ARIB DSRC as alternatives to the CEN DSRC. The attributes and functions defined are for compliance checking by means of the DSRC communication 


name: iso-ts-17575-1-2010
rev: 00
time: 2010-06-10
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:30.997249+00:00
source: iso
source_id: ISO/TS 17575-1:2010
source_url: https://www.iso.org/standard/ISO%2FTS%2017575-1.html
doc_status: 9599
title:
  ISO/TS 17575-1:2010: Electronic fee collection — Application interface definition for autonomous systems — Part 1: Charging

abstract:
  <p>ISO/TS 17575‑1:2010 defines the format and semantic of the data exchange between a Front End (OBE plus optional proxy) and corresponding Back Ends in autonomous toll regimes. ISO/TS 17575‑1:2010 deals with the definition of the data elements used to report charging details from the Front End to the CE and to receive data which can be used to re-configure the ongoing process of gathering charge relevant information in the Front End.</p><p>The data defined in ISO/TS 17575‑1:2010 is used to generate charge reports that contain information about the road usage of a vehicle for certain time intervals. The contents of these charge reports might vary between toll regimes. A toll regime comprises a set of rules for charging, including the charged network, the charging principles, the liable vehicles and a definition of the required contents of the charge report.</p><p>The data defined in ISO/TS 17575‑1:2010 are exchanged using an open definition of a communication stack as defined in ISO/TS 17575‑2.</p><p>The definitions in ISO/TS 17575‑1:2010 comprise:</p><ul><li>reporting data, i.e. data for transferring road usage data from Front End to Back End, including a response from the Back End towards the Front End;</li><li>contract data, i.e. data for identifying contractually essential entities;</li><li>road usage data, i.e. data for reporting the amount of road usage;</li><li>account data for managing a payment account;</li><li>versioning data;</li><li>compliance checking data, i.e. data imported from ISO/TS 12813, which are required in Compliance Checking Communications.</li></ul>


name: iso-ts-17575-2-2010
rev: 00
time: 2010-06-10
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.000398+00:00
source: iso
source_id: ISO/TS 17575-2:2010
source_url: https://www.iso.org/standard/ISO%2FTS%2017575-2.html
doc_status: 9599
title:
  ISO/TS 17575-2:2010: Electronic fee collection — Application interface definition for autonomous systems — Part 2: Communication and connection to the lower layers

abstract:
  <p>ISO/TS 17575‑2:2010 defines how to convey all or parts of the data element structure defined in ISO/TS 17575‑1 over any communication stack and media suitable for this application. It is focussed on mobile communication links. However, wired links shall use the same methodology.</p><p>The communication interface shall be implemented as an API in the programming environment of choice for the Front End (FE) system. The definition of this API in concrete terms is outside of the scope of ISO/TS 17575‑2:2010. ISO/TS 17575‑2:2010 specifies an abstract API that defines the semantics of the concrete API. An example concrete API is presented in Annex C. Where no distinction is made between the abstract and concrete communications APIs the term 'communications API' or just 'API', can be used.</p>


name: iso-ts-17575-3-2011
rev: 00
time: 2011-04-11
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.003493+00:00
source: iso
source_id: ISO/TS 17575-3:2011
source_url: https://www.iso.org/standard/ISO%2FTS%2017575-3.html
doc_status: 9599
title:
  ISO/TS 17575-3:2011: Electronic fee collection — Application interface definition for autonomous systems — Part 3: Context data

abstract:
  <p>ISO/TS 17575 defines the information exchange between the Front End and the Back End in Electronic Fee Collection (EFC) based on autonomous on-board equipment (OBE). ISO/TS 17575-3:2011 defines the data to be used for a description of individual charging systems in terms of charged geographical objects and charging and reporting rules. For every Toll Charger's system, attributes defined in ISO/TS 17575-3:2011 are used to transfer data to the Front End in order to instruct it which data to collect and report.</p>


name: iso-ts-17575-4-2011
rev: 00
time: 2011-04-11
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.006396+00:00
source: iso
source_id: ISO/TS 17575-4:2011
source_url: https://www.iso.org/standard/ISO%2FTS%2017575-4.html
doc_status: 9599
title:
  ISO/TS 17575-4:2011: Electronic fee collection — Application interface definition for autonomous systems — Part 4: Roaming

abstract:
  <p>ISO/TS 17575 defines the information exchange between the Front End and the Back End in Electronic Fee Collection (EFC) based on autonomous on-board equipment (OBE). ISO/TS 17575-4:2011 defines the functional details and data elements required to operate more than one EFC regime in parallel. The domains of these EFC regimes may or may not overlap. The charge rules of different overlapping EFC regimes may be linked, i.e. they may include rules that an area pricing scheme shall not be charged if an overlapping toll road is used and already paid for.</p>


name: iso-iec-30147-2021
rev: 00
time: 2021-08-17
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.009217+00:00
source: iso
source_id: ISO/IEC 30147:2021
source_url: https://www.iso.org/standard/ISO%2FIEC%2030147.html
doc_status: 9092
title:
  ISO/IEC 30147:2021: Information technology — Internet of things — Methodology for trustworthiness of IoT system/service

abstract:
  ISO/IEC standard: Information technology — Internet of things — Methodology for trustworthiness of IoT system/service. Committee: ISO/IEC JTC 1/SC 41.


name: iso-iec-ts-30149-2024
rev: 00
title: ISO/IEC TS 30149:2024: Internet of Things (IoT) — Trustworthiness principles
time: 2024-05-27
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.011939+00:00
source: iso
source_id: ISO/IEC TS 30149:2024
source_url: https://www.iso.org/standard/ISO%2FIEC%20TS%2030149.html
doc_status: 6060
abstract:
  <p>This document provides principles for IoT trustworthiness based on ISO/IEC 30141 - IoT Reference Architecture.</p>


name: iso-iec-30184-2024
rev: 00
time: 2024-12-11
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.014736+00:00
source: iso
source_id: ISO/IEC 30184:2024
source_url: https://www.iso.org/standard/ISO%2FIEC%2030184.html
doc_status: 6060
title:
  ISO/IEC 30184:2024: Internet of Things (IoT) — Autonomous IoT object identification in connected home — Requirements and framework

abstract:
  <p>This document specifies the following items for the autonomous IoT object identification in a connected home:</p><p>– requirements;</p><p>– architecture, functional entities and interfaces;</p><p>– operation procedures.</p><p>Information model formats, data formats, and identifier assignment are out of scope of this document.</p>


name: iso-ts-13141-2010
rev: 00
time: 2010-02-11
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.017475+00:00
source: iso
source_id: ISO/TS 13141:2010
source_url: https://www.iso.org/standard/ISO%2FTS%2013141.html
doc_status: 9599
title:
  ISO/TS 13141:2010: Electronic fee collection — Localisation augmentation communication for autonomous systems

abstract:
  <p>ISO/TS 13141:2010 establishes requirements for short-range communication for the purposes of augmenting the localisation in autonomous electronic fee collection (EFC) systems. Localisation augmentation serves to inform OBE about geographical location and the identification of a charge object. ISO/TS 13141:2010 specifies the provision of location and heading information and security means to protect from the manipulation of the OBE with false road-side equipment (RSE). </p><p>The localisation augmentation communication takes place between an OBE in a vehicle and fixed road-side equipment. ISO/TS 13141:2010 is applicable to OBE in an autonomous mode of operation. </p><p>ISO/TS 13141:2010 defines attributes and functions for the purpose of localisation augmentation, by making use of the DSRC communication services provided by DSRC Layer 7, and makes these LAC attributes and functions available to the LAC applications at the RSE and the OBE. Attributes and functions are defined on the level of Application Data Units.</p>


name: iso-awi-29999
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.020670+00:00
source: iso
source_id: ISO/AWI 29999
source_url: https://www.iso.org/standard/ISO%2FAWI%2029999.html
doc_status: 2000
title:
  ISO/AWI 29999: Education and learning services — Application of Artificial Intelligence (AI) Technology — Ethical Guidelines

abstract:
  This proposal is intended to provide ethical recommendations and guidelines for the application of artificial intelligence (AI) technology in education and learning services. It addresses general ethical principles, integrated framework, key factors, essential actions for applying AI technology in education and learning servicesThis proposal does not cover AI technologies or other information technology recommendations and guidelines that are defined or addressed by other standards.This proposal is applicable to all organizations providing education and learning services, including commercial entities, public services, and not-for-profit organizations.


name: iso-16363-2012
rev: 00
time: 2012-02-14
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.024388+00:00
source: iso
source_id: ISO 16363:2012
source_url: https://www.iso.org/standard/ISO%2016363.html
doc_status: 9599
title:
  ISO 16363:2012: Space data and information transfer systems — Audit and certification of trustworthy digital repositories

abstract:
  <p>ISO 16363:2012 defines a recommended practice for assessing the trustworthiness of digital repositories. It is applicable to the entire range of digital repositories. ISO 16363:2012 can be used as a basis for certification.</p>


name: iso-iec-dis-27090
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.027968+00:00
source: iso
source_id: ISO/IEC DIS 27090
source_url: https://www.iso.org/standard/ISO%2FIEC%20DIS%2027090.html
doc_status: 4060
title:
  ISO/IEC DIS 27090: Cybersecurity — Artificial Intelligence — Guidance for addressing security threats and compromises to artificial intelligence systems

abstract:
  <p class='MsoBodyText' style='margin: 4.5pt 59.4pt .0001pt 19.85pt;'>This document <span style='color: black; mso-color-alt: windowtext; background: yellow;'>addresses </span>security threats and <span style='color: black; mso-color-alt: windowtext; background: yellow;'>compromises</span> specific to artificial intelligence (AI) systems. <span style='color: black; mso-color-alt: windowtext; background: yellow;'>This</span> document aims to provide information to organizations to help them better understand the consequences of security threats specific to AI systems, throughout their life cycle, and descriptions of how to detect and mitigate such threats.</p><p class='MsoBodyText' style='margin-left: 0cm;'> </p><p><span style='font-size: 11.0pt; font-family: 'Times New Roman',serif; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;'>This document is applicable to all types and sizes of organizations, including public and private companies, government entities, and not-for-profit organizations, that develop or use AI systems</span></p>


name: iso-iec-dis-27091
rev: 00
title: ISO/IEC DIS 27091: Cybersecurity and Privacy — Artificial Intelligence — Privacy protection
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.031255+00:00
source: iso
source_id: ISO/IEC DIS 27091
source_url: https://www.iso.org/standard/ISO%2FIEC%20DIS%2027091.html
doc_status: 4060
abstract:
  This document provides guidance for organizations to address privacy risks in artificial intelligence (AI) systems and machine learning (ML) models. The guidance in this document helps organizations identify privacy risks throughout the AI system lifecycle, and establishes mechanisms to evaluate the consequences of and treat such risks.This document is applicable to all types and sizes of organizations, including public and privatecompanies, government entities, and not-for-profit organizations that develop or use AI systems.


name: iso-16919-2014
rev: 00
time: 2014-10-29
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.034138+00:00
source: iso
source_id: ISO 16919:2014
source_url: https://www.iso.org/standard/ISO%2016919.html
doc_status: 9599
title:
  ISO 16919:2014: Space data and information transfer systems — Requirements for bodies providing audit and certification of candidate trustworthy digital repositories

abstract:
  <p>ISO 16919:2014 is meant primarily for those setting up and managing the organization performing the auditing and certification of digital repositories.</p><p>It should also be of use to those who work in or are responsible for digital repositories seeking objective measurement of the trustworthiness of their repository and wishing to understand the processes involved.</p><p>The main purpose is to define a CCSDS Recommended Practice (and ISO International Standard) on which to base the operations of the organization(s) which assess the trustworthiness of digital repositories using ISO 16363 and provide the appropriate certification. ISO 16919:2014 specifies requirements for bodies providing audit and certification of digital repositories, based on the metrics contained within ISO/IEC 17021 and CCSDS 652.0-M-1/ISO 16363. It is primarily intended to support the accreditation of bodies providing such certification.</p><p>ISO/IEC 17021 provides the bulk of the requirements on bodies offering audit and certification for general types of management systems. However, for each specific type of system, specific additional requirements will be needed, for example, to specify the standard against which the audit is to be made and the qualifications which auditors require.</p><p>ISO 16919:2014 provides the (small number of) specific additions required for bodies providing audit and certification of candidate trustworthy digital repositories. Trustworthy here means that they can be trusted to maintain, over the long-term, the understandability and usability of digitally encoded information placed into their safekeeping.</p><p>In order improve readability, the clause numbers are kept consistent with those of ISO/IEC 17021. Some subclauses are applicable as they stand, and these are simply enumerated; otherwise additions to subclauses are explicitly given. In the former case, the clauses may consist of just a few sentences. As a result, this document must be read in conjunction 


name: iso-24801-2-2014
rev: 00
time: 2014-03-31
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.037515+00:00
source: iso
source_id: ISO 24801-2:2014
source_url: https://www.iso.org/standard/ISO%2024801-2.html
doc_status: 9093
title:
  ISO 24801-2:2014: Recreational diving services — Requirements for the training of recreational scuba divers — Part 2: Level 2 — Autonomous diver

abstract:
  <p>ISO 24801-2:2014 specifies the competencies required of a scuba diver in order to obtain a scuba diver qualification from a training organization attesting that he/she has met or exceeded scuba diver level 2 ('Autonomous diver'), and specifies evaluation criteria for these competencies.</p><p>It also specifies the conditions under which training is provided, in addition to the general requirements for recreational diving service provision in accordance with ISO 24803.</p><p>ISO 24801-2:2014 applies to training and evaluation in recreational scuba diving.</p>


name: iso-17757-2017
rev: 00
time: 2017-10-03
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.040858+00:00
source: iso
source_id: ISO 17757:2017
source_url: https://www.iso.org/standard/ISO%2017757.html
doc_status: 9599
title:
  ISO 17757:2017: Earth-moving machinery and mining — Autonomous and semi-autonomous machine system safety

abstract:
  <p>ISO 17757 provides safety requirements for autonomous machines and semi-autonomous machines used in earth-moving and mining operations, and their autonomous or semi-autonomous machine systems (ASAMS). It specifies safety criteria both for the machines and their associated systems and infrastructure, including hardware and software, and provides guidance on safe use in their defined functional environments during the machine and system life cycle. It also defines terms and definitions related to ASAMS.</p><p>It is applicable to autonomous and semi-autonomous versions of the earth-moving machinery (EMM) defined in ISO 6165 and of mobile mining machines used in either surface or underground applications. Its principles and many of its provisions can be applied to other types of autonomous or semi‑autonomous machines used on the worksites.</p><p>Safety requirements for general mobile EMM and mining machines, as well as operators, trainers or passengers on the machine, are given by other International Standards (e.g. ISO 20474, ISO 19296). ISO 17757 addresses additional hazards specific and relevant to ASAMS when used as intended.</p><p>It is not applicable to remote control capability (covered by ISO 15817) or function-specific automated features, except when those features are used as part of ASAMS.</p>


name: iso-18829-2017
rev: 00
title: ISO 18829:2017: Document management — Assessing ECM/EDRM implementations — Trustworthiness
time: 2017-06-01
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.044521+00:00
source: iso
source_id: ISO 18829:2017
source_url: https://www.iso.org/standard/ISO%2018829.html
doc_status: 9093
abstract:
  <p>ISO 18829:2017 identifies activities and operations that an organization needs to perform, or have performed, to evaluate whether the electronically stored information (ESI) is or was maintained in a reliable and trustworthy environment(s). These environments utilize content or records management technologies commonly referred to as either enterprise content management (ECM) or electronic document and records management (EDRM) enforcing organizational records management policies and schedules.</p><p>ISO/TR 15801 and ISO 15489 (all parts) established the standards and best practices associated with implementing trustworthy records/document management environments. However, a standard is necessary to define the methodology used to evaluate these types of records/document management environments regardless of what technologies are currently employed by the organization. ISO 18829:2017 establishes the assessment methodology to be followed to identify the level of organizational compliance with these standards as related to trustworthiness and reliability of information stored in these environments.</p><p>ISO 18829:2017 is applicable to existing or planned ECM systems. Establishing the existence of a trustworthy system is an important step in documenting the reliability of ESI maintained within that system or environment. ISO 18829:2017 is designed for use by organizations evaluating the trustworthiness of existing record/document management environments. ISO 18829:2017 identifies all of the mandatory activities and areas that need to be examined by a resource, or resources, with a thorough technical and operational knowledge of the specific technologies and methodologies being examined, along with understanding record management processes and activities.</p>


name: iso-ts-13141-2010-cor-1-2013
rev: 00
time: 2013-03-19
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.051906+00:00
source: iso
source_id: ISO/TS 13141:2010/Cor 1:2013
source_url: https://www.iso.org/standard/ISO%2FTS%2013141.html
doc_status: 9599
title:
  ISO/TS 13141:2010/Cor 1:2013: Electronic fee collection — Localisation augmentation communication for autonomous systems — Technical Corrigendum 1

abstract:
  ISO/IEC standard: Electronic fee collection — Localisation augmentation communication for autonomous systems — Technical Corrigendum 1. Committee: ISO/TC 204.


name: iso-ts-17575-1-2010-cor-1-2013
rev: 00
time: 2013-03-20
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.055302+00:00
source: iso
source_id: ISO/TS 17575-1:2010/Cor 1:2013
source_url: https://www.iso.org/standard/ISO%2FTS%2017575-1.html
doc_status: 9599
title:
  ISO/TS 17575-1:2010/Cor 1:2013: Electronic fee collection — Application interface definition for autonomous systems — Part 1: Charging — Technical Corrigendum 1

abstract:
  ISO/IEC standard: Electronic fee collection — Application interface definition for autonomous systems — Part 1: Charging — Technical Corrigendum 1. Committee: ISO/TC 204.


name: iso-ts-17575-3-2011-cor-1-2013
rev: 00
time: 2013-03-20
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.058970+00:00
source: iso
source_id: ISO/TS 17575-3:2011/Cor 1:2013
source_url: https://www.iso.org/standard/ISO%2FTS%2017575-3.html
doc_status: 9599
title:
  ISO/TS 17575-3:2011/Cor 1:2013: Electronic fee collection — Application interface definition for autonomous systems — Part 3: Context data — Technical Corrigendum 1

abstract:
  ISO/IEC standard: Electronic fee collection — Application interface definition for autonomous systems — Part 3: Context data — Technical Corrigendum 1. Committee: ISO/TC 204.


name: iso-17575-1-2016
rev: 00
time: 2016-01-18
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.062482+00:00
source: iso
source_id: ISO 17575-1:2016
source_url: https://www.iso.org/standard/ISO%2017575-1.html
doc_status: 9093
title:
  ISO 17575-1:2016: Electronic fee collection — Application interface definition for autonomous systems — Part 1: Charging

abstract:
  <p>ISO 17575-1:2016 defines the format and semantics of the data exchange between a Front End (OBE plus optional proxy) and corresponding Back Ends in autonomous toll schemes. It defines the data elements that are used to generate charge reports containing information about the road usage of a vehicle for certain time intervals, sent from the Front End to the Back End. It also defines the data that can be used to re-configure the ongoing process of gathering charge relevant information in the Front End. The scope is shown in Figure 1.</p><p>The constitution of the charge report is dependent on configuration data that are assumed to be present in the Front End. The assembly of charge reports can be configured for each individual toll scheme according to local needs. Charge reports generated in accordance with this part of ISO 17575 are consistent with the requirements derived from the architectural concept defined in ISO 17573:2010.</p><p>The definitions in ISO 17575-1:2016 comprise</p><p>-      reporting data, i.e. data for transferring road usage data from Front End to Back End, including a response from the Back End towards the Front End,</p><p>-      data for supporting security mechanisms,</p><p>-      contract data, i.e. data for identifying contractually essential entities,</p><p>-      road usage data, i.e. data for reporting the amount of road usage,</p><p>-      account data for managing a payment account,</p><p>-      versioning data, and</p><p>-      compliance checking data, i.e. data imported from ISO 12813:2015, which are required in compliance checking communication.</p><p>Annex A contains the data type specifications using ASN.1 notation.</p><p>The protocol implementation conformity statements (PICS) proforma are provided in Annex B.</p><p>Annex C provides a graphical presentation of the structure of the data elements described in Clause 7.</p><p>Annex D provides information on how this part of ISO 17575 can be used in EETS environment and how the re


name: iso-17575-2-2016
rev: 00
time: 2016-01-18
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.065975+00:00
source: iso
source_id: ISO 17575-2:2016
source_url: https://www.iso.org/standard/ISO%2017575-2.html
doc_status: 9093
title:
  ISO 17575-2:2016: Electronic fee collection — Application interface definition for autonomous systems — Part 2: Communication and connection to the lower layers

abstract:
  <p>ISO 17575-2:2016 defines how to convey all or parts of the data element structure defined in other parts of ISO 17575 over any communication stack and media suitable for this application. It is applicable only to mobile communication links (although wired links, i.e. back office connections, can use the same methodology).</p><p>To establish a link to a sequence of service calls initializing the communication channel, addressing the reception of the message and forwarding the payload are required. The definition provided in this part of ISO 17575 includes the required communication medium independent services, represented by an abstract application programming interface (API).</p><p>The communication interface is implemented as an API in the programming environment of choice for the Front End (FE) system. The specification of the Back End (BE) API is outside the scope of this part of ISO 17575.</p><p>The definition of this API in concrete terms is outside of the scope of this part of ISO 17575. This part of ISO 17575 specifies an abstract API that defines the semantics of the concrete API as illustrated in Figure 3 and its protocol implementation conformance statement (PICS) proforma (see Annex B). An example of a concrete API is presented in Annex C. Where no distinction is made between the abstract and concrete communications APIs, the term 'communications API' or just 'API' can be used.</p><p/><p>ISO 17575-2:2016 also provides a detailed specification for the structure of associated API statements, an example on how to implement it and its role in a complex toll cluster such as the EETS (see Annex A to Annex E).</p><p>Media selection policies, certificate handling and encryption mechanisms are outside of the scope of this part of ISO 17575.</p>


name: iso-17575-3-2016
rev: 00
time: 2016-01-18
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.069304+00:00
source: iso
source_id: ISO 17575-3:2016
source_url: https://www.iso.org/standard/ISO%2017575-3.html
doc_status: 9093
title:
  ISO 17575-3:2016: Electronic fee collection — Application interface definition for autonomous systems — Part 3: Context data

abstract:
  <p>ISO 17575-3:2016 defines the content, semantics and format of the data exchange between a Front End (OBE plus optional proxy) and the corresponding Back End in autonomous toll systems. It defines the data elements used to specify and describe the toll context details. Context data are transmitted from the Back End to the Front End to configure it for the charging processes of the associated toll context.</p><p>In ISO 17575, context data is the description of the properties of a single instance of an electronic fee collection (EFC) context. This single instance of an EFC context operates according to one of the basic tolling principles such as</p><p>-      road section charging,</p><p>-      area charging (according to travelled distance or duration of time), and</p><p>-      cordon charging.</p><p>EFC context data comprise a set of rules for charging, including the description of the charged network, the charging principles, the liable vehicles and a definition of the required contents of the charge report. This set of rules is defined individually for each EFC context according to local needs.</p><p>The following data and associated procedures are defined in this part of ISO 17575:</p><p>-      data providing toll context overview information;</p><p>-      data providing tariff information (including definitions of required tariff determinants such as vehicle parameters, time classe, etc.);</p><p>-      data providing context layout information;</p><p>-      data providing reporting rules information.</p><p>ISO 17575-3:2016 also provides the required definitions and data specifications to be applied when one single toll context is spilt inot more than one toll context partitions. This is applicable to cases where one EFC scheme and the rules applied cannot be described with a single set of context data.</p><p>Annex A provides the data type specification using ASN.1 notation.</p><p>The protocol implementation conformity statements (PICS) proforma are provided in 


name: iso-dis-17575-4
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.072593+00:00
source: iso
source_id: ISO/DIS 17575-4
source_url: https://www.iso.org/standard/ISO%2FDIS%2017575-4.html
doc_status: 4098
title:
  ISO/DIS 17575-4: Electronic fee collection — Application interface definition for autonomous systems — Part 4: Roaming

abstract:
  ISO/IEC standard: Electronic fee collection — Application interface definition for autonomous systems — Part 4: Roaming. Committee: ISO/TC 204.


name: iso-12813-2015
rev: 00
title: ISO 12813:2015: Electronic fee collection — Compliance check communication for autonomous systems
time: 2015-11-19
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.075584+00:00
source: iso
source_id: ISO 12813:2015
source_url: https://www.iso.org/standard/ISO%2012813.html
doc_status: 9599
abstract:
  <p>ISO 12813:2015 defines requirements for short-range communication for the purposes of compliance checking in autonomous electronic fee-collecting systems. Compliance checking communication (CCC) takes place between a road vehicle's on-board equipment (OBE) and an outside interrogator (road-side mounted equipment, mobile device or hand-held unit), and serves to establish whether the data that are delivered by the OBE correctly reflect the road usage of the corresponding vehicle according to the rules of the pertinent toll regime.</p><p>The operator of the compliance checking interrogator is assumed to be part of the toll charging role as defined in ISO 17573. The CCC permits identification of the OBE, vehicle and contract, and verification of whether the driver has fulfilled his obligations and the checking status and performance of the OBE. The CCC reads, but does not write, OBE data.</p><p>ISO 12813:2015 is applicable to OBE in an autonomous mode of operation; it is not applicable to compliance checking in dedicated short-range communication (DSRC)-based charging systems.</p><p>It defines data syntax and semantics, but does not define a communication sequence. All the attributes defined herein are required in any OBE claimed to be compliant with this International Standard, even if some values are set to 'not defined' in cases where certain functionality is not present in an OBE. The interrogator is free to choose which attributes are read, as well as the sequence in which they are read. In order to achieve compatibility with existing systems, the communication makes use of the attributes defined in ISO 14906 wherever useful.</p><p>The CCC is suitable for a range of short-range communication media. Specific definitions are given for the CEN-DSRC as specified in EN 15509, as well as for the use of ISO CALM IR, the Italian DSRC as specified in ETSI ES 200 674-1 and ARIB DSRC as alternatives to the CEN-DSRC. The attributes and functions defined are for compliance c


name: iso-13141-2015
rev: 00
time: 2015-11-18
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.079068+00:00
source: iso
source_id: ISO 13141:2015
source_url: https://www.iso.org/standard/ISO%2013141.html
doc_status: 9599
title:
  ISO 13141:2015: Electronic fee collection — Localisation augmentation communication for autonomous systems

abstract:
  <p>ISO 13141:2015 establishes requirements for short-range communication for the purposes of augmenting the localization in autonomous electronic fee collection (EFC) systems. Localization augmentation serves to inform on-board equipment (OBE) about geographical location and the identification of a charge object. This International Standard specifies the provision of location and heading information and security means to protect from the manipulation of the OBE with false roadside equipment (RSE).</p><p>The localization augmentation communication takes place between an OBE in a vehicle and fixed roadside equipment. This International Standard is applicable to OBE in an autonomous mode of operation.</p><p>ISO 13141:2015 defines attributes and functions for the purpose of localization augmentation, by making use of the dedicated short-range communications (DSRC) communication services provided by DSRC Layer 7, and makes these LAC attributes and functions available to the LAC applications at the RSE and the OBE. Attributes and functions are defined on the level of Application Data Units (ADUs, see Figure 1).</p>


name: iso-tr-15801-2017
rev: 00
time: 2017-05-17
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.083284+00:00
source: iso
source_id: ISO/TR 15801:2017
source_url: https://www.iso.org/standard/ISO%2FTR%2015801.html
doc_status: 9092
title:
  ISO/TR 15801:2017: Document management — Electronically stored information — Recommendations for trustworthiness and reliability

abstract:
  <p>ISO/TR 15801:2017 describes the implementation and operation of information management systems that store and make available for use electronically stored information (ESI) in a trustworthy and reliable manner. Such ESI can be of any type, including 'page based' information, information in databases and audio/video information.</p><p>ISO/TR 15801:2017 is for use by any organization that uses systems to store trustworthy ESI over time. Such systems incorporate policies, procedures, technology and audit requirements that ensure that trustworthiness of the ESI is maintained.</p><p>ISO/TR 15801:2017 does not cover processes used to evaluate whether ESI can be considered to be trustworthy prior to it being stored or imported into the system. However, it can be used to demonstrate that, once the electronic information is stored, output from the system will be a true and accurate reproduction of the ESI created and/or imported.</p>


name: iso-pwi-20531
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.086883+00:00
source: iso
source_id: ISO/PWI 20531
source_url: https://www.iso.org/standard/ISO%2FPWI%2020531.html
doc_status: 98
title:
  ISO/PWI 20531: Road vehicles — Test method to evaluate the performance of autonomous braking systems

abstract:
  ISO/IEC standard: Road vehicles — Test method to evaluate the performance of autonomous braking systems. Committee: ISO/TC 22/SC 33.


name: iso-iec-20546-2019
rev: 00
title: ISO/IEC 20546:2019: Information technology — Big data — Overview and vocabulary
time: 2019-02-28
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.090597+00:00
source: iso
source_id: ISO/IEC 20546:2019
source_url: https://www.iso.org/standard/ISO%2FIEC%2020546.html
doc_status: 9060
abstract:
  <p>This document provides a set of terms and definitions needed to promote improved communication and understanding of this area. It provides a terminological foundation for big data-related standards.</p><p>This document provides a conceptual overview of the field of big data, its relationship to other technical areas and standards efforts, and the concepts ascribed to big data that are not new to big data.</p>


name: iso-pwi-20554
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.094505+00:00
source: iso
source_id: ISO/PWI 20554
source_url: https://www.iso.org/standard/ISO%2FPWI%2020554.html
doc_status: 98
title:
  ISO/PWI 20554: Road vehicles — Test method to evaluate the performance of autonomous braking systems

abstract:
  ISO/IEC standard: Road vehicles — Test method to evaluate the performance of autonomous braking systems. Committee: ISO/TC 22.


name: iso-pwi-20800
rev: 00
title: ISO/PWI 20800: Underwater acoustics — Calibration of autonomous acoustic receiver/recorder systems
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.098593+00:00
source: iso
source_id: ISO/PWI 20800
source_url: https://www.iso.org/standard/ISO%2FPWI%2020800.html
doc_status: 98
abstract:
  ISO/IEC standard: Underwater acoustics — Calibration of autonomous acoustic receiver/recorder systems. Committee: ISO/TC 43/SC 3.


name: iso-37168-2022
rev: 00
time: 2022-06-14
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.102759+00:00
source: iso
source_id: ISO 37168:2022
source_url: https://www.iso.org/standard/ISO%2037168.html
doc_status: 6060
title:
  ISO 37168:2022: Smart community infrastructures — Guidance on smart transportation by Electric, Connected and Autonomous Vehicles (eCAVs) and its application to on-demand responsive passenger services with shared vehicles

abstract:
  <p>This document provides guidance on the staged implementation of Electric, Connected and Autonomous Vehicle (eCAV) passenger and delivery services, with a special focus on on-demand responsive passenger services with shared vehicles. This document aims to accelerate innovation and deliver smart transportation by eCAV, in and between cities.</p><p>Note 1 to entry:       This document does not designate the technical details of eCAVs, including pods, which are Low-Speed Autonomous Transport System (L-SAT) vehicles. These technical details are provided by ISO 22737.</p><p>Note 2 to entry:       This document targets on-demand responsive passenger services with shared vehicles. ISO 37181 also mentions the advantages of eCAV applications to public transportation.</p>


name: iso-37181-2022
rev: 00
time: 2022-06-14
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.106892+00:00
source: iso
source_id: ISO 37181:2022
source_url: https://www.iso.org/standard/ISO%2037181.html
doc_status: 6060
title:
  ISO 37181:2022: Smart community infrastructures — Smart transportation by autonomous vehicles on public roads

abstract:
  <p>This document describes the concept and goals of smart transportation by autonomous vehicles on public roads. It provides guidelines for the successful introduction and organisation of autonomous vehicles, with the aim of enhancing the safety of public road transportation and addressing the challenges to cities such as an aging population and diverse travel demands.</p><p>This document focuses on the deployment of autonomous vehicles as an operational system for actual use on public roads. This document is intended for those in academia, autonomous vehicle developers, policy makers, research institutions, road infrastructure operators, public road administrators, testing inspection and certification bodies, and vehicle manufacturers.</p><p>NOTE 1   This document targets autonomous vehicle services except on-demand responsive services with shared vehicles. For on-demand responsive passenger services with shared vehicles, see ISO 37168.</p><p>NOTE 2   A bus vehicle is shared by different passenger groups and can be chartered. A taxi vehicle is hired and can, if local regulations permit, be shared by different passenger groups.</p>


name: iso-12813-2015-amd-1-2017
rev: 00
time: 2017-06-01
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.110574+00:00
source: iso
source_id: ISO 12813:2015/Amd 1:2017
source_url: https://www.iso.org/standard/ISO%2012813.html
doc_status: 9599
title:
  ISO 12813:2015/Amd 1:2017: Electronic fee collection — Compliance check communication for autonomous systems — Amendment 1

abstract:
  ISO/IEC standard: Electronic fee collection — Compliance check communication for autonomous systems — Amendment 1. Committee: ISO/TC 204.


name: iso-13141-2015-amd-1-2017
rev: 00
time: 2017-06-06
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.114018+00:00
source: iso
source_id: ISO 13141:2015/Amd 1:2017
source_url: https://www.iso.org/standard/ISO%2013141.html
doc_status: 9599
title:
  ISO 13141:2015/Amd 1:2017: Electronic fee collection — Localisation augmentation communication for autonomous systems — Amendment 1

abstract:
  ISO/IEC standard: Electronic fee collection — Localisation augmentation communication for autonomous systems — Amendment 1. Committee: ISO/TC 204.


name: iso-iec-dis-30754
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.117100+00:00
source: iso
source_id: ISO/IEC DIS 30754
source_url: https://www.iso.org/standard/ISO%2FIEC%20DIS%2030754.html
doc_status: 4098
title:
  ISO/IEC DIS 30754: Information technology — Software trustworthiness — Governance and management — Specification

abstract:
  ISO/IEC standard: Information technology — Software trustworthiness — Governance and management — Specification. Committee: ISO/IEC JTC 1.


name: iso-iec-tr-20547-1-2020
rev: 00
time: 2020-08-20
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.119991+00:00
source: iso
source_id: ISO/IEC TR 20547-1:2020
source_url: https://www.iso.org/standard/ISO%2FIEC%20TR%2020547-1.html
doc_status: 6060
title:
  ISO/IEC TR 20547-1:2020: Information technology — Big data reference architecture — Part 1: Framework and application process

abstract:
  <p>This document describes the framework of the big data reference architecture and the process for how a user of the document can apply it to their particular problem domain.</p>


name: iso-iec-tr-20547-2-2018
rev: 00
time: 2018-01-10
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.123029+00:00
source: iso
source_id: ISO/IEC TR 20547-2:2018
source_url: https://www.iso.org/standard/ISO%2FIEC%20TR%2020547-2.html
doc_status: 6060
title:
  ISO/IEC TR 20547-2:2018: Information technology — Big data reference architecture — Part 2: Use cases and derived requirements

abstract:
  <p>ISO/IEC TR 20547-2:2018 provides examples of big data use cases with application domains and technical considerations derived from the contributed use cases.</p>


name: iso-iec-20547-3-2020
rev: 00
time: 2020-03-04
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.126303+00:00
source: iso
source_id: ISO/IEC 20547-3:2020
source_url: https://www.iso.org/standard/ISO%2FIEC%2020547-3.html
doc_status: 9060
title:
  ISO/IEC 20547-3:2020: Information technology — Big data reference architecture — Part 3: Reference architecture

abstract:
  <p>This document specifies the big data reference architecture (BDRA). The reference architecture includes concepts and architectural views.</p><p>The reference architecture specified in this document defines two architectural viewpoints:</p><p>—     a user view defining roles/sub-roles, their relationships, and types of activities within a big data ecosystem;</p><p>—     a functional view defining the architectural layers and the classes of functional components within those layers that implement the activities of the roles/sub-roles within the user view.</p><p>The BDRA is intended to:</p><p>—     provide a common language for the various stakeholders;</p><p>—     encourage adherence to common standards, specifications, and patterns;</p><p>—     provide consistency of implementation of technology to solve similar problem sets;</p><p>—     facilitate the understanding of the operational intricacies in big data;</p><p>—     illustrate and understand the various big data components, processes, and systems, in the context of an overall big data conceptual model;</p><p>—     provide a technical reference for government departments, agencies and other consumers to understand, discuss, categorize and compare big data solutions; and</p><p>—     facilitate the analysis of candidate standards for interoperability, portability, reusability, and extendibility.</p>


name: iso-pwi-22133-1
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.129533+00:00
source: iso
source_id: ISO/PWI 22133-1
source_url: https://www.iso.org/standard/ISO%2FPWI%2022133-1.html
doc_status: 98
title:
  ISO/PWI 22133-1: Road vehicles — Test object monitoring and control for active safety and automated/autonomous vehicle testing — Part 1: Communication protocols and interfaces

abstract:
  ISO/IEC standard: Road vehicles — Test object monitoring and control for active safety and automated/autonomous vehicle testing — Part 1: Communication protocols and interfaces. Committee: ISO/TC 22.


name: iso-pwi-22133-2
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.132859+00:00
source: iso
source_id: ISO/PWI 22133-2
source_url: https://www.iso.org/standard/ISO%2FPWI%2022133-2.html
doc_status: 98
title:
  ISO/PWI 22133-2: Road vehicles — Test object monitoring and control for active safety and automated/autonomous vehicle testing — Part 2: Test scenario description formats

abstract:
  ISO/IEC standard: Road vehicles — Test object monitoring and control for active safety and automated/autonomous vehicle testing — Part 2: Test scenario description formats. Committee: ISO/TC 22.


name: iso-iec-tr-20547-5-2018
rev: 00
time: 2018-02-09
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.135791+00:00
source: iso
source_id: ISO/IEC TR 20547-5:2018
source_url: https://www.iso.org/standard/ISO%2FIEC%20TR%2020547-5.html
doc_status: 6060
title:
  ISO/IEC TR 20547-5:2018: Information technology — Big data reference architecture — Part 5: Standards roadmap

abstract:
  <p>ISO/IEC TR 20547-5:2018 describes big data relevant standards, both in existence and under development, along with priorities for future big data standards development based on gap analysis.</p>


name: iso-22733-1-2021
rev: 00
time: 2021-07-23
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.139214+00:00
source: iso
source_id: ISO 22733-1:2021
source_url: https://www.iso.org/standard/ISO%2022733-1.html
doc_status: 9599
title:
  ISO 22733-1:2021: Road vehicles — Test method to evaluate the performance of autonomous emergency braking systems — Part 1: Car-to-car

abstract:
  <p>This document specifies a method to evaluate the behaviour of a vehicle equipped with an autonomous emergency braking system (AEBS), or dynamic brake support (DBS) during several accident scenarios. Those accidents occur during a straight-line driving when the vehicle under test (VUT) approaches another vehicle in the same lane. Both vehicles are aligned in longitudinal axis to each other.</p><p>The most important part of the vehicle behaviour during these accidents scenarios is the capacity to avoid or mitigate the collision.</p><p>Systems requiring driver intervention are not in the scope of this document.</p><p>NOTE      Depending on accidentology, only a part of the scenarios can be used for an evaluation of performance. AEB system evaluation based upon this document is limited to longitudinal accident scenarios.</p>


name: iso-12813-2015-cd-amd-2
rev: 00
time: 2015/CD Amd 2
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.142156+00:00
source: iso
source_id: ISO 12813:2015/CD Amd 2
source_url: https://www.iso.org/standard/ISO%2012813.html
doc_status: 3098
title:
  ISO 12813:2015/CD Amd 2: Electronic fee collection — Compliance check communication for autonomous systems — Amendment 2

abstract:
  ISO/IEC standard: Electronic fee collection — Compliance check communication for autonomous systems — Amendment 2. Committee: ISO/TC 204.


name: iso-12813-2019
rev: 00
title: ISO 12813:2019: Electronic fee collection — Compliance check communication for autonomous systems
time: 2019-11-15
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.145091+00:00
source: iso
source_id: ISO 12813:2019
source_url: https://www.iso.org/standard/ISO%2012813.html
doc_status: 9599
abstract:
  <p>This document defines requirements for short-range communication for the purposes of compliance checking in autonomous electronic fee collecting systems. Compliance checking communication (CCC) takes place between a road vehicle's on-board equipment (OBE) and an interrogator (roadside mounted equipment, mobile device or hand-held unit), and serves to establish whether the data that are delivered by the OBE correctly reflect the road usage of the corresponding vehicle according to the rules of the pertinent toll regime.</p><p>The operator of the compliance checking interrogator is assumed to be part of the toll charging role as defined in ISO 17573-1. The CCC permits identification of the OBE, vehicle and contract, and verification of whether the driver has fulfilled his obligations and the checking status and performance of the OBE. The CCC reads, but does not write, OBE data.</p><p>This document is applicable to OBE in an autonomous mode of operation; it is not applicable to compliance checking in dedicated short-range communication (DSRC)-based charging systems.</p><p>It defines data syntax and semantics, but not a communication sequence. All the attributes defined herein are required in any OBE claimed to be compliant with this document, even if some values are set to 'not defined' in cases where certain functionality is not present in an OBE. The interrogator is free to choose which attributes are read in the data retrieval phase, as well as the sequence in which they are read. In order to achieve compatibility with existing systems, the communication makes use of the attributes defined in ISO 14906 wherever useful.</p><p>The CCC is suitable for a range of short-range communication media. Specific definitions are given for the CEN-DSRC as specified in EN 15509, as well as for the use of ISO CALM IR, the Italian DSRC as specified in ETSI ES 200 674-1, ARIB DSRC and WAVE DSRC as alternatives to the CEN-DSRC. The attributes and functions defined are for complian


name: iso-17757-2019
rev: 00
time: 2019-07-30
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.148365+00:00
source: iso
source_id: ISO 17757:2019
source_url: https://www.iso.org/standard/ISO%2017757.html
doc_status: 9093
title:
  ISO 17757:2019: Earth-moving machinery and mining — Autonomous and semi-autonomous machine system safety

abstract:
  <p>This document provides safety requirements for autonomous machines and semi-autonomous machines (ASAM) used in earth-moving and mining operations, and their autonomous or semi-autonomous machine systems (ASAMS). It specifies safety criteria both for the machines and their associated systems and infrastructure, including hardware and software, and provides guidance on safe use in their defined functional environments during the machine and system life cycle. It also defines terms and definitions related to ASAMS.</p><p>It is applicable to autonomous and semi-autonomous versions of the earth-moving machinery (EMM) defined in ISO 6165 and of mobile mining machines used in either surface or underground applications. Its principles and many of its provisions can be applied to other types of ASAM used on the worksites.</p><p>Safety requirements for general mobile EMM and mining machines, as well as operators, trainers or passengers on the machine, are given by other International Standards (e.g. ISO 20474, ISO 19296). This document addresses additional hazards specific and relevant to ASAMS when used as intended.</p><p>It is not applicable to remote control capability (covered by ISO 15817) or function-specific automated features, except when those features are used as part of ASAMS.</p>


name: iso-iec-np-23615
rev: 00
title: ISO/IEC NP 23615: Neural network representation and model compression
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.154599+00:00
source: iso
source_id: ISO/IEC NP 23615
source_url: https://www.iso.org/standard/ISO%2FIEC%20NP%2023615.html
doc_status: 1098
abstract:
  ISO/IEC standard: Neural network representation and model compression. Committee: ISO/IEC JTC 1/SC 42.


name: iso-tr-9241-810-2020
rev: 00
time: 2020-09-02
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.157710+00:00
source: iso
source_id: ISO/TR 9241-810:2020
source_url: https://www.iso.org/standard/ISO%2FTR%209241-810.html
doc_status: 6060
title:
  ISO/TR 9241-810:2020: Ergonomics of human-system interaction — Part 810: Robotic, intelligent and autonomous systems

abstract:
  <p>This document addresses:</p><p>—     physically embodied RIA systems, such as robots and autonomous vehicles with which users will physically interact;</p><p>—     systems embedded within the physical environment with which users do not consciously interact, but which collect data and/or modify the environment within which people live or work such as smart building and, mood-detection;</p><p>—     intelligent software tools and agents with which users actively interact through some form of user interface;</p><p>—     intelligent software agents which act without active user input to modify or tailor the systems to the user's behaviour, task or some other purpose, including providing context specific content/information, tailoring adverts to a user based on information about them, user interfaces that adapt to the cognitive or physiological state, 'ambient intelligence';</p><p>—     the effect on users resulting from the combined interaction of several RIA systems such as conflicting behaviours between the RIA systems under the same circumstances;</p><p>—     the complex system-of-systems and sociotechnical impacts of the use of RIA systems, particularly on society and government.</p><p>This document is not an exploration of the philosophical, ethical or political issues surrounding robotics, artificial intelligence, machine learning, and intelligent machines or environments. For matters of ethics and political issues, see standards such as BS 8611 and IEC P7000. However, this document does identify where and why ethical issues need to be taken into account for a wide range of systems and contexts, and as such it provides information relevant to the broader debate regarding RIA systems.</p><p>This document has a broader focus than much of the early work on autonomy that relates to the automation of control tasks and mechanization of repetitive physical or cognitive tasks, and centres on levels of automation.</p><p>Although this document addresses a wide range of t


name: iso-23725-2024
rev: 00
title: ISO 23725:2024: Autonomous system and fleet management system interoperability
time: 2024-08-06
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.160886+00:00
source: iso
source_id: ISO 23725:2024
source_url: https://www.iso.org/standard/ISO%2023725.html
doc_status: 6060
abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document defines the interfaces required between the fleet management (FMS) and autonomous haulage (AHS) systems for dispatch of haul trucks and coordination of production information, including communication protocols, message structures, telemetry signals, map sharing and task assignments.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document applies to surface mining. It specifies requirements and recommendations to achieve the following:</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><span lang='EN-GB'>realtime computer system communication;</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><span lang='EN-GB'>message definition and semantic;</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><span lang='EN-GB'>mine map sharing;</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><span lang='EN-GB'>truck dispatching;</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLis


name: iso-ts-23860-2022
rev: 00
title: ISO/TS 23860:2022: Ships and marine technology — Vocabulary related to autonomous ship systems
time: 2022-05-25
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.163938+00:00
source: iso
source_id: ISO/TS 23860:2022
source_url: https://www.iso.org/standard/ISO%2FTS%2023860.html
doc_status: 9060
abstract:
  <p>This document defines terminology related to autonomous ship systems, which includes ships that can be classified as a “Maritime Autonomous Surface Ship” (MASS) according to the preliminary definitions from the International Maritime Organization (IMO). Autonomous ship system can also be applied to similar ship types for use on inland waterways.</p>


name: iso-iec-tr-24027-2021
rev: 00
time: 2021-11-05
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.167113+00:00
source: iso
source_id: ISO/IEC TR 24027:2021
source_url: https://www.iso.org/standard/ISO%2FIEC%20TR%2024027.html
doc_status: 6060
title:
  ISO/IEC TR 24027:2021: Information technology — Artificial intelligence (AI) — Bias in AI systems and AI aided decision making

abstract:
  <p>This document addresses bias in relation to AI systems, especially with regards to AI-aided decision-making. Measurement techniques and methods for assessing bias are described, with the aim to address and treat bias-related vulnerabilities. All AI system lifecycle phases are in scope, including but not limited to data collection, training, continual learning, design, testing, evaluation and use.</p>


name: iso-tr-24291-2021
rev: 00
time: 2021-03-26
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.169984+00:00
source: iso
source_id: ISO/TR 24291:2021
source_url: https://www.iso.org/standard/ISO%2FTR%2024291.html
doc_status: 6060
title:
  ISO/TR 24291:2021: Health informatics — Applications of machine learning technologies in imaging and other medical applications

abstract:
  <p>This document lists examples of and defines categories of use cases for machine learning in medicine for clinical practice. </p><p>The developments and applications of machine learning technologies for artificial intelligence consist of 1) data collection and curation, 2) pre-processing, 3) model training and validation, and 4) medicine depending on various kinds of specialty including radiology, pathology, emergency medicine, dermatology, ophthalmology, anaesthesia, surgery, etc., and clinical settings including repeated detection and/or diagnosis, real-time monitoring, and treatment prediction.</p><p>This document covers categories applications of medicine in (4). It also defines the clinical usages and necessities of the artificial intelligence in medicine. </p><p>(1) to (3) are not the scope of this document</p><p>This document also excludes</p><p>—     basic research and other scientific areas,</p><p>—     use cases related to artificial intelligence methods other than machine learning (for example, symbolic artificial intelligence, expert systems), and</p><p>—     non-human results such as veterinary medicine.</p>


name: iso-iec-24668-2022
rev: 00
time: 2022-11-17
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.172970+00:00
source: iso
source_id: ISO/IEC 24668:2022
source_url: https://www.iso.org/standard/ISO%2FIEC%2024668.html
doc_status: 6060
title:
  ISO/IEC 24668:2022: Information technology — Artificial intelligence — Process management framework for big data analytics

abstract:
  <p>This document provides a framework for developing processes to effectively leverage big data analytics across the organization irrespective of the industries or sectors.</p><p>This document specifies process management for big data analytics with its various process categories taken into account along with their interconnectivities. These process categories are organization stakeholder processes, competency development processes, data management processes, analytics development processes and technology integration processes. This document describes processes to acquire, describe, store and process data at an organization level which provides big data analytics services.</p>


name: iso-iec-15938-17-2022
rev: 00
time: 2022-08-26
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.176255+00:00
source: iso
source_id: ISO/IEC 15938-17:2022
source_url: https://www.iso.org/standard/ISO%2FIEC%2015938-17.html
doc_status: 9599
title:
  ISO/IEC 15938-17:2022: Information technology — Multimedia content description interface — Part 17: Compression of neural networks for multimedia content description and analysis

abstract:
  <p>This document specifies Neural Network Coding (NNC) as a compressed representation of the parameters/weights of a trained neural network and a decoding process for the compressed representation, complementing the description of the network topology in existing (exchange) formats for neural networks. It establishes a toolbox of compression methods, specifying (where applicable) the resulting elements of the compressed bitstream.</p><p>This document does not specify a complete protocol for the transmission of neural networks, but focuses on compression of network parameters. Only the syntax format, semantics, associated decoding process requirements, parameter sparsification, parameter transformation methods, parameter quantization, entropy coding method and integration/signalling within existing exchange formats are specified, while other matters such as pre-processing, system signalling and multiplexing, data loss recovery and post-processing are considered to be outside the scope of this document. Additionally, the internal processing steps performed within a decoder are also considered to be outside the scope of this document; only the externally observable output behaviour is required to conform to the specifications of this document.</p>


name: iso-iec-tr-24368-2022
rev: 00
time: 2022-08-19
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.179325+00:00
source: iso
source_id: ISO/IEC TR 24368:2022
source_url: https://www.iso.org/standard/ISO%2FIEC%20TR%2024368.html
doc_status: 6060
title:
  ISO/IEC TR 24368:2022: Information technology — Artificial intelligence — Overview of ethical and societal concerns

abstract:
  <p>This document provides a high-level overview of AI ethical and societal concerns.</p><p>In addition, this document:</p><p>—    provides information in relation to principles, processes and methods in this area;</p><p>—    is intended for technologists, regulators, interest groups, and society at large;</p><p>—    is not intended to advocate for any specific set of values (value systems).</p><p>This document includes an overview of International Standards that address issues arising from AI ethical and societal concerns.</p>


name: iso-iec-tr-24372-2021
rev: 00
time: 2021-12-07
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.182385+00:00
source: iso
source_id: ISO/IEC TR 24372:2021
source_url: https://www.iso.org/standard/ISO%2FIEC%20TR%2024372.html
doc_status: 6060
title:
  ISO/IEC TR 24372:2021: Information technology — Artificial intelligence (AI) — Overview of computational approaches for AI systems

abstract:
  <p>This document provides an overview of the state of the art of computational approaches for AI systems, by describing: a) main computational characteristics of AI systems; b) main algorithms and approaches used in AI systems, referencing use cases contained in ISO/IEC TR 24030.</p>


name: iso-ts-22133-2023
rev: 00
time: 2023-03-30
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.185153+00:00
source: iso
source_id: ISO/TS 22133:2023
source_url: https://www.iso.org/standard/ISO%2FTS%2022133.html
doc_status: 9599
title:
  ISO/TS 22133:2023: Road vehicles — Test object monitoring and control for active safety and automated/autonomous vehicle testing — Functional requirements, specifications and communication protocol

abstract:
  <p class='MsoNormal'><span lang='EN-GB'>This document specifies requirements, procedures and message formats for controlling and monitoring of test targets, used for testing of active safety functions and autonomous vehicles. </span></p><p class='MsoNormal'><span lang='EN-GB'>The document specifies functionality and messaging for monitoring and controlling of test objects by a control centre facilitating an interoperable test object environment. </span><span lang='EN-GB' style='mso-bidi-font-size: 9.0pt;'>This document defines a communication protocol which allows for the control centre to safely execute tests using test objects from multiple vendors.</span></p><p class='MsoNormal'><span lang='EN-GB'>This document does not specify the internal architecture of the test object nor control centre.</span></p><p class='MsoNormal'><span lang='EN-GB'>This document does not specify how testing of the vehicles shall be performed.</span></p>


name: iso-pwi-3510
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.238559+00:00
source: iso
source_id: ISO/PWI 3510
source_url: https://www.iso.org/standard/ISO%2FPWI%203510.html
doc_status: 98
title:
  ISO/PWI 3510: Specification of interoperability of teleoperated, autonomous, and manned mining equipment

abstract:
  ISO/IEC standard: Specification of interoperability of teleoperated, autonomous, and manned mining equipment. Committee: ISO/TC 82/SC 8.


name: iso-iec-ts-4213-2022
rev: 00
time: 2022-10-13
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.244110+00:00
source: iso
source_id: ISO/IEC TS 4213:2022
source_url: https://www.iso.org/standard/ISO%2FIEC%20TS%204213.html
doc_status: 9092
title:
  ISO/IEC TS 4213:2022: Information technology — Artificial intelligence — Assessment of machine learning classification performance

abstract:
  <p>This document specifies methodologies for measuring classification performance of machine learning models, systems and algorithms.</p>


name: iso-iec-24029-2-2023
rev: 00
time: 2023-08-01
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.247069+00:00
source: iso
source_id: ISO/IEC 24029-2:2023
source_url: https://www.iso.org/standard/ISO%2FIEC%2024029-2.html
doc_status: 6060
title:
  ISO/IEC 24029-2:2023: Artificial intelligence (AI) — Assessment of the robustness of neural networks — Part 2: Methodology for the use of formal methods

abstract:
  <p class='MsoBodyText' style='mso-layout-grid-align: none; text-autospace: none;'><span lang='EN-GB' style='mso-bidi-font-size: 12.0pt;'>This document provides methodology for the use of formal methods to assess robustness properties of neural networks. The document focuses on how to select, apply and manage formal methods to prove robustness properties.</span></p>


name: iso-iec-tr-27563-2023
rev: 00
title: ISO/IEC TR 27563:2023: Security and privacy in artificial intelligence use cases — Best practices
time: 2023-05-25
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.249952+00:00
source: iso
source_id: ISO/IEC TR 27563:2023
source_url: https://www.iso.org/standard/ISO%2FIEC%20TR%2027563.html
doc_status: 6060
abstract:
  <p class='MsoBodyText' style='mso-layout-grid-align: none; text-autospace: none;'><span lang='EN-GB' style='mso-bidi-font-size: 12.0pt;'>This document outlines best practices on assessing security and privacy in artificial intelligence use cases, covering in particular those published in <span class='stdpublisher'><span style='color: black; mso-color-alt: windowtext;'>ISO/IEC</span></span> <span class='stddocumentType'><span style='color: black; mso-color-alt: windowtext;'>TR</span></span> <span class='stddocNumber'><span style='color: black; mso-color-alt: windowtext;'>24030</span></span>.</span></p><p class='MsoBodyText' style='mso-layout-grid-align: none; text-autospace: none;'><span lang='EN-GB' style='mso-bidi-font-size: 12.0pt;'>The following aspects are addressed:</span></p><p class='ListContinue1' style='tab-stops: 19.85pt 39.7pt 59.55pt 79.4pt 99.25pt 119.05pt 138.9pt 158.75pt 178.6pt 7.0cm; mso-layout-grid-align: none; text-autospace: none;'><span lang='EN-GB' style='mso-bidi-font-size: 12.0pt;'>—<span style='mso-tab-count: 1;'>    </span>an overall assessment of security and privacy on the AI system of interest;</span></p><p class='ListContinue1' style='tab-stops: 19.85pt 39.7pt 59.55pt 79.4pt 99.25pt 119.05pt 138.9pt 158.75pt 178.6pt 7.0cm; mso-layout-grid-align: none; text-autospace: none;'><span lang='EN-GB' style='mso-bidi-font-size: 12.0pt;'>—<span style='mso-tab-count: 1;'>    </span>security and privacy concerns;</span></p><p class='ListContinue1' style='tab-stops: 19.85pt 39.7pt 59.55pt 79.4pt 99.25pt 119.05pt 138.9pt 158.75pt 178.6pt 7.0cm; mso-layout-grid-align: none; text-autospace: none;'><span lang='EN-GB' style='mso-bidi-font-size: 12.0pt;'>—<span style='mso-tab-count: 1;'>    </span>security and privacy risks;</span></p><p class='ListContinue1' style='tab-stops: 19.85pt 39.7pt 59.55pt 79.4pt 99.25pt 119.05pt 138.9pt 158.75pt 178.6pt 7.0cm; mso-layout-grid-align: none; text-autospace: none;'><span lang='EN-GB' style='mso-bidi-font-size: 12.0


name: iso-ts-42501-2022
rev: 00
time: 2022-10-06
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.252747+00:00
source: iso
source_id: ISO/TS 42501:2022
source_url: https://www.iso.org/standard/ISO%2FTS%2042501.html
doc_status: 9092
title:
  ISO/TS 42501:2022: Sharing economy — General trustworthiness and safety requirements for digital platforms

abstract:
  <p>This document specifies general trustworthiness and safety requirements applicable to operators of digital platforms within the sharing economy. While this document does not cover system requirements for digital platforms, the document is still beneficial for system development.</p>


name: iso-iec-25059-2023
rev: 00
time: 2023-06-28
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.255509+00:00
source: iso
source_id: ISO/IEC 25059:2023
source_url: https://www.iso.org/standard/ISO%2FIEC%2025059.html
doc_status: 9092
title:
  ISO/IEC 25059:2023: Software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Quality model for AI systems

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document outlines a quality model for AI systems and is an application-specific extension to the standards on SQuaRE. The characteristics and sub-characteristics detailed in the model provide consistent terminology for specifying, measuring and evaluating AI system quality. The characteristics and sub-characteristics detailed in the model also provide a set of quality characteristics against which stated quality requirements can be compared for completeness.</span></p>


name: iso-iec-wd-ts-23220-6
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.261242+00:00
source: iso
source_id: ISO/IEC WD TS 23220-6
source_url: https://www.iso.org/standard/ISO%2FIEC%20WD%20TS%2023220-6.html
doc_status: 2098
title:
  ISO/IEC WD TS 23220-6: Cards and security devices for personal identification — Building blocks for identity management via mobile devices — Part 6: Mechanism for use of certification on trustworthiness of secure area

abstract:
  ISO/IEC standard: Cards and security devices for personal identification — Building blocks for identity management via mobile devices — Part 6: Mechanism for use of certification on trustworthiness of secure area. Committee: ISO/IEC JTC 1/SC 17.


name: iso-tr-22100-5-2021
rev: 00
time: 2021-01-22
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.264035+00:00
source: iso
source_id: ISO/TR 22100-5:2021
source_url: https://www.iso.org/standard/ISO%2FTR%2022100-5.html
doc_status: 6060
title:
  ISO/TR 22100-5:2021: Safety of machinery — Relationship with ISO 12100 — Part 5: Implications of artificial intelligence machine learning

abstract:
  <p>This document addresses how artificial intelligence machine learning can impact the safety of machinery and machinery systems.</p><p>This document describes how hazards being associated with artificial intelligence (AI) applications machine learning in machinery or machinery systems, and designed to act within specific limits, can be considered in the risk assessment process.</p><p>This document is not applicable to machinery or machinery systems with AI applications machine learning designed to act beyond specified limits that can result in unpredictable effects.</p><p>This document does not address safety systems with AI, for example, safety-related sensors and other safety-related parts of control systems.</p>


name: iso-iec-5259-1-2024
rev: 00
time: 2024-07-02
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.266897+00:00
source: iso
source_id: ISO/IEC 5259-1:2024
source_url: https://www.iso.org/standard/ISO%2FIEC%205259-1.html
doc_status: 6060
title:
  ISO/IEC 5259-1:2024: Artificial intelligence — Data quality for analytics and machine learning (ML) — Part 1: Overview, terminology, and examples

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document provides the means for understanding and associating the individual documents of the ISO/IEC 5259 series and is the foundation for conceptual understanding of data quality for analytics and machine learning. It also discusses associated technologies and examples (e.g. use cases and usage scenarios).</span></p>


name: iso-iec-5259-3-2024
rev: 00
time: 2024-07-02
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.272033+00:00
source: iso
source_id: ISO/IEC 5259-3:2024
source_url: https://www.iso.org/standard/ISO%2FIEC%205259-3.html
doc_status: 6060
title:
  ISO/IEC 5259-3:2024: Artificial intelligence — Data quality for analytics and machine learning (ML) — Part 3: Data quality management requirements and guidelines

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document specifies requirements and provides guidance for establishing, implementing, maintaining and continually improving the quality of data used in the areas of analytics and machine learning.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document does not define a detailed process, methods or metrics. Rather it defines the requirements and guidance for a quality management process along with a reference process and methods that can be tailored to meet the requirements in this document.</span></p><p class='MsoBodyText'><span lang='EN-GB'>The requirements and recommendations set out in this document are generic and are intended to be applicable to all organizations, regardless of type, size or nature.</span></p>


name: iso-iec-5259-4-2024
rev: 00
time: 2024-07-15
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.274940+00:00
source: iso
source_id: ISO/IEC 5259-4:2024
source_url: https://www.iso.org/standard/ISO%2FIEC%205259-4.html
doc_status: 6060
title:
  ISO/IEC 5259-4:2024: Artificial intelligence — Data quality for analytics and machine learning (ML) — Part 4: Data quality process framework

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document establishes general common organizational approaches, regardless of the type, size or nature of the applying organization, to ensure data quality for training and evaluation in analytics and machine learning (ML). It includes guidance on the data quality process for:</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><span lang='EN-GB'>supervised ML with regard to the labelling of data used for training ML systems, including common organizational approaches for training data labelling;</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><span lang='EN-GB'>unsupervised ML;</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><span lang='EN-GB'>semi-supervised ML;</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><span lang='EN-GB'>reinforcement learning;</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-fo


name: iso-iec-5392-2024
rev: 00
time: 2024-03-15
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.278377+00:00
source: iso
source_id: ISO/IEC 5392:2024
source_url: https://www.iso.org/standard/ISO%2FIEC%205392.html
doc_status: 6060
title:
  ISO/IEC 5392:2024: Information technology — Artificial intelligence — Reference architecture of knowledge engineering

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document defines a reference architecture of knowledge engineering (KE) in artificial intelligence (AI). The reference architecture describes KE roles, activities, constructional layers, components and their relationships amongst themselves and other systems from systemic user and functional views. This document also provides a common KE vocabulary by defining KE terms.</span></p>


name: iso-iec-tr-5469-2024
rev: 00
title: ISO/IEC TR 5469:2024: Artificial intelligence — Functional safety and AI systems
time: 2024-01-08
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.281484+00:00
source: iso
source_id: ISO/IEC TR 5469:2024
source_url: https://www.iso.org/standard/ISO%2FIEC%20TR%205469.html
doc_status: 6060
abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document describes the properties, related risk factors, available methods and processes relating to:</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><span lang='EN-GB'>use of AI inside a safety related function to realize the functionality;</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><span lang='EN-GB'>use of non-AI safety related functions to ensure safety for an AI controlled equipment;</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><span lang='EN-GB'>use of AI systems to design and develop safety related functions.</span></p>


name: iso-np-ts-18759
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.284807+00:00
source: iso
source_id: ISO/NP TS 18759
source_url: https://www.iso.org/standard/ISO%2FNP%20TS%2018759.html
doc_status: 1098
title:
  ISO/NP TS 18759: Document management — Trustworthy storage system (TSS) functional and technical requirements

abstract:
  ISO/IEC standard: Document management — Trustworthy storage system (TSS) functional and technical requirements. Committee: ISO/TC 171/SC 2.


name: iso-22733-2-2023
rev: 00
time: 2023-11-02
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.287949+00:00
source: iso
source_id: ISO 22733-2:2023
source_url: https://www.iso.org/standard/ISO%2022733-2.html
doc_status: 6060
title:
  ISO 22733-2:2023: Road vehicles — Test method to evaluate the performance of autonomous emergency braking systems — Part 2: Car to pedestrian

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document specifies test methods to evaluate performance of the autonomous emergency braking system (AEBS) in car to pedestrian collision situations. Forward collision warning system (FCWS) is part of AEBS when it provides warning before braking intervention.</span></p><p class='MsoBodyText'><span lang='EN-GB'>Vehicle to pedestrian accidents occur when a vehicle under test (VUT) drives in straight line and either a pedestrian walks longitudinal on the same road or the pedestrian is approaching perpendicular the road.</span></p><p class='MsoBodyText'><span lang='EN-GB'>A system requiring a driver intervention is not in scope of this document.</span></p><p class='Note'><span lang='EN-GB'>NOTE<span style='mso-tab-count: 1;'>            </span>Depending on accidentology only a part of the scenarios can be used for an evaluation of performance.</span></p>


name: iso-iec-ts-5723-2022
rev: 00
title: ISO/IEC TS 5723:2022: Trustworthiness — Vocabulary
time: 2022-07-22
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.291655+00:00
source: iso
source_id: ISO/IEC TS 5723:2022
source_url: https://www.iso.org/standard/ISO%2FIEC%20TS%205723.html
doc_status: 9060
abstract:
  <p>This document provides a definition of trustworthiness for systems and their associated services, along with a selected set of their characteristics.</p>


name: iso-iec-5259-2-2024
rev: 00
time: 2024-11-05
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.295146+00:00
source: iso
source_id: ISO/IEC 5259-2:2024
source_url: https://www.iso.org/standard/ISO%2FIEC%205259-2.html
doc_status: 6060
title:
  ISO/IEC 5259-2:2024: Artificial intelligence — Data quality for analytics and machine learning (ML) — Part 2: Data quality measures

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document specifies a data quality model, data quality measures and guidance on reporting data quality in the context of analytics and machine learning (ML).</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document is applicable to all types of organizations who want to achieve their data quality objectives.</span></p>


name: iso-iec-ts-6254-2025
rev: 00
time: 2025-09-05
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.300862+00:00
source: iso
source_id: ISO/IEC TS 6254:2025
source_url: https://www.iso.org/standard/ISO%2FIEC%20TS%206254.html
doc_status: 6060
title:
  ISO/IEC TS 6254:2025: Information technology — Artificial intelligence — Objectives and approaches for explainability and interpretability of machine learning (ML) models and artificial intelligence (AI) systems

abstract:
  <p class='MsoBodyText' style='mso-layout-grid-align: none; text-autospace: none;'><span lang='EN-GB' style='mso-bidi-font-size: 12.0pt; mso-fareast-font-family: KoPub바탕체;'>This document describes approaches and methods that can be used to achieve explainability objectives of stakeholders with regard to machine learning (ML) models and artificial intelligence (AI) systems’ behaviours, outputs and results. Stakeholders include but are not limited to, academia, industry, policy makers and end users. It provides guidance concerning the applicability of the described approaches and methods to the identified objectives throughout the AI system’s life cycle, as defined in </span><span class='stdpublisher'><span lang='EN-GB' style='mso-bidi-font-size: 12.0pt; color: black; mso-color-alt: windowtext;'>ISO/IEC</span></span><span lang='EN-GB' style='mso-bidi-font-size: 12.0pt; mso-fareast-font-family: KoPub바탕체;'> <span class='stddocNumber'><span style='color: black; mso-color-alt: windowtext;'>22989</span></span>.</span></p>


name: iso-ts-18759-2022
rev: 00
time: 2022-08-26
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.303998+00:00
source: iso
source_id: ISO/TS 18759:2022
source_url: https://www.iso.org/standard/ISO%2FTS%2018759.html
doc_status: 9093
title:
  ISO/TS 18759:2022: Document management — Trustworthy storage system (TSS) — Functional and technical requirements

abstract:
  <p>This document specifies the functional, technology-neutral requirements for trustworthy storage systems (TSS) that ensure storing and managing electronically stored information (ESI) in a protected and secure fashion during the lifecycle of the information. The TSS as specified in this document is storage technology neutral and accordingly does not specify any specific storage media types or configurations.</p><p>This document is applicable to all information systems in which users and applications must manage the protection, preservation and security of stored ESI throughout its entire lifecycle to meet organizational and regulatory requirements to enforce:</p><p>—    immutability, authenticity and trustworthiness of the stored ESI;</p><p>—    protection of application managed ESI and other stored ESI against tampering, malicious acts and ransomware;</p><p>—    organizational ESI preservation and retention policies;</p><p>—    protection for unstructured and unmanaged data.</p>


name: iso-iec-ts-25058-2024
rev: 00
time: 2024-01-24
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.307516+00:00
source: iso
source_id: ISO/IEC TS 25058:2024
source_url: https://www.iso.org/standard/ISO%2FIEC%20TS%2025058.html
doc_status: 9092
title:
  ISO/IEC TS 25058:2024: Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Guidance for quality evaluation of artificial intelligence (AI) systems

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document provides guidance for evaluation of artificial intelligence (AI) systems using an AI system quality model.</span></p><p class='MsoBodyText'><span lang='EN-GB'>The document is applicable to all types of organizations engaged in the development and use of AI.</span></p>


name: iso-18497-1-2024
rev: 00
time: 2024-07-31
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.311160+00:00
source: iso
source_id: ISO 18497-1:2024
source_url: https://www.iso.org/standard/ISO%2018497-1.html
doc_status: 6060
title:
  ISO 18497-1:2024: Agricultural machinery and tractors — Safety of partially automated, semi-autonomous and autonomous machinery — Part 1: Machine design principles and vocabulary

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document specifies principles for the design of agricultural machinery and tractors that are used in agricultural applications and that have partially automated, semi-autonomous and autonomous functions. Additionally, it provides guidance on the type of information to be provided by the manufacturer on safe working practices (including information about residual risks).</span></p><p class='MsoBodyText'><span lang='EN-GB'>The purpose of this document is to assist in the provision of more specific safety requirements, means of verification and information for use to ensure an appropriate level of safety for agricultural machinery and tractors with partially automated, semi-autonomous and autonomous functions used in a specified way.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document deals with the significant hazards relevant to agricultural machinery and tractors with partially automated, semi-autonomous and autonomous functions when used as intended and under the conditions of misuse reasonably foreseeable by the manufacturer during normal operation and service.</span></p><p class='MsoBodyText'><span lang='EN-GB'>Applicability of the design principles and any additional detailed requirements for design, verification, validation or information for use are outside the scope of this document. When risk assessment concludes that hazards are not significant hazards, the principles of this document do not apply.</span></p><p class='Note'><span lang='EN-GB'>NOTE<span style='mso-tab-count: 1;'>          </span>Safety requirements for specific non-automated functions of agricultural machinery and tractors can be available in machine-specific type-C standards.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document is not applicable to:</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-fa


name: iso-18497-2-2024
rev: 00
time: 2024-07-31
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.314253+00:00
source: iso
source_id: ISO 18497-2:2024
source_url: https://www.iso.org/standard/ISO%2018497-2.html
doc_status: 6060
title:
  ISO 18497-2:2024: Agricultural machinery and tractors — Safety of partially automated, semi-autonomous and autonomous machinery — Part 2: Design principles for obstacle protection systems

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document specifies principles for the design of obstacle protective systems used in agricultural machinery and tractors that are used in agricultural applications and that have partially automated, semi-autonomous and autonomous functions. Additionally, it provides guidance on the type of information to be provided by the manufacturer on safe working practices (including information about residual risks).</span></p><p class='MsoBodyText'><span lang='EN-GB'>The purpose of this document is to assist in the provision of more specific safety requirements, means of verification and information for use to ensure an appropriate level of safety for agricultural machinery and tractors with partially automated, semi-autonomous and autonomous functions used in a specified way.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document deals with the significant hazards relevant to agricultural machinery and tractors with partially automated, semi-autonomous and autonomous functions when used as intended and under the conditions of misuse reasonably foreseeable by the manufacturer during normal operation and service.</span></p><p class='MsoBodyText'><span lang='EN-GB'>Applicability of the design principles and any additional detailed requirements for design, verification, validation or information for use are outside the scope of this document. When risk assessment concludes that hazards are not significant hazards, the principles of this document do not apply.</span></p><p class='Note'><span lang='EN-GB'>NOTE<span style='mso-tab-count: 1;'>          </span>Safety requirements for specific non-automated functions of agricultural machinery and tractors can be available in machine-specific type-C standards.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document is not applicable to:</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-fo


name: iso-18497-3-2024
rev: 00
time: 2024-07-31
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.317446+00:00
source: iso
source_id: ISO 18497-3:2024
source_url: https://www.iso.org/standard/ISO%2018497-3.html
doc_status: 6060
title:
  ISO 18497-3:2024: Agricultural machinery and tractors — Safety of partially automated, semi-autonomous and autonomous machinery — Part 3: Autonomous operating zones

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document specifies principles for the design of agricultural machinery and tractors utilizing systems (perception, supervisory or other) to prevent unintended excursions beyond the boundary of the autonomous operating zone which are used in agricultural applications and that have partially automated, semi-autonomous and autonomous functions. Additionally, it provides guidance on the type of information to be provided by the manufacturer on safe working practices (including information about residual risks).</span></p><p class='MsoBodyText'><span lang='EN-GB'>The autonomous operating zone itself is not within the scope of this document. The autonomous operating zone can include, for example, considerations for the autonomous operating zone location, physical or virtual boundaries, physical boundary types (natural or man-made) and the associated risks with the systems (perception, supervisory or other) to prevent unintended excursions beyond the boundary of the autonomous operating zone design.</span></p><p class='MsoBodyText'><span lang='EN-GB'>The purpose of this document is to assist in the provision of more specific safety requirements, means of verification and information for use to ensure an appropriate level of safety for agricultural machinery and tractors with partially automated, semi-autonomous and autonomous functions used in a specified way.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document deals with the significant hazards relevant to agricultural machinery and tractors with partially automated, semi-autonomous and autonomous functions when used as intended and under the conditions of misuse reasonably foreseeable by the manufacturer during normal operation and service.</span></p><p class='MsoBodyText'><span lang='EN-GB'>Applicability of the design principles and any additional detailed requirements for design, verification, validation or information for use are outside the scope of this do


name: iso-18497-4-2024
rev: 00
time: 2024-07-31
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.320526+00:00
source: iso
source_id: ISO 18497-4:2024
source_url: https://www.iso.org/standard/ISO%2018497-4.html
doc_status: 6060
title:
  ISO 18497-4:2024: Agricultural machinery and tractors — Safety of partially automated, semi-autonomous and autonomous machinery — Part 4: Verification methods and validation principles

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document specifies principles for verification methods and validation principles of agricultural machinery and tractors that are used in agricultural applications and that have partially automated, semi-autonomous and autonomous functions.</span></p><p class='MsoBodyText'><span lang='EN-GB'>The purpose of this document is to assist in the provision of more specific safety requirements, means of verification and information for use to ensure an appropriate level of safety for agricultural machinery and tractors with partially automated, semi-autonomous and autonomous functions used in a specified way.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document deals with the significant hazards relevant to agricultural machinery and tractors with partially automated, semi-autonomous and autonomous functions when used as intended and under the conditions of misuse reasonably foreseeable by the manufacturer during normal operation and service.</span></p><p class='MsoBodyText'><span lang='EN-GB'>Applicability of the design principles and any additional requirements, for design, verification, validation or information for use are outside the scope of this document. When risk assessment concludes that hazards are not significant hazards, the principles of this document do not apply.</span></p><p class='Note'><span lang='EN-GB'>NOTE<span style='mso-tab-count: 1;'>          </span>Safety requirements for specific non-automated functions of agricultural machinery and tractors can be available in machine-specific type-C standards.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document is not applicable to:</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><span l


name: iso-pwi-18497-5
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.323823+00:00
source: iso
source_id: ISO/PWI 18497-5
source_url: https://www.iso.org/standard/ISO%2FPWI%2018497-5.html
doc_status: 98
title:
  ISO/PWI 18497-5: Agricultural machinery and tractors — Safety of partially automated, semi-autonomous and autonomous machinery — Part 5: open

abstract:
  ISO/IEC standard: Agricultural machinery and tractors — Safety of partially automated, semi-autonomous and autonomous machinery — Part 5: open. Committee: ISO/TC 23/SC 19.


name: iso-iec-15938-18-2023
rev: 00
time: 2023-07-14
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.326817+00:00
source: iso
source_id: ISO/IEC 15938-18:2023
source_url: https://www.iso.org/standard/ISO%2FIEC%2015938-18.html
doc_status: 9599
title:
  ISO/IEC 15938-18:2023: Information technology — Multimedia content description interface — Part 18: Conformance and reference software for compression of neural networks

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document specifies conformance testing procedures for implementations of ISO/IEC 15938-17 and provides conformance bitstreams. It also provides the reference software for ISO/IEC 15938-17 which is an integral part of this document.</span></p>


name: iso-iec-pwi-7699
rev: 00
title: ISO/IEC PWI 7699: Guidance for addressing security threats and failures in artificial intelligence
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.329630+00:00
source: iso
source_id: ISO/IEC PWI 7699
source_url: https://www.iso.org/standard/ISO%2FIEC%20PWI%207699.html
doc_status: 98
abstract:
  ISO/IEC standard: Guidance for addressing security threats and failures in artificial intelligence. Committee: ISO/IEC JTC 1/SC 27.


name: iso-13141-2024
rev: 00
time: 2024-02-23
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.333161+00:00
source: iso
source_id: ISO 13141:2024
source_url: https://www.iso.org/standard/ISO%2013141.html
doc_status: 6060
title:
  ISO 13141:2024: Electronic fee collection — Localization augmentation communication for autonomous systems

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document establishes requirements for short-range communication for the purposes of augmenting the localization in autonomous electronic fee collection (EFC) systems. Localization augmentation serves to inform on-board equipment (OBE) about geographical location and the identification of a charge object. This document specifies the provision of location and heading information and security means to protect against the manipulation of the OBE with false RSE.</span></p><p class='MsoBodyText'><span lang='EN-GB'>The localization augmentation communication (LAC) takes place between an OBE in a vehicle and fixed RSE. This document is applicable to OBE in an autonomous mode of operation.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document specifies attributes and functions for the purpose of localization augmentation, by making use of the dedicated short-range communications (DSRC) communication services provided by DSRC Layer 7, and makes these LAC attributes and functions available to the LAC applications at the RSE and the OBE. Attributes and functions are specified on the level of application data units (ADUs; see Figure 1).</span></p><p class='MsoBodyText'><span lang='EN-GB'>As depicted in Figure 1, this document is applicable to:</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><span lang='EN-GB'>the application interface definition between OBE and RSE;</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><sp


name: iso-12813-2024
rev: 00
title: ISO 12813:2024: Electronic fee collection — Compliance check communication for autonomous systems
time: 2024-02-23
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.337051+00:00
source: iso
source_id: ISO 12813:2024
source_url: https://www.iso.org/standard/ISO%2012813.html
doc_status: 6060
abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document specifies requirements for short-range communication for the purposes of compliance checking in autonomous electronic fee collecting systems. Compliance checking communication (CCC) takes place between a road vehicle's on-board equipment (OBE) and an interrogator [fixed and mobile roadside equipment (RSE) or hand-held unit] and serves to establish whether the data that are delivered by the OBE correctly reflect the road usage of the corresponding vehicle according to the rules of the pertinent toll regime.</span></p><p class='MsoBodyText'><span lang='EN-GB'>The operator of the compliance checking interrogator is assumed to be part of the toll charging role as defined in ISO 17573-1. The CCC permits identification of the OBE, vehicle and contract, and verification of whether the driver has fulfilled their obligations and the checking status and performance of the OBE. The CCC reads, but does not write, OBE data.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document is applicable to OBE in an autonomous mode of operation. It is not applicable to compliance checking in dedicated short-range communication (DSRC)-based charging systems.</span></p><p class='MsoBodyText'><span lang='EN-GB'>It specifies data syntax and semantics, but not a communication sequence. All the attributes specified herein are required in any OBE claimed to be compliant with this document, even if some values are set to “not specified” in cases where a certain functionality is not present in an OBE. The interrogator is free to choose which attributes are read in the data retrieval phase, as well as the sequence in which they are read. In order to achieve compatibility with existing systems, the communication makes use of the attributes specified in ISO 17573-3 wherever useful.</span></p><p class='MsoBodyText'><span lang='EN-GB'>The CCC is suitable for a range of short-range communication media. Specific definitions are given for th


name: iso-iec-8183-2023
rev: 00
title: ISO/IEC 8183:2023: Information technology — Artificial intelligence — Data life cycle framework
time: 2023-07-26
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.340990+00:00
source: iso
source_id: ISO/IEC 8183:2023
source_url: https://www.iso.org/standard/ISO%2FIEC%208183.html
doc_status: 6060
abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document defines the stages and identifies associated actions for data processing throughout the artificial intelligence (AI) system life cycle, including acquisition, creation, development, deployment, maintenance and decommissioning. This document does not define specific services, platforms or tools. This document is applicable to all organizations, regardless of type, size or nature, that use data in the development and use of AI systems.</span></p>


name: iso-iec-ts-8200-2024
rev: 00
time: 2024-04-10
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.345013+00:00
source: iso
source_id: ISO/IEC TS 8200:2024
source_url: https://www.iso.org/standard/ISO%2FIEC%20TS%208200.html
doc_status: 6060
title:
  ISO/IEC TS 8200:2024: Information technology — Artificial intelligence — Controllability of automated artificial intelligence systems

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document specifies a basic framework with principles, characteristics and approaches for the realization and enhancement for automated artificial intelligence (AI) systems’ controllability.</span></p><p class='MsoBodyText'><span lang='EN-GB'>The following areas are covered:</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><span lang='EN-GB'>state observability and state transition;</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><span lang='EN-GB'>control transfer process and cost;</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><span lang='EN-GB'>reaction to uncertainty during control transfer;</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><span lang='EN-GB'>verification and validation approaches.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document is applicable to all types of organizations (e.g. commercial enterprises, government agencies, not-for-profit organizations) developing and using AI s


name: iso-np-15801
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.348219+00:00
source: iso
source_id: ISO/NP 15801
source_url: https://www.iso.org/standard/ISO%2FNP%2015801.html
doc_status: 1098
title:
  ISO/NP 15801: Document management — Electronically stored information — Recommendations for trustworthiness and reliability

abstract:
  This document specifies the implementation and operation of information management systems that stores and make available for use electronically stored information (ESI) in a trustworthy and reliable manner. Such ESI can be of any type, including “page based” information, information in databases and audio/video information.This document is for use by any organization that uses information management systems to store trustworthy ESI over time.  Such systems incorporate policies, procedures, technology and audit requirements that ensure that trustworthiness of the ESI is maintained.This document does not cover processes used to evaluate whether ESI can be considered to be trustworthy prior to it being stored or imported into the system. However, it can be used to demonstrate that, once the electronic information is stored, output from the system will be a true and accurate reproduction of the ESI created and/or imported.


name: iso-pas-8800-2024
rev: 00
title: ISO/PAS 8800:2024: Road vehicles — Safety and artificial intelligence
time: 2024-12-13
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.351370+00:00
source: iso
source_id: ISO/PAS 8800:2024
source_url: https://www.iso.org/standard/ISO%2FPAS%208800.html
doc_status: 9092
abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document applies to safety-related systems that include one or more electrical and/or electronic (E/E) systems that use AI technology and that is installed in series production road vehicles, excluding mopeds. It does not address unique E/E systems in special vehicles, such as E/E systems designed for drivers with disabilities.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document addresses the risk of undesired safety-related behaviour at the vehicle level due to output insufficiencies, systematic errors and random hardware errors of AI elements within the vehicle. This includes interactions with AI elements that are not part of the vehicle itself but that can have a direct or indirect impact on vehicle safety.</span></p><p class='Example'><span lang='EN-GB'>EXAMPLE 1<span style='mso-tab-count: 1;'>         </span>Examples of AI elements within the vehicle include the trained AI model and AI system.</span></p><p class='Example'><span lang='EN-GB'>EXAMPLE 2<span style='mso-tab-count: 1;'>         </span>Direct impact on safety can be due to object detection by elements external to the vehicle.</span></p><p class='Example'><span lang='EN-GB'>EXAMPLE 3<span style='mso-tab-count: 1;'>         </span>Indirect impact on safety can be due to field monitoring by elements external to the vehicle.</span></p><p class='MsoBodyText'><span lang='EN-GB'>The development of AI elements that are not part of the vehicle is not within the scope of this document. These elements can conform to domain-specific safety guidance. This document can be used as a reference where such domain-specific guidance does not exist.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document describes safety-related properties of AI systems that can be used to construct a convincing safety assurance claim for the absence of unreasonable risk.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document does not provide specific guide


name: iso-iec-pwi-9991
rev: 00
title: ISO/IEC PWI 9991: Information technology – Trustworthiness – Overview and concepts
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.354621+00:00
source: iso
source_id: ISO/IEC PWI 9991
source_url: https://www.iso.org/standard/ISO%2FIEC%20PWI%209991.html
doc_status: 98
abstract:
  ISO/IEC standard: Information technology – Trustworthiness – Overview and concepts. Committee: ISO/IEC JTC 1.


name: iso-iec-cd-11034.2
rev: 00
title: ISO/IEC CD 11034.2: Information technology — Cloud computing — Trustworthiness in cloud computing
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.358099+00:00
source: iso
source_id: ISO/IEC CD 11034.2
source_url: https://www.iso.org/standard/ISO%2FIEC%20CD%2011034.2.html
doc_status: 3060
abstract:
  This document provides an overview, frameworks, and concepts for Trustworthiness in cloud computing.


name: iso-dtr-12786
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.361318+00:00
source: iso
source_id: ISO/DTR 12786
source_url: https://www.iso.org/standard/ISO%2FDTR%2012786.html
doc_status: 5000
title:
  ISO/DTR 12786: Intelligent transport systems — Big data and artificial intelligence supporting intelligent transport systems — Use cases

abstract:
  ISO/IEC standard: Intelligent transport systems — Big data and artificial intelligence supporting intelligent transport systems — Use cases. Committee: ISO/TC 204.


name: iso-iec-ts-12791-2024
rev: 00
time: 2024-10-31
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.364744+00:00
source: iso
source_id: ISO/IEC TS 12791:2024
source_url: https://www.iso.org/standard/ISO%2FIEC%20TS%2012791.html
doc_status: 6060
title:
  ISO/IEC TS 12791:2024: Information technology — Artificial intelligence — Treatment of unwanted bias in classification and regression machine learning tasks

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document describes how to address unwanted bias in AI systems that use machine learning to conduct classification and regression tasks. This document provides mitigation techniques that can be applied throughout the AI system life cycle in order to treat unwanted bias. This document is applicable to all types and sizes of organization.</span></p>


name: iso-iec-12792-2025
rev: 00
time: 2025-11-11
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.368114+00:00
source: iso
source_id: ISO/IEC 12792:2025
source_url: https://www.iso.org/standard/ISO%2FIEC%2012792.html
doc_status: 6060
title:
  ISO/IEC 12792:2025: Information technology — Artificial intelligence (AI) — Transparency taxonomy of AI systems

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document specifies a taxonomy of information elements to assist AI stakeholders with identifying and addressing the needs for transparency of AI systems. The document describes the semantics of the information elements and their relevance to the various objectives of different stakeholders.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document is applicable to any kind of organization and application involving an AI system.</span></p>


name: iso-iec-ts-42119-2-2025
rev: 00
time: 2025-11-03
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.371545+00:00
source: iso
source_id: ISO/IEC TS 42119-2:2025
source_url: https://www.iso.org/standard/ISO%2FIEC%20TS%2042119-2.html
doc_status: 6060
title:
  ISO/IEC TS 42119-2:2025: Artificial intelligence — Testing of AI — Part 2: Overview of testing AI systems

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document provides requirements and guidance on the application of the ISO/IEC/IEEE 29119 series to the testing of AI systems. This document follows a risk-based approach and uses risks associated with AI systems, and their development and maintenance, to identify suitable test practices, approaches and techniques applicable to AI systems and their components. When the test practices, approaches and techniques are already specified in the ISO/IEC/IEEE 29119 series, this document provides additional detail and describes their application in the context of AI systems.</span></p>


name: iso-iec-tr-24030-2024
rev: 00
title: ISO/IEC TR 24030:2024: Information technology — Artificial intelligence (AI) — Use cases
time: 2024-04-08
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.375326+00:00
source: iso
source_id: ISO/IEC TR 24030:2024
source_url: https://www.iso.org/standard/ISO%2FIEC%20TR%2024030.html
doc_status: 9092
abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document provides a collection of representative use cases of AI applications in a variety of domains.</span></p>


name: iso-iec-5259-5-2025
rev: 00
time: 2025-02-12
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.378706+00:00
source: iso
source_id: ISO/IEC 5259-5:2025
source_url: https://www.iso.org/standard/ISO%2FIEC%205259-5.html
doc_status: 6060
title:
  ISO/IEC 5259-5:2025: Artificial intelligence — Data quality for analytics and machine learning (ML) — Part 5: Data quality governance framework

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document provides a data quality governance framework for analytics and machine learning (ML) to enable governing bodies of organizations to direct and oversee the implementation and operation of data quality measures, management, and related processes with adequate controls throughout the data life cycle (DLC) model according to ISO/IEC 5259-1.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document can be applied to any analytics and ML. This document does not define specific management requirements or process requirements according to ISO/IEC 5259-3 and ISO/IEC 5259-4 respectively.</span></p>


name: iso-22733-1-2022
rev: 00
time: 2022-09-13
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.382136+00:00
source: iso
source_id: ISO 22733-1:2022
source_url: https://www.iso.org/standard/ISO%2022733-1.html
doc_status: 6060
title:
  ISO 22733-1:2022: Road vehicles — Test method to evaluate the performance of autonomous emergency braking systems — Part 1: Car-to-car

abstract:
  <p>This document specifies a method to evaluate the behaviour of a vehicle equipped with an autonomous emergency braking system (AEBS), or dynamic brake support (DBS) during several accident scenarios. Those accidents occur during a straight-line driving when the vehicle under test (VUT) approaches another vehicle in the same lane. Both vehicles are aligned in longitudinal axis to each other.</p><p>The most important part of the vehicle behaviour during these accidents scenarios is the capacity to avoid or mitigate the collision.</p><p>Systems requiring driver intervention are not in the scope of this document.</p><p>NOTE      Depending on accidentology, only a part of the scenarios can be used for an evaluation of performance. AEB system evaluation based upon this document is limited to longitudinal accident scenarios.</p>


name: iso-np-4669-3
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.385252+00:00
source: iso
source_id: ISO/NP 4669-3
source_url: https://www.iso.org/standard/ISO%2FNP%204669-3.html
doc_status: 1098
title:
  ISO/NP 4669-3: Document management — Information classification, marking and handling — Part 3: Trustworthiness of information received from third parties

abstract:
  This document specifies requirements and procedures to be followed when assessing the trustworthiness of documents received from third parties.


name: iso-iec-23093-5-2025
rev: 00
time: 2025-03-06
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.388368+00:00
source: iso
source_id: ISO/IEC 23093-5:2025
source_url: https://www.iso.org/standard/ISO%2FIEC%2023093-5.html
doc_status: 6060
title:
  ISO/IEC 23093-5:2025: Information technology — Internet of media things — Part 5: IoMT autonomous collaboration

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document specifies data formats and APIs for the mission management and control between MThings and end-users/system managers. Specifically, the following interfaces, protocols and associated media-related information representations are within the scope of this document:</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><span lang='EN-GB'>structured data formats (XML) representing the mission assigned by the user to the network of IoMT, for the data formats;</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><span lang='EN-GB'>structured data formats (XML) representing user commands to one or several MThings, possibly in a modified form (e.g. a subset of 1);</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><span lang='EN-GB'>APIs to exchange the data for mission management and control.</span></p>


name: iso-iec-dts-42119-3.2
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.392022+00:00
source: iso
source_id: ISO/IEC DTS 42119-3.2
source_url: https://www.iso.org/standard/ISO%2FIEC%20DTS%2042119-3.2.html
doc_status: 5000
title:
  ISO/IEC DTS 42119-3.2: Artificial intelligence — Testing of AI — Part 3: Verification and validation analysis of AI systems

abstract:
  This document describes approaches and provides guidance on processes for the verification and validation analysis of AI systems (comprising AI system components and the interaction of non-AI components with the AI system components) including formal methods, simulation and evaluation.This document is applicable for AI systems verification and validation in the context of the AI system life cycle stages described in ISO/IEC 22989.This document is applicable to all types of organizations engaged in the development, deployment and use of AI systems.


name: iso-iec-pwi-17866
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.395404+00:00
source: iso
source_id: ISO/IEC PWI 17866
source_url: https://www.iso.org/standard/ISO%2FIEC%20PWI%2017866.html
doc_status: 98
title:
  ISO/IEC PWI 17866: Artificial intelligence — Best practice guidance for mitigating ethical and societal concerns

abstract:
  ISO/IEC standard: Artificial intelligence — Best practice guidance for mitigating ethical and societal concerns. Committee: ISO/IEC JTC 1/SC 42.


name: iso-iec-tr-17903-2024
rev: 00
time: 2024-05-06
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.399102+00:00
source: iso
source_id: ISO/IEC TR 17903:2024
source_url: https://www.iso.org/standard/ISO%2FIEC%20TR%2017903.html
doc_status: 6060
title:
  ISO/IEC TR 17903:2024: Information technology — Artificial intelligence — Overview of machine learning computing devices

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document surveys machine learning (ML) computing devices, including the following:</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><span lang='EN-GB'>ML computing device terminology and characteristics;</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><span lang='EN-GB'>existing approaches to the setting and use of characteristics for optimizing ML computing device performance.</span></p><p class='MsoBodyText'><span lang='EN-GB'>The information provided in this document is relevant for organizations of all types and sizes.</span></p>


name: iso-iec-awi-31310-1
rev: 00
title: ISO/IEC AWI 31310-1: Information Technology — Trustworthiness ontology — Part 1: Framework
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.402392+00:00
source: iso
source_id: ISO/IEC AWI 31310-1
source_url: https://www.iso.org/standard/ISO%2FIEC%20AWI%2031310-1.html
doc_status: 2000
abstract:
  Scope: This document describes the ontology framework and the general ontological notion of trustworthiness for information technology.


name: iso-18374-2025
rev: 00
time: 2025-04-30
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.405456+00:00
source: iso
source_id: ISO 18374:2025
source_url: https://www.iso.org/standard/ISO%2018374.html
doc_status: 6060
title:
  ISO 18374:2025: Dentistry — Artificial intelligence (AI) and augmented intelligence (AuI) based 2D radiograph analysis — Data generation, data annotation and data processing

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document defines the requirements for developing and documenting the goals, limitations, target end users and target patient population for artificial intelligence (AI) and augmented intelligence (AuI) enabled 2D radiograph analysis software for dentistry applications. It outlines the requirements for appropriate training data, validation data, test data and annotation for the software to ensure that it achieves its intended goals, and is restricted to the aspects. This document does not cover the specific implementation details, and focuses on static (i.e. non-dynamic) AI/AuI.</span></p>


name: iso-awi-18460
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.408699+00:00
source: iso
source_id: ISO/AWI 18460
source_url: https://www.iso.org/standard/ISO%2FAWI%2018460.html
doc_status: 2000
title:
  ISO/AWI 18460: Powered lawn and garden equipment — Internal-combustion engine-powered autonomous lawnmowers

abstract:
  This Type C Standard specifies safety requirements and their verification for autonomous combustion-engine-powered lawnmowers and equipped with:— metallic cutting means; and/or— non-metallic cutting means with one or more cutting elements pivotally mounted on a generally circular drive unit, where these cutting elements rely on centrifugal force to achieve cutting and have a kinetic energy for each single cutting element of 10 J or more.This document deals with the significant hazards, hazardous situations, and events relevant to lawnmowers with autonomous functions when used as intended and under the conditions of misuse foreseeable by the manufacturer during normal operation and service.This standard does not apply to:—	travel on public roads;—	grassland mowers;—	sickle bar mowers;—	scrub-clearing machines;—	automatic docking and refueling systems.This International Standard is neither applicable to machines which were manufactured with an auto-guidance system, nor to self-contained auto-guidance retrofit systems which were placed on the market before the date of this International Standard.


name: iso-iec-pwi-18966
rev: 00
title: ISO/IEC PWI 18966: Artificial intelligence — Oversight of AI systems
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.411711+00:00
source: iso
source_id: ISO/IEC PWI 18966
source_url: https://www.iso.org/standard/ISO%2FIEC%20PWI%2018966.html
doc_status: 98
abstract:
  ISO/IEC standard: Artificial intelligence — Oversight of AI systems. Committee: ISO/IEC JTC 1/SC 42.


name: iso-iec-15938-17-2024
rev: 00
time: 2024-01-10
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.414940+00:00
source: iso
source_id: ISO/IEC 15938-17:2024
source_url: https://www.iso.org/standard/ISO%2FIEC%2015938-17.html
doc_status: 6060
title:
  ISO/IEC 15938-17:2024: Information technology — Multimedia content description interface — Part 17: Compression of neural networks for multimedia content description and analysis

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document specifies Neural Network Coding (NNC) as a compressed representation of the parameters/weights of a trained neural network and a decoding process for the compressed representation, complementing the description of the network topology in existing (exchange) formats for neural networks. It establishes a toolbox of compression methods, specifying (where applicable) the resulting elements of the compressed bitstream. Most of these tools can be applied to the compression of entire neural networks, and some of them can also be applied to the compression of differential updates of neural networks with respect to a base network. Such differential updates are for example useful when models are redistributed after fine-tuning or transfer learning, or when providing versions of a neural network with different compression ratios.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document does not specify a complete protocol for the transmission of neural networks, but focuses on compression of network parameters. Only the syntax format, semantics, associated decoding process requirements, parameter sparsification, parameter transformation methods, parameter quantization, entropy coding method and integration/signalling within existing exchange formats are specified, while other matters such as pre-processing, system signalling and multiplexing, data loss recovery and post-processing are considered to be outside the scope of this document. Additionally, the internal processing steps performed within a decoder are also considered to be outside the scope of this document; only the externally observable output behaviour is required to conform to the specifications of this document.</span></p>


name: iso-iec-cd-tr-18988
rev: 00
title: ISO/IEC CD TR 18988: Artificial intelligence — Application of AI technologies in health informatics
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.418302+00:00
source: iso
source_id: ISO/IEC CD TR 18988
source_url: https://www.iso.org/standard/ISO%2FIEC%20CD%20TR%2018988.html
doc_status: 3099
abstract:
  ISO/IEC standard: Artificial intelligence — Application of AI technologies in health informatics. Committee: ISO/IEC JTC 1/SC 42.


name: iso-awi-tr-3510
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.421695+00:00
source: iso
source_id: ISO/AWI TR 3510
source_url: https://www.iso.org/standard/ISO%2FAWI%20TR%203510.html
doc_status: 2000
title:
  ISO/AWI TR 3510: Advanced automated mining systems – Communication interface for interoperability between a supervisor system and heterogenous autonomous machine controllers

abstract:
  ISO/IEC standard: Advanced automated mining systems – Communication interface for interoperability between a supervisor system and heterogenous autonomous machine controllers. Committee: ISO/TC 82/SC 8.


name: iso-cd-tr-22957
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.425273+00:00
source: iso
source_id: ISO/CD TR 22957
source_url: https://www.iso.org/standard/ISO%2FCD%20TR%2022957.html
doc_status: 3098
title:
  ISO/CD TR 22957: Document management — Trustworthy content/records management environments - Best practices

abstract:
  <p>This document gives guidelines for a set of procedures and activities to be considered and/or performed by organizations when planning, designing and implementing various enterprise content management (ECM) technologies. The aspects or project phases range from initial business analysis through to vendor/integrator selection and technology implementation. The implementation of processes to manage electronically stored information (ESI) requires significant participation from the affected business units, if the content is stored and managed when created/received and controlled through the information life cycle following organizational policies and/or records retention and control policies are applied. As these efforts require multiple people with different disciplines, including technical teams, records managers and organizational management, this document has been prepared taking those perspectives into account.</p><p>This document is applicable to both in-house and outsourced systems, including cloud solutions. It can also be useful when dealing with specialized business systems. The term 'enterprise content management (ECM)' (or 'document management') used throughout this document is intended as an all-encompassing term referring to capture technologies [scanning, indexing, optical character recognition (OCR), forms, digital creation, etc.], management technologies (document services, workflow and other work management tools), and storage [primarily non-alterable or write once read many (WORM) technologies]. This document provides information to users related to the technical reports, guidelines and standards that have been developed for technologies commonly available in ECM systems.</p><p>This document is not intended to be an all-inclusive paper on electronic document or content management and does not attempt to influence any single technology or provide legal guidance or legal opinions. While there are storage technologies other than optical/magnetic curr


name: iso-iec-tr-20226-2025
rev: 00
time: 2025-07-01
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.429123+00:00
source: iso
source_id: ISO/IEC TR 20226:2025
source_url: https://www.iso.org/standard/ISO%2FIEC%20TR%2020226.html
doc_status: 6060
title:
  ISO/IEC TR 20226:2025: Information technology — Artificial intelligence — Environmental sustainability aspects of AI systems

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document provides an overview of the environmental sustainability aspects (e.g. workload, resource and asset utilization, carbon impact, pollution, waste, transportation, location) of AI systems during their life cycle, and related potential metrics.</span></p><p class='Note'><span lang='EN-GB'>NOTE 1<span style='mso-tab-count: 1;'>        </span>This document does not identify opportunities on how AI, AI applications and AI systems can improve environmental, social or economic sustainability outcomes.</span></p><p class='Note'><span lang='EN-GB'>NOTE 2<span style='mso-tab-count: 1;'>        </span>This document can help other projects related to AI system environmental sustainability.</span></p>


name: iso-20682-2026
rev: 00
title: ISO 20682:2026: Autonomous underwater vehicles — Risk and reliability
time: 2026-02-13
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.432020+00:00
source: iso
source_id: ISO 20682:2026
source_url: https://www.iso.org/standard/ISO%2020682.html
doc_status: 6060
abstract:
  <p><span lang='EN-GB'>This document specifies the risks and reliability of an autonomous underwater vehicle (AUV) in its underwater realm. It covers sensors, communication devices, and any other pieces and parts directly influencing the “digital mission” of the vehicle. This document does not cover the manufacturing or operation of the following items:</span></p><ul style='list-style-type: disc;'><li><span lang='EN-GB'>autonomous underwater gliders (AUGs), as they use a narrowly modifiable set of operational commands;</span></li><li><span lang='EN-GB'>batteries for the use of AUVs;</span></li><li><span lang='EN-GB'>electrical motors for the use of AUVs.</span></li></ul>


name: iso-iec-pwi-20822
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.435121+00:00
source: iso
source_id: ISO/IEC PWI 20822
source_url: https://www.iso.org/standard/ISO%2FIEC%20PWI%2020822.html
doc_status: 98
title:
  ISO/IEC PWI 20822: Information technology — Domain knowledge trustworthiness evaluation for smart cities

abstract:
  ISO/IEC standard: Information technology — Domain knowledge trustworthiness evaluation for smart cities. Committee: ISO/IEC JTC 1.


name: iso-iec-tr-5259-6
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.438127+00:00
source: iso
source_id: ISO/IEC TR 5259-6
source_url: https://www.iso.org/standard/ISO%2FIEC%20TR%205259-6.html
doc_status: 6000
title:
  ISO/IEC TR 5259-6: Artificial intelligence — Data quality for analytics and machine learning (ML) — Part 6: Visualization framework for data quality

abstract:
  ISO/IEC standard: Artificial intelligence — Data quality for analytics and machine learning (ML) — Part 6: Visualization framework for data quality. Committee: ISO/IEC JTC 1/SC 42.


name: iso-iec-tr-21221-2025
rev: 00
title: ISO/IEC TR 21221:2025: Information technology — Artificial intelligence — Beneficial AI systems
time: 2025-09-05
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.441249+00:00
source: iso
source_id: ISO/IEC TR 21221:2025
source_url: https://www.iso.org/standard/ISO%2FIEC%20TR%2021221.html
doc_status: 6060
abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document describes the delivery of functional, economic, environmental, social, societal, cultural, intellectual and personal benefits by AI systems as perceived by their stakeholders. The document includes illustrative use cases of AI systems.</span></p>


name: iso-iec-ts-23220-6-2025
rev: 00
time: 2025-10-21
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.444293+00:00
source: iso
source_id: ISO/IEC TS 23220-6:2025
source_url: https://www.iso.org/standard/ISO%2FIEC%20TS%2023220-6.html
doc_status: 6060
title:
  ISO/IEC TS 23220-6:2025: Cards and security devices for personal identification — Building blocks for identity management via mobile devices — Part 6: Mechanism for use of certification on trustworthiness of secure area

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document specifies mechanism for use of certification on trustworthiness of secure area that is defined in ISO/IEC 23220-1.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document aims at enabling secure area providers to describe capabilities and confidence level of secure area for verification by eID issuers or mobile eID Attestation service providers, or both.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document specifies:</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><span lang='EN-GB'>list of elements describing capabilities and confidence level of a secure area;</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><span lang='EN-GB'>structure and management for use of a certificate, affixed or not to the secure area, containing that list of elements.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document refers to existing standards and applicable industry specifications which partly address the trustworthiness related issue (e.g. DLOA specified in GlobalPlatform specification GPC_SPE_095<sup>[</sup><a href='#Reference_ref_3'><!-- [if supportFields]><spanstyle='color:#0563C1'><span style='mso-element:field-begin'></span> REFReference_ref_3 \\r \\h <span style='mso-element:field-separator'></span></span><![endif]--><span style='color: #0563c1;'>1<!-- [if gte mso 9]><xml> <w:data>08D0C9EA79F9BACE118C8200AA004BA90B0200000008000000100000005200650066006500720065006E00630065005F0072006


name: iso-iec-cd-42102
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.447978+00:00
source: iso
source_id: ISO/IEC CD 42102
source_url: https://www.iso.org/standard/ISO%2FIEC%20CD%2042102.html
doc_status: 3060
title:
  ISO/IEC CD 42102: Information technology — Artificial intelligence — Framework for characterizing AI system methods and capabilities

abstract:
  <p>This document provides a framework of descriptors to support the consistent characterization of AI system methods and capabilities. The framework helps AI stakeholders describe AI systems and have a common understanding of them. This document applies to all types of organizations involved in any of the lifecycle stages of AI systems as well as to any AI stakeholder roles</p>


name: iso-iec-cd-tr-42103
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.501606+00:00
source: iso
source_id: ISO/IEC CD TR 42103
source_url: https://www.iso.org/standard/ISO%2FIEC%20CD%20TR%2042103.html
doc_status: 3020
title:
  ISO/IEC CD TR 42103: Information technology — Artificial intelligence — Overview of synthetic data in the context of AI systems

abstract:
  <p>This document provides an overview of synthetic data concepts, methods, uses and considerations in the context of AI systems.</p>


name: iso-iec-dis-24029-3
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.507926+00:00
source: iso
source_id: ISO/IEC DIS 24029-3
source_url: https://www.iso.org/standard/ISO%2FIEC%20DIS%2024029-3.html
doc_status: 4020
title:
  ISO/IEC DIS 24029-3: Artificial intelligence (AI) — Assessment of the robustness of neural networks — Part 3: Methodology for the use of statistical methods

abstract:
  This document provides methodology for the use of statistical methods to assess robustness properties of neural networks. The document focuses on how to select, apply and manage statistical methods to assess robustness properties.


name: iso-iec-dis-42105
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.511251+00:00
source: iso
source_id: ISO/IEC DIS 42105
source_url: https://www.iso.org/standard/ISO%2FIEC%20DIS%2042105.html
doc_status: 4060
title:
  ISO/IEC DIS 42105: Information technology — Artificial intelligence — Guidance for human oversight of AI systems

abstract:
  <p>This document provides guidance on human control and monitoring of AI systems, which is referred to as human oversight. This document extends ISO/IEC TS 8200. This document is applicable to all types of organizations. This document is applicable throughout the AI system life cycle.</p>


name: iso-iec-tr-42106
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.514507+00:00
source: iso
source_id: ISO/IEC TR 42106
source_url: https://www.iso.org/standard/ISO%2FIEC%20TR%2042106.html
doc_status: 6000
title:
  ISO/IEC TR 42106: Information technology — Artificial intelligence (AI) — Overview of differentiated benchmarking of AI system quality characteristics

abstract:
  ISO/IEC standard: Information technology — Artificial intelligence (AI) — Overview of differentiated benchmarking of AI system quality characteristics. Committee: ISO/IEC JTC 1/SC 42.


name: iso-fdis-15801
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.517438+00:00
source: iso
source_id: ISO/FDIS 15801
source_url: https://www.iso.org/standard/ISO%2FFDIS%2015801.html
doc_status: 5020
title:
  ISO/FDIS 15801: Document management — Electronically stored information — Requirements and guidance for trustworthiness and reliability

abstract:
  This document specifies the implementation and operation of information management systems that stores and make available for use electronically stored information (ESI) in a trustworthy and reliable manner. Such ESI can be of any type, including “page based” information, information in databases and audio/video information.This document is for use by any organization that uses information management systems to store trustworthy ESI over time.  Such systems incorporate policies, procedures, technology and audit requirements that ensure that trustworthiness of the ESI is maintained.This document does not cover processes used to evaluate whether ESI can be considered to be trustworthy prior to it being stored or imported into the system. However, it can be used to demonstrate that, once the electronic information is stored, output from the system will be a true and accurate reproduction of the ESI created and/or imported.


name: iso-iec-wd-ts-22440
rev: 00
title: ISO/IEC WD TS 22440: Artificial intelligence — Functional safety and AI systems — Requirements
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.520252+00:00
source: iso
source_id: ISO/IEC WD TS 22440
source_url: https://www.iso.org/standard/ISO%2FIEC%20WD%20TS%2022440.html
doc_status: 2098
abstract:
  This document provides requirements and guidance on the terminology, properties, risk factors, processes, methods, techniques and architectures relating to:  -	use of AI technology within a safety-related function;-	use of safety-related function based on conventional technology to ensure safety of a system using AI technology; -	use of AI technology to design, develop and verify safety-related functions.This document includes general considerations on how security threats can affect safety of an AI system.Unless differently specified, this document is applicable to all types of AI technologies. It includes specific details on machine learning (ML).


name: iso-iec-cd-ts-22443
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.523125+00:00
source: iso
source_id: ISO/IEC CD TS 22443
source_url: https://www.iso.org/standard/ISO%2FIEC%20CD%20TS%2022443.html
doc_status: 3099
title:
  ISO/IEC CD TS 22443: Information technology — Artificial intelligence — Guidance on addressing societal concerns and ethical considerations

abstract:
  This document provides guidance on how an organization can identify and address societal concerns and ethical considerations during the life cycle of AI systems that can potentially harm individuals and society.The document expands existing AI system governance, management system and impact assessment standards. This document is applicable to all types of organizations that develop or use AI systems, regardless of size, type and nature.


name: iso-iec-cd-23282
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.526242+00:00
source: iso
source_id: ISO/IEC CD 23282
source_url: https://www.iso.org/standard/ISO%2FIEC%20CD%2023282.html
doc_status: 3060
title:
  ISO/IEC CD 23282: Artificial Intelligence — Evaluation methods for accurate natural language processing systems

abstract:
  <p>This document specifies the evaluation of natural language processing systems, in the sense of measuring the quality of a system’s results to assess its functional suitability. It provides a definition of evaluation methods for those systems, together with guidance on how to select, implement and interpret those evaluation methods. This document covers quantitative metrics as well as other evaluation methods. It includes requirements on the implementation of the described metrics, and further requirements on the technical resources involved in the evaluation process.</p>


name: iso-16363-2025
rev: 00
time: 2025-03-05
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.529232+00:00
source: iso
source_id: ISO 16363:2025
source_url: https://www.iso.org/standard/ISO%2016363.html
doc_status: 6060
title:
  ISO 16363:2025: Space data and information transfer systems — Audit and certification of trustworthy digital repositories

abstract:
  <p class='MsoNormal'><span style='color: black; mso-color-alt: windowtext;'>This document defines a CCSDS Recommended Practice on which to base an audit and certification process for assessing the trustworthiness of digital repositories. The scope of application of this document is the entire range of digital repositories.</span></p>


name: iso-16919-2025
rev: 00
time: 2025-03-07
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.532372+00:00
source: iso
source_id: ISO 16919:2025
source_url: https://www.iso.org/standard/ISO%2016919.html
doc_status: 6060
title:
  ISO 16919:2025: Space data and information transfer systems — Requirements for bodies providing audit and certification of candidate trustworthy digital repositories

abstract:
  <p class='MsoNormal'><span lang='EN-GB' style='mso-ansi-language: EN-GB;'>This document defines a CCSDS Recommended Practice (and ISO standard) on which to base the operations of the organization(s) which assess the trustworthiness of digital repositories using the latest version of CCSDS 652.0/ISO 16363 (reference </span><!-- [if supportFields]><span lang=EN-GBstyle='mso-ansi-language:EN-GB'><span style='mso-element:field-begin'></span>REFR_652x0m2AuditandCertificationofTrustwor \\h<span style='mso-element:field-separator'></span></span><![endif]--><span lang='EN-GB' style='mso-ansi-language: EN-GB;'>[<span style='mso-no-proof: yes;'>1</span>]<!-- [if gte mso 9]><xml> <w:data>08D0C9EA79F9BACE118C8200AA004BA90B02000000080000002900000052005F00360035003200780030006D0032004100750064006900740061006E006400430065007200740069006600690063006100740069006F006E006F0066005400720075007300740077006F0072000000</w:data></xml><![endif]--></span><!-- [if supportFields]><span lang=EN-GBstyle='mso-ansi-language:EN-GB'><span style='mso-element:field-end'></span></span><![endif]--><span lang='EN-GB' style='mso-ansi-language: EN-GB;'>) and provide the appropriate certification. This document specifies requirements for bodies providing audit and certification of digital repositories, based on the metrics contained within ISO/IEC 17021-1 (reference </span><!-- [if supportFields]><spanlang=EN-GB style='mso-ansi-language:EN-GB'><span style='mso-element:field-begin'></span><spanstyle='mso-spacerun:yes'> </span>REF R_ISOIEC170212011ConformityAssessmentReq\\h <span style='mso-spacerun:yes'> </span>\\* MERGEFORMAT <spanstyle='mso-element:field-separator'></span></span><![endif]--><span lang='EN-GB' style='mso-ansi-language: EN-GB;'>[<span style='mso-no-proof: yes;'>4</span>]<!-- [if gte mso 9]><xml> <w:data>08D0C9EA79F9BACE118C8200AA004BA90B02000000080000002900000052005F00490053004F0049004500430031003700300032003100320030003100310043006F006E0066006F0072006D006900740079004100730073006500730073006D


name: iso-iec-dtr-23888-1
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.535673+00:00
source: iso
source_id: ISO/IEC DTR 23888-1
source_url: https://www.iso.org/standard/ISO%2FIEC%20DTR%2023888-1.html
doc_status: 5020
title:
  ISO/IEC DTR 23888-1: Information technology — Artificial intelligence for multimedia — Part 1: Vision and scenarios

abstract:
  ISO/IEC standard: Information technology — Artificial intelligence for multimedia — Part 1: Vision and scenarios. Committee: ISO/IEC JTC 1/SC 29.


name: iso-dts-24971-2.2
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.538786+00:00
source: iso
source_id: ISO/DTS 24971-2.2
source_url: https://www.iso.org/standard/ISO%2FDTS%2024971-2.2.html
doc_status: 5020
title:
  ISO/DTS 24971-2.2: Medical devices — Guidance on the application of ISO 14971 — Part 2: Machine learning in artificial intelligence

abstract:
  <p class='MsoNormal'><span style='font-size: 11.0pt; line-height: 115%; font-family: 'Arial',sans-serif;'>This document provides guidance on how to apply the risk management process of ISO 14971:2019 to ML-enabled medical devices (MLMD). This document is intended to be used in conjunction with ISO 14971 and does not alter the risk management requirements specified in ISO 14971. </span></p><p class='MsoNormal'><span style='font-size: 11.0pt; line-height: 115%; font-family: 'Arial',sans-serif;'>This document addresses risks specific to machine learning (ML). Those risks can be related to topics such as data management, feature extraction, unwanted bias, information security, training the ML model by an ML algorithm, evaluation and testing of the trained ML model. See Figure 1 for an overview of the relevant terms and their relationship. See Annex A for an explanation of bias.</span></p><p class='MsoNormal'><span style='font-size: 11.0pt; line-height: 115%; font-family: 'Arial',sans-serif;'>It is recognized that the ML model can require retraining after a period of use to redefine its parameters. An ML model can learn continuously from patient data and modify their parameters accordingly. The description “continuous(ly) learning” is used throughout this document; the term “adaptive” is sometimes used in other documents. This document also provides examples and suggests strategies for eliminating or controlling these ML-related risks.</span></p>


name: iso-iec-15938-18-2025
rev: 00
time: 2025-02-26
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.541933+00:00
source: iso
source_id: ISO/IEC 15938-18:2025
source_url: https://www.iso.org/standard/ISO%2FIEC%2015938-18.html
doc_status: 6060
title:
  ISO/IEC 15938-18:2025: Information technology — Multimedia content description interface — Part 18: Conformance and reference software for compression of neural networks

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document specifies conformance testing procedures for implementations of ISO/IEC 15938-17 and provides conformance bitstreams. It also provides the reference software for ISO/IEC 15938-17 which is an integral part of this document.</span></p>


name: iso-dis-24051-1
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.544945+00:00
source: iso
source_id: ISO/DIS 24051-1
source_url: https://www.iso.org/standard/ISO%2FDIS%2024051-1.html
doc_status: 4000
title:
  ISO/DIS 24051-1: Medical laboratories — Part 1: General principles for the application of artificial intelligence in medical laboratories

abstract:
  This document specifies general principles for the application of artificial intelligence in the medical laboratory.This document is applicable to methods commonly considered subsets of artificial intelligence, including fuzzy logic, Bayesian networks, supervised and unsupervised machine learning, deep learning, neural networks, expert systems, robotics, natural language processing and image analysis.


name: iso-cd-24051-2
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.548040+00:00
source: iso
source_id: ISO/CD 24051-2
source_url: https://www.iso.org/standard/ISO%2FCD%2024051-2.html
doc_status: 3092
title:
  ISO/CD 24051-2: Medical laboratories — Part 2: Digital pathology and artificial intelligence (AI)-based image analysis

abstract:
  This document specifies requirements and gives recommendations for the digitalization of slide-mounted, stained sections, processing of digital whole slide images, and artificial intelligence (AI) based image analysis to support anatomical pathology examination. This document focuses on sections from formalin-fixed paraffin-embedded (FFPE) tissues (derived e.g. from surgical resection, biopsy or autopsy). It is also applicable to paraffin-embedded tissue fixed by fixatives other than formalin. This document is applicable to in vitro diagnostic examinations using digital pathology and AI-based image analysis performed by medical laboratories, in particular but not limited to anatomical pathology laboratories. It is also intended to be used by health institutions, in vitro diagnostics developers and manufacturers, and regulatory authorities. NOTE 	International, national or regional regulations or requirements can also apply to specific topics covered in this document.


name: iso-22133-2026
rev: 00
time: 2026-01-27
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.551216+00:00
source: iso
source_id: ISO 22133:2026
source_url: https://www.iso.org/standard/ISO%2022133.html
doc_status: 6060
title:
  ISO 22133:2026: Road vehicles — Test object monitoring and control for active safety and automated/autonomous vehicle testing — Functional requirements, specifications and communication protocol

abstract:
  <p><span lang='EN-GB'>This document specifies requirements, procedures and message formats for controlling and monitoring of test objects, used for testing of active safety functions and autonomous vehicles.</span></p><p><span lang='EN-GB'>This document specifies functionality and messaging for monitoring and controlling of test objects by a control centre facilitating an interoperable test object environment. This document defines a communication protocol which allows for the control centre to safely execute tests using test objects from multiple vendors.</span></p><p><span lang='EN-GB'>This document does not specify the internal architecture of the test object nor control centre.</span></p><p><span lang='EN-GB'>This document does not specify how testing of the vehicles shall be performed.</span></p>


name: iso-iec-22989-2022-damd-1
rev: 00
time: 2022/DAmd 1
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.554918+00:00
source: iso
source_id: ISO/IEC 22989:2022/DAmd 1
source_url: https://www.iso.org/standard/ISO%2FIEC%2022989.html
doc_status: 4060
title:
  ISO/IEC 22989:2022/DAmd 1: Information technology — Artificial intelligence — Artificial intelligence concepts and terminology — Amendment 1: Generative AI

abstract:
  ISO/IEC standard: Information technology — Artificial intelligence — Artificial intelligence concepts and terminology — Amendment 1: Generative AI. Committee: ISO/IEC JTC 1/SC 42.


name: iso-iec-23053-2022-damd-1
rev: 00
time: 2022/DAmd 1
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.558017+00:00
source: iso
source_id: ISO/IEC 23053:2022/DAmd 1
source_url: https://www.iso.org/standard/ISO%2FIEC%2023053.html
doc_status: 4060
title:
  ISO/IEC 23053:2022/DAmd 1: Framework for Artificial Intelligence (AI) Systems Using Machine Learning (ML) — Amendment 1: Generative AI

abstract:
  ISO/IEC standard: Framework for Artificial Intelligence (AI) Systems Using Machine Learning (ML) — Amendment 1: Generative AI. Committee: ISO/IEC JTC 1/SC 42.


name: iso-iec-dis-25059
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.560842+00:00
source: iso
source_id: ISO/IEC DIS 25059
source_url: https://www.iso.org/standard/ISO%2FIEC%20DIS%2025059.html
doc_status: 4020
title:
  ISO/IEC DIS 25059: Software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Quality models for AI systems

abstract:
  This document outlines quality models for AI systems and services and is an applicationspecificextension to the standards on SQuaRE. The characteristics and sub-characteristicsdetailed in the models provide consistent terminology for specifying, measuring and evaluatingAI system and service quality. The characteristics and sub-characteristics detailed in themodels also provide a set of quality characteristics against which stated quality requirementscan be compared for completeness.


name: iso-iec-cd-tr-42109
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.564095+00:00
source: iso
source_id: ISO/IEC CD TR 42109
source_url: https://www.iso.org/standard/ISO%2FIEC%20CD%20TR%2042109.html
doc_status: 3060
title:
  ISO/IEC CD TR 42109: Information technology — Artificial intelligence — Use cases of human-machine teaming

abstract:
  ISO/IEC standard: Information technology — Artificial intelligence — Use cases of human-machine teaming. Committee: ISO/IEC JTC 1/SC 42.


name: iso-iec-np-ts-42110
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.567226+00:00
source: iso
source_id: ISO/IEC NP TS 42110
source_url: https://www.iso.org/standard/ISO%2FIEC%20NP%20TS%2042110.html
doc_status: 1098
title:
  ISO/IEC NP TS 42110: Information technology — Artificial intelligence — AI inference framework for AI systems

abstract:
  This document describes guidance for a comprehensive “AI inference framework for AI systems”. The framework includes AI inference concepts and terminology, AI inference modelling and components, AI inference framework processes, and AI inference performance. The AI inference framework is designed for generalized AI systems and is not specific to AI systems.


name: iso-iec-awi-ts-42111
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.570332+00:00
source: iso
source_id: ISO/IEC AWI TS 42111
source_url: https://www.iso.org/standard/ISO%2FIEC%20AWI%20TS%2042111.html
doc_status: 2000
title:
  ISO/IEC AWI TS 42111: Information technology — Artificial intelligence — Guidance on lightweight AI systems

abstract:
  This document provides guidance on developing and deploying lightweight AI systems optimized forlimited resource utilization.The optimization approach for AI model training efficiency is not within the scope of the this document.


name: iso-iec-dts-42112
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.573365+00:00
source: iso
source_id: ISO/IEC DTS 42112
source_url: https://www.iso.org/standard/ISO%2FIEC%20DTS%2042112.html
doc_status: 5020
title:
  ISO/IEC DTS 42112: Information technology — Artificial intelligence — Guidance on machine learning model training efficiency optimization

abstract:
  <p>This document describes the characteristics that impact machine learning model training efficiency and then provides the optimization approaches that apply to these characteristics. This document provides AI providers and AI producers with a set of characteristics and the related optimizations that they can use to enhance their machine learning model training efficiency. AI providers and AI producers can also use this information to evaluate different machine learning model training approaches. This document does not specify any training accelerating mechanisms provided and implemented within machine learning computing device defined in ISO /IEC TR 17903 and its library.</p>


name: iso-iec-cd-31303.2
rev: 00
title: ISO/IEC CD 31303.2: Information technology — Trustworthiness — Overview and concepts
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.576675+00:00
source: iso
source_id: ISO/IEC CD 31303.2
source_url: https://www.iso.org/standard/ISO%2FIEC%20CD%2031303.2.html
doc_status: 3060
abstract:
  This document provides an overview of trustworthiness and related concepts and describes trustworthiness applicable to information technology (IT).


name: iso-iec-dis-24970
rev: 00
title: ISO/IEC DIS 24970: Artificial intelligence — AI system logging
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.579832+00:00
source: iso
source_id: ISO/IEC DIS 24970
source_url: https://www.iso.org/standard/ISO%2FIEC%20DIS%2024970.html
doc_status: 4060
abstract:
  This document describes common capabilities, requirements and a supporting information model for logging of events in AI systems.This document is designed to be used with a risk management system.


name: iso-pwi-24986
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.582982+00:00
source: iso
source_id: ISO/PWI 24986
source_url: https://www.iso.org/standard/ISO%2FPWI%2024986.html
doc_status: 20
title:
  ISO/PWI 24986: Energy performance of building systems — Determination of energy performance of machine learning based optimal control strategy by field measuring methods

abstract:
  The proposed standard is a comprehensive international standard related to building energy prediction and optimal energy saving control using artificial intelligence. This standard includes content on the development of an energy prediction model using artificial intelligence, content on the development of an energy saving algorithm using an machine learning (ML)-based energy prediction model, and application of the energy saving algorithm to actual buildings through toolbox integration.


name: iso-iec-cd-25029
rev: 00
title: ISO/IEC CD 25029: Artificial intelligence — AI-enhanced nudging
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.586195+00:00
source: iso
source_id: ISO/IEC CD 25029
source_url: https://www.iso.org/standard/ISO%2FIEC%20CD%2025029.html
doc_status: 3060
abstract:
  This standard applies to nudging mechanisms enhanced by AI systems.This document provides definitions, concepts, and guidelines to address AI-enhanced nudging mechanisms by organisations. This standard aims to support organisations to deal with AI-enhanced nudging mechanisms in alignment with existing AI standards. “AI-enhanced nudging mechanisms” are a sub category of digital nudges and which are enhanced by AI systems. It provides use-cases to illustrate AI-enhanced nudging mechanisms. It provides guidelines and requirements for designing responsible AI-enhanced nudging mechanisms. This includes horizontal processes and key indicators using specific vertical examples.


name: iso-iec-ieee-np-29119-16
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.589601+00:00
source: iso
source_id: ISO/IEC/IEEE NP 29119-16
source_url: https://www.iso.org/standard/ISO%2FIEC%2FIEEE%20NP%2029119-16.html
doc_status: 1098
title:
  ISO/IEC/IEEE NP 29119-16: Software and systems engineering — Software testing — Part 16: Testing of Machine Learning systems

abstract:
  This document provides requirements and guidance on the application of the ISO/IEC/IEEE 29119 series and ISO/IEC 20246 to the testing of machine learning (ML) software and ML systems. This document requires a risk-based approach to testing, and uses generic risks associated with ML systems, and their development and maintenance, to identify suitable treatments in the form of various test approaches (including test levels, test practices, test types, static testing, and test design techniques and measures). When these test approaches and reviews are already specified in the ISO/IEC/IEEE 29119 series or ISO/IEC 20246, this document provides additional detail and describes their application in the context of ML.This document does not cover the testing of adaptive ML systems that can change their functionality once operational, such as reinforcement learning systems and other self-learning systems.


name: iso-iec-cd-tr-23281
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.593428+00:00
source: iso
source_id: ISO/IEC CD TR 23281
source_url: https://www.iso.org/standard/ISO%2FIEC%20CD%20TR%2023281.html
doc_status: 3060
title:
  ISO/IEC CD TR 23281: Artificial intelligence — Overview of AI tasks and functionalities related to natural language processing

abstract:
  <p>This document describes the concept of AI task as applied to natural language. It proposes a landscaping of the AI tasks related to the analysis or generation of natural language, as well as other languagerelated functionalities that are associated to those AI systems. It identifies existing and competing terminologies, co-existing variants of the same tasks and functionalities, and how specific tasks can be affected by language diversity in terms of their role or their challenges. This includes all languages, dialects and variants, whether official or not. The relations among tasks or functionalities, and their interactions within pipelines, are discussed and illustrated. In addition, the document provides references to existing standards and published guidelines associated to those tasks and functionalities, highlighting their differences in case of competing standards.</p>


name: iso-iec-dis-23888-2
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.596900+00:00
source: iso
source_id: ISO/IEC DIS 23888-2
source_url: https://www.iso.org/standard/ISO%2FIEC%20DIS%2023888-2.html
doc_status: 4000
title:
  ISO/IEC DIS 23888-2: Information technology — Artificial intelligence for multimedia — Part 2: Video coding for machines

abstract:
  This project will define bitstream syntax and semantics of encoded video, decoding procedure to reconstruct video as well as descriptors extracted from video that is efficient in terms of bitrate and performance of machine tasks after decoding.


name: iso-dis-16400-6
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.600384+00:00
source: iso
source_id: ISO/DIS 16400-6
source_url: https://www.iso.org/standard/ISO%2FDIS%2016400-6.html
doc_status: 4000
title:
  ISO/DIS 16400-6: Automation systems and integration — Equipment behaviour catalogues for virtual production systems — Part 6: An equipment behaviour catalogue with machine learning models

abstract:
  This document specifies an equipment behaviour catalogue (EBC) with machine learning (ML). It allows ML models to be used as a part of equipment behaviour descriptions.


name: iso-iec-dtr-23888-3.2
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.603769+00:00
source: iso
source_id: ISO/IEC DTR 23888-3.2
source_url: https://www.iso.org/standard/ISO%2FIEC%20DTR%2023888-3.2.html
doc_status: 5000
title:
  ISO/IEC DTR 23888-3.2: Information technology — Artificial intelligence for multimedia — Part 3: Optimization of encoders and receiving systems for machine analysis of coded video content

abstract:
  ISO/IEC standard: Information technology — Artificial intelligence for multimedia — Part 3: Optimization of encoders and receiving systems for machine analysis of coded video content. Committee: ISO/IEC JTC 1/SC 29.


name: iso-19178-1-2025
rev: 00
time: 2025-05-27
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.607588+00:00
source: iso
source_id: ISO 19178-1:2025
source_url: https://www.iso.org/standard/ISO%2019178-1.html
doc_status: 6060
title:
  ISO 19178-1:2025: Geographic information — Training data markup language for artificial intelligence — Part 1: Conceptual model

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>Within the context of training data for Earth Observation (EO) Artificial Intelligence Machine Learning (AI/ML), this document specifies a conceptual model that:</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><span lang='EN-GB'>establishes a UML model with a target of maximizing the interoperability and usability of EO imagery training data;</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><span lang='EN-GB'>specifies different AI/ML tasks and labels in EO in terms of supervised learning, including scene level, object level and pixel level tasks;</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><span lang='EN-GB'>describes the permanent identifier, version, licence, training data size, measurement or imagery used for annotation;</span></p><p class='ListContinue1' style='mso-list: l0 level1 lfo1;'><!-- [if !supportLists]--><span lang='EN-GB' style='mso-fareast-font-family: Cambria; mso-bidi-font-family: Cambria;'><span style='mso-list: Ignore;'>—<span style='font: 7.0pt 'Times New Roman';'>     </span></span></span><!--[endif]--><span lang='EN-GB'>specifies a description of quality (e.g. training data errors, training data representativeness, quality measures) and proven


name: iso-cd-25132
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.611243+00:00
source: iso
source_id: ISO/CD 25132
source_url: https://www.iso.org/standard/ISO%2FCD%2025132.html
doc_status: 3060
title:
  ISO/CD 25132: Classification of civil unmanned aircraft system (UAS) autonomous flight control levels

abstract:
  This document defines the classification of civil unmanned aircraft system (UAS) autonomous flight control levels. Based on the human machine role allocation, this document defines 6 UAS autonomous levels, from no autonomy (level 0) to full autonomy (level 5).


name: iso-pwi-ts-21947
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.614681+00:00
source: iso
source_id: ISO/PWI TS 21947
source_url: https://www.iso.org/standard/ISO%2FPWI%20TS%2021947.html
doc_status: 60
title:
  ISO/PWI TS 21947: Machine Learning Application to Surface Analysis Data. Part I: Mass Spectrum and Imaging

abstract:
  This technical report (TS) provides guidelines of machine learning application to mass spectrometry data including spectra and mass images. Machine learning includes numerical analysis methods using computers such as multivariate analysis, artificial neural network-based methods and combination of multiple learning methods, and is generally classified into three categories, unsupervised learning, supervised learning, and reinforcement learning. This TS gives explanations of basic terms regarding machine learning and shows suitable methods depending on the analysis purposes and necessary procedures to data preparation for machine learning. This TS does not strictly regulate learning methods for mass spectrometry data because new learning methods and modified methods are being developed.


name: iso-iec-cd-4213
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.618107+00:00
source: iso
source_id: ISO/IEC CD 4213
source_url: https://www.iso.org/standard/ISO%2FIEC%20CD%204213.html
doc_status: 3060
title:
  ISO/IEC CD 4213: Artificial intelligence — Performance measurement for AI classification, regression, clustering and recommendation tasks

abstract:
  This document specifies methodologies for measuring the performance of AI models for classification, regression, clustering and recommendation tasks.


name: iso-iec-awi-22989-2
rev: 00
title: ISO/IEC AWI 22989-2: Artificial intelligence — Concepts and terminology — Part 2: Healthcare
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.621569+00:00
source: iso
source_id: ISO/IEC AWI 22989-2
source_url: https://www.iso.org/standard/ISO%2FIEC%20AWI%2022989-2.html
doc_status: 2000
abstract:
  This document establishes terminology for Al and describes concepts in the field of AI for healthcare.This document can be used in the development of other standards and in support of communications among diverse, interested parties or stakeholders.This document is applicable to all types of organizations (e.g. commercial enterprises, government agencies, not-for-profit organizations).


name: iso-iec-awi-ts-25223
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.624983+00:00
source: iso
source_id: ISO/IEC AWI TS 25223
source_url: https://www.iso.org/standard/ISO%2FIEC%20AWI%20TS%2025223.html
doc_status: 2000
title:
  ISO/IEC AWI TS 25223: Information technology — Artificial intelligence — Guidance and requirements for uncertainty quantification in AI systems

abstract:
  This document specifies general and technical guidance and requirements for the development and use of methods for the quantification of uncertainties in AI systems.This document defines fundamental terminology for uncertainty quantification in AI systems along with the characteristics of selected approaches to uncertainty quantification. The characteristics and approaches are then described through selected applications.This document describes aspects of quantification of uncertainties for all stages of the AI system life cycle.


name: iso-iec-cd-ts-22440-1
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.628394+00:00
source: iso
source_id: ISO/IEC CD TS 22440-1
source_url: https://www.iso.org/standard/ISO%2FIEC%20CD%20TS%2022440-1.html
doc_status: 3020
title:
  ISO/IEC CD TS 22440-1: Artificial intelligence — Functional safety and AI systems — Part 1: Requirements

abstract:
  ISO/IEC standard: Artificial intelligence — Functional safety and AI systems — Part 1: Requirements. Committee: ISO/IEC JTC 1/SC 42.


name: iso-iec-cd-ts-22440-2
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.631909+00:00
source: iso
source_id: ISO/IEC CD TS 22440-2
source_url: https://www.iso.org/standard/ISO%2FIEC%20CD%20TS%2022440-2.html
doc_status: 3020
title:
  ISO/IEC CD TS 22440-2: Artificial intelligence — Functional safety and AI systems — Part 2: Guidance

abstract:
  ISO/IEC standard: Artificial intelligence — Functional safety and AI systems — Part 2: Guidance. Committee: ISO/IEC JTC 1/SC 42.


name: iso-iec-cd-ts-22440-3
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.635452+00:00
source: iso
source_id: ISO/IEC CD TS 22440-3
source_url: https://www.iso.org/standard/ISO%2FIEC%20CD%20TS%2022440-3.html
doc_status: 3020
title:
  ISO/IEC CD TS 22440-3: Artificial intelligence — Functional safety and AI systems — Part 3: Examples of application

abstract:
  ISO/IEC standard: Artificial intelligence — Functional safety and AI systems — Part 3: Examples of application. Committee: ISO/IEC JTC 1/SC 42.


name: iso-iec-awi-ts-25258
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.638587+00:00
source: iso
source_id: ISO/IEC AWI TS 25258
source_url: https://www.iso.org/standard/ISO%2FIEC%20AWI%20TS%2025258.html
doc_status: 2000
title:
  ISO/IEC AWI TS 25258: Information technology — Artificial intelligence — Hybrid AI inference framework for AI systems

abstract:
  This document provides effective guidance for an AI inference framework for AI systems with multiple tasks to generate output in the deployment process.


name: iso-cd-25268
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.642000+00:00
source: iso
source_id: ISO/CD 25268
source_url: https://www.iso.org/standard/ISO%2FCD%2025268.html
doc_status: 3099
title:
  ISO/CD 25268: Guidelines for Hospital Internal Logistics Services using Autonomous Mobile Robots for the Delivery of Pharmaceuticals

abstract:
  This document gives guidelines for Healthcare Organization Management including healthcare suppliers and manufacturers of Autonomous Mobile Robots (AMRs) where they implement the internal hospital logistics using autonomous mobile robots. It includes the key components that should be considered to provide safe and reliable internal hospital logistics of pharmaceutics. It covers physical arrangement of AMR including medication packaging, delivery chambers, emergency halt method and logistics environment of hospitals such as elevator in-and-out sequence, locations of the delivery.


name: iso-iec-cd-42007
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.645381+00:00
source: iso
source_id: ISO/IEC CD 42007
source_url: https://www.iso.org/standard/ISO%2FIEC%20CD%2042007.html
doc_status: 3060
title:
  ISO/IEC CD 42007: Information technology — Artificial intelligence — High-level framework and guidance for the development of conformity assessment schemes for AI systems

abstract:
  This document provides a high-level framework and guidance for the development and operation of conformity assessment schemes, including certification schemes, for artificial intelligence (AI) systems.


name: iso-awi-tr-24492
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.649082+00:00
source: iso
source_id: ISO/AWI TR 24492
source_url: https://www.iso.org/standard/ISO%2FAWI%20TR%2024492.html
doc_status: 1099
title:
  ISO/AWI TR 24492: Standardization needs for the application of artificial intelligence in the financial services industry

abstract:
  ISO/IEC standard: Standardization needs for the application of artificial intelligence in the financial services industry. Committee: ISO/IEC JTC 1/SC 42.


name: iso-iec-awi-25505
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.652324+00:00
source: iso
source_id: ISO/IEC AWI 25505
source_url: https://www.iso.org/standard/ISO%2FIEC%20AWI%2025505.html
doc_status: 2000
title:
  ISO/IEC AWI 25505: Information technology — Telecommunications and information exchange between systems — Charging communication interface protocols for autonomous moving achines

abstract:
  This International Standard defines the communication protocol architecture and message framework for wireless energy transfer and management in autonomous moving machines (AMMs) operating across heterogeneous wireless networks.It specifies logical communication structures above the MAC layer to enable energy transfer session coordination, device identification and authentication, session continuity, and seamless network handover during autonomous charging operations.This standard defines logical communication and message structures operating above the MAC layer, enabling interoperability across heterogeneous wireless networks such as wireless LAN (IEEE 802.11) and short-range wireless communication technologies (IEEE 802.15.4 family), without requiring changes or constraints to existing physical or MAC technologies.This International Standard is intended to be developed in multiple parts:•	Part 1 - Architecture and Requirements•	Part 2 - Communication Protocol•	Part 3 – Protocol for Communication Synchronization and OperationAdditional parts may be developed as needed to address related technical topics within the scope of this work item.


name: iso-iec-awi-tr-25523
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.655874+00:00
source: iso
source_id: ISO/IEC AWI TR 25523
source_url: https://www.iso.org/standard/ISO%2FIEC%20AWI%20TR%2025523.html
doc_status: 2000
title:
  ISO/IEC AWI TR 25523: Information technology — Artificial intelligence — Overview of data profiles for analytics and ML

abstract:
  ISO/IEC standard: Information technology — Artificial intelligence — Overview of data profiles for analytics and ML. Committee: ISO/IEC JTC 1/SC 42.


name: iso-iec-awi-ts-25566
rev: 00
title: ISO/IEC AWI TS 25566: Terminology and concepts for domain engineering of AI systems
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.659180+00:00
source: iso
source_id: ISO/IEC AWI TS 25566
source_url: https://www.iso.org/standard/ISO%2FIEC%20AWI%20TS%2025566.html
doc_status: 2000
abstract:
  This document provides terminology and concepts of domain engineering of AI systems.This document is intended for use by organizations developing, providing or using AI systems, regardless of the organisations’ size, type or sector.


name: iso-iec-awi-ts-25568
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.662638+00:00
source: iso
source_id: ISO/IEC AWI TS 25568
source_url: https://www.iso.org/standard/ISO%2FIEC%20AWI%20TS%2025568.html
doc_status: 2000
title:
  ISO/IEC AWI TS 25568: Information technology — Artificial Intelligence — Guidance on addressing risks in generative AI systems

abstract:
  This document provides guidance on addressing risks in generative artificial intelligence (AI) systems. It includes:-	The objectives of generative AI systems when identifying risks.-	The risk sources and the stakeholders facing the risks in generative AI systems throughout its life cycle.-	Guidance for risk analysis, risk treatment and controls of addressing risks in generative AI systems.


name: iso-iec-awi-ts-25569
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.665969+00:00
source: iso
source_id: ISO/IEC AWI TS 25569
source_url: https://www.iso.org/standard/ISO%2FIEC%20AWI%20TS%2025569.html
doc_status: 2000
title:
  ISO/IEC AWI TS 25569: Artificial Intelligence — Implementation guidance on de-identification of data used in Machine Learning (ML)

abstract:
  This document provides implementation guidance on de-identifying data used in machine learning. The guidance includes methods that can be used during machine learning model development.


name: iso-iec-awi-ts-25570
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.669304+00:00
source: iso
source_id: ISO/IEC AWI TS 25570
source_url: https://www.iso.org/standard/ISO%2FIEC%20AWI%20TS%2025570.html
doc_status: 2000
title:
  ISO/IEC AWI TS 25570: Information Technology — Artificial Intelligence — Reliability assessment of AI systems

abstract:
  This document provides methods and mechanisms to assess the reliability of an AI system. It describes the metrics of reliability and the procedure for reliability assessment from a statistical perspective.


name: iso-iec-awi-ts-25571
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.672611+00:00
source: iso
source_id: ISO/IEC AWI TS 25571
source_url: https://www.iso.org/standard/ISO%2FIEC%20AWI%20TS%2025571.html
doc_status: 1099
title:
  ISO/IEC AWI TS 25571: Artificial Intelligence — Example template for documenting ethical issues of an AI system

abstract:
  This document provides an example template for stakeholders to document potential ethical issues that can arise at each stage of the AI system lifecycle. It provides associated instructions for the use of the template.


name: iso-iec-awi-25589
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.675808+00:00
source: iso
source_id: ISO/IEC AWI 25589
source_url: https://www.iso.org/standard/ISO%2FIEC%20AWI%2025589.html
doc_status: 2000
title:
  ISO/IEC AWI 25589: Information technology — Artificial intelligence — Framework for human-machine teaming

abstract:
  This document describes a framework for human-machine teaming. This document provides concepts, terms and definitions applicable to describe the relationships between humans and machines in human-machine teaming, which refers to integration of human interaction with machine intelligence capabilities to enable problem solving and successful task completion.This document also describes a set of technical characteristics of human-machine teaming.This document provides a set of design principles for human-machine teaming.This document provides guidance based on ISO/IEC 5339 for developing and applying AI applications in human-machine teaming.


name: iso-iec-awi-25590
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.679011+00:00
source: iso
source_id: ISO/IEC AWI 25590
source_url: https://www.iso.org/standard/ISO%2FIEC%20AWI%2025590.html
doc_status: 2000
title:
  ISO/IEC AWI 25590: Information technology — Artificial intelligence — Guidance for output data quality of generative AI applications

abstract:
  Provide guidance to measure quality of output data obtained using generative AI applications. This document also provides key considerations towards output data quality which can be considered based on the context and usage of generative AI applications. This document addresses the need of stakeholders from make, use and impact perspective of generative AI application.


name: iso-iec-awi-25623
rev: 00
title: ISO/IEC AWI 25623: Artificial intelligence — Machine learning (ML) model description framework
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.682208+00:00
source: iso
source_id: ISO/IEC AWI 25623
source_url: https://www.iso.org/standard/ISO%2FIEC%20AWI%2025623.html
doc_status: 2000
abstract:
  This document provides a general description framework and elements of documentation for ML models to facilitate their management and use throughout the ML model life cycle. This document is applicable to any organization that develops, provides or uses ML models.


name: iso-iec-awi-42003
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.685429+00:00
source: iso
source_id: ISO/IEC AWI 42003
source_url: https://www.iso.org/standard/ISO%2FIEC%20AWI%2042003.html
doc_status: 2000
title:
  ISO/IEC AWI 42003: Information technology — Artificial intelligence — Guidance on the implementation of ISO/IEC 42001

abstract:
  This document provides guidance for implementing ISO/IEC 42001, including competencies for AI management systems (AIMS) professionals.This document is intended for use by any organization, regardless of size, type and nature that plans on referencing or implementing ISO/IEC 42001.


name: iso-dis-42501
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.688709+00:00
source: iso
source_id: ISO/DIS 42501
source_url: https://www.iso.org/standard/ISO%2FDIS%2042501.html
doc_status: 4000
title:
  ISO/DIS 42501: Sharing economy — General trustworthiness and safety requirements for digital platforms

abstract:
  <p>This document specifies general trustworthiness and safety requirements applicable to operators of digital platforms within the sharing economy. While this document does not cover system requirements for digital platforms, the document is still beneficial for system development.</p>


name: iso-iec-awi-ts-42119-7
rev: 00
title: ISO/IEC AWI TS 42119-7: Artificial intelligence — Testing of AI — Part 7: Red teaming
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.692319+00:00
source: iso
source_id: ISO/IEC AWI TS 42119-7
source_url: https://www.iso.org/standard/ISO%2FIEC%20AWI%20TS%2042119-7.html
doc_status: 2000
abstract:
  This document provides technology-agnostic guidance for conducting red teaming assessments on AI systems. The document covers:— Definitions and terminology specific to red teaming in AI contexts— Identification of risks, applicability, objectives and attack vectors— Methodologies for planning and executing red teaming assessments on AI systems, aligned with ISO/IEC 29119 processes as appropriate— Procedures for documenting and reporting red teaming findings— Recommendations for integrating red teaming into the AI system lifecycleThis document is applicable to testing all types of AI systems.


name: iso-iec-awi-25704
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.696291+00:00
source: iso
source_id: ISO/IEC AWI 25704
source_url: https://www.iso.org/standard/ISO%2FIEC%20AWI%2025704.html
doc_status: 1099
title:
  ISO/IEC AWI 25704: Artificial Intelligence — Process assessment model for AI system life cycle processes

abstract:
  This document provides  a process assessment model as a basis for the assessment of AI process capability based on the process measurement framework for the processes performed during AI system life cycle stages in ISO/IEC 22989:2022. The processes performed during AI system life cycle stages are defined in ISO/IEC 5338:2023. Based on ISO/IEC 33020:2019, the process measurement framework provides a set of indicators for measuring performance and capability of those processes. These indicators are used as a basis for collecting evidence that enable an organization to determine its process capability level. This document applies to any type of organization, that provides, develops, or uses products or services that utilize AI systems.


name: iso-cd-21520
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.699928+00:00
source: iso
source_id: ISO/CD 21520
source_url: https://www.iso.org/standard/ISO%2FCD%2021520.html
doc_status: 3060
title:
  ISO/CD 21520: Project, programme and portfolio management — Artificial intelligence — Concepts, applications, and implications

abstract:
  This standard proposal outlines artificial intelligence (AI) concepts, applications, and implications, as well as benefits, risks, governance framework, and scope for use by organizations within the context of project, programme, and portfolio management (P3M).  This proposed standard is intended to supplement the other TC 258 standards and is in direct alignment with standards prepared by ISO/TC 258. This document provides guidance for organizations on what to consider when adopting or looking to improve on existing AI technologies that directly support P3M. This proposed standard is applicable to any organization, including public, private, and charitable, as well as to any type of project, regardless of purpose, delivery approaches, project or programme lifecycle model used, complexity, size, cost, or duration.  This document also provides (P3M) practitioners (including top-level management, project managers, PMO’s, etc.) with AI-related guidance and consideration in the areas of security, privacy, transparency, and bias, as well as related data governance, ethical and risk considerations.


name: iec-np-ts-62366-3
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.703172+00:00
source: iso
source_id: IEC/NP TS 62366-3
source_url: https://www.iso.org/standard/IEC%2FNP%20TS%2062366-3.html
doc_status: 1060
title:
  IEC/NP TS 62366-3: Medical devices — Part 3: Guidance on the application of usability engineering to medical devices using artificial intelligence and machine learning technology

abstract:
  This Part of IEC 62366, which is a Technical Specification, contains background information and provides guidance that addresses the specific areas that experience suggests can be helpful for those implementing the usability engineering process as defined in IEC 62366-1 for medical devices utilizing artificial intelligence and/or machine learning technology. The technical specification is not intended to be used for regulatory purposes. It contains no requirements and only provides guidance and tutorial information.


name: iso-iec-awi-ts-42119-8
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.706362+00:00
source: iso
source_id: ISO/IEC AWI TS 42119-8
source_url: https://www.iso.org/standard/ISO%2FIEC%20AWI%20TS%2042119-8.html
doc_status: 2000
title:
  ISO/IEC AWI TS 42119-8: Artificial intelligence — Testing of AI — Part 8: Quality assessment of prompt-based text-to-text systems that utilize generative AI

abstract:
  This document provides definitions, concepts, requirements and guidance related to assessing prompt-based text-to-text AI systems that utilize generative AI. It covers quality assessment (which encompasses safety) using methodologies including red teaming and builds on existing standards such as ISO/IEC 23282 and ISO/IEC 42119-7. Additionally, it details methods for analyzing and interpreting results, as well as best practices for documentation


name: iso-iec-awi-25870
rev: 00
title: ISO/IEC AWI 25870: Artificial intelligence — Reporting for AI incidents
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.709471+00:00
source: iso
source_id: ISO/IEC AWI 25870
source_url: https://www.iso.org/standard/ISO%2FIEC%20AWI%2025870.html
doc_status: 2000
abstract:
  This document specifies a framework for data elements of reports of AI incidents that have occurred.This document is applicable to all types of organizations (e.g., commercial enterprises, government agencies, not-for-profit organizations).


name: iso-iec-awi-25872-1
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.712580+00:00
source: iso
source_id: ISO/IEC AWI 25872-1
source_url: https://www.iso.org/standard/ISO%2FIEC%20AWI%2025872-1.html
doc_status: 2000
title:
  ISO/IEC AWI 25872-1: Artificial intelligence — Knowledge enhancement for pretrained machine learning models — Part 1: Framework

abstract:
  This document describes the framework of knowledge enhancement for pretrained machine learning models, and also provides guidance on methods of knowledge enhancement.


name: iso-iec-awi-ts-25864
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.759720+00:00
source: iso
source_id: ISO/IEC AWI TS 25864
source_url: https://www.iso.org/standard/ISO%2FIEC%20AWI%20TS%2025864.html
doc_status: 2000
title:
  ISO/IEC AWI TS 25864: Information technology — Artificial Intelligence (AI) — Resilience assessment of AI systems

abstract:
  This document provides methods and mechanisms to assess the resilience of AI systems. It describes a comprehensive framework comprising guidelines, methodologies, and quantifiable metrics to assess an AI system’s resilience.


name: iso-iec-np-25880
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.769077+00:00
source: iso
source_id: ISO/IEC NP 25880
source_url: https://www.iso.org/standard/ISO%2FIEC%20NP%2025880.html
doc_status: 1020
title:
  ISO/IEC NP 25880: Requirements and Guidance for the organizational implementation of human-machine teaming

abstract:
  This document specifies requirements and provides guidance for the organizational implementation of the human-machine teaming (HMT) in the practical operation of an AI system.This document applies to all user groups that develop, produce or use AI-Applications.


name: iso-awi-tr-25896
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.772119+00:00
source: iso
source_id: ISO/AWI TR 25896
source_url: https://www.iso.org/standard/ISO%2FAWI%20TR%2025896.html
doc_status: 2000
title:
  ISO/AWI TR 25896: Management of terminology resources - Artificial intelligence for terminology management

abstract:
  ISO/IEC standard: Management of terminology resources - Artificial intelligence for terminology management. Committee: ISO/TC 37/SC 3.


name: iso-iec-awi-25058
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.774999+00:00
source: iso
source_id: ISO/IEC AWI 25058
source_url: https://www.iso.org/standard/ISO%2FIEC%20AWI%2025058.html
doc_status: 2000
title:
  ISO/IEC AWI 25058: Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Measurement and guidance for quality evaluation of AI systems

abstract:
  This document provides measurement and guidance for quality evaluation of artificial intelligence (AI) systems using AI system quality models defined in ISO/IEC 25059. It contains a set of quality measures and guidance for AI system quality models.The document is applicable to all types of organizations engaged in the development and use of AI systems.


name: iso-awi-25922
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.777757+00:00
source: iso
source_id: ISO/AWI 25922
source_url: https://www.iso.org/standard/ISO%2FAWI%2025922.html
doc_status: 2000
title:
  ISO/AWI 25922: Ships and marine technology — Method for defining and allocating capabilities and responsibilities between maritime autonomous surface ships and their remote operators

abstract:
  The proposed standard specifies a method for describing the capabilities and responsibilities of a MASS and its human operators. This is based on certain assumptions for the functionality of automation systems and organization of the operators. The main assumptions are that for automation, it needs to have a deterministic performance and can be trusted to control ship functions without human supervision, under specified constraints. For operators, they need to be alerted to take over control sufficiently early enough to regain situational awareness before actions are required. The organization of the operators must also provide a deterministic worst case response time for the operator from being alerted to be able to safely take actions.Given these assumptions, this document provides guidance on how the specifications can be created effectively and in a standardized way. The reason for using standards in system descriptions is for ease of understanding between the different parties to MASS operations, system operator, ship owner, system designer, authorities and class societies.


name: iso-awi-25934
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.780891+00:00
source: iso
source_id: ISO/AWI 25934
source_url: https://www.iso.org/standard/ISO%2FAWI%2025934.html
doc_status: 2000
title:
  ISO/AWI 25934: Ships and marine technology — Guidelines for the development of verification procedures for autonomous navigation systems

abstract:
  This document specifies a structured process for the development of verification procedures for autonomous navigation systems used in Maritime Autonomous Surface Ships (MASS), in accordance with ISO standards related to safety and system reliability assessment. The procedure is intended to ensure the systematic verification of safety and reliability of the constituent systems of MASS, with particular attention to the safe navigation system. The guidelines apply to various modes of operation of MASS and are intended to support manufacturers, ship operators, and regulatory authorities in formulating verification procedures adapted to MASS specific operational requirements.


name: iso-iec-cd-30147
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.784422+00:00
source: iso
source_id: ISO/IEC CD 30147
source_url: https://www.iso.org/standard/ISO%2FIEC%20CD%2030147.html
doc_status: 3000
title:
  ISO/IEC CD 30147: Information technology — Internet of Things (IoT) - Integration of IoT trustworthiness activities in ISO/IEC/IEEE 15288 system engineering processes

abstract:
  ISO/IEC standard: Information technology — Internet of Things (IoT) - Integration of IoT trustworthiness activities in ISO/IEC/IEEE 15288 system engineering processes. Committee: ISO/IEC JTC 1/SC 41.


name: iso-awi-tr-19182
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.787760+00:00
source: iso
source_id: ISO/AWI TR 19182
source_url: https://www.iso.org/standard/ISO%2FAWI%20TR%2019182.html
doc_status: 2000
title:
  ISO/AWI TR 19182: Geographic information — How to incorporate Geospatial Artificial Intelligence (GeoAI) in geographic information standards

abstract:
  ISO/IEC standard: Geographic information — How to incorporate Geospatial Artificial Intelligence (GeoAI) in geographic information standards. Committee: ISO/TC 211.


name: iso-iec-awi-23888-5
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.790754+00:00
source: iso
source_id: ISO/IEC AWI 23888-5
source_url: https://www.iso.org/standard/ISO%2FIEC%20AWI%2023888-5.html
doc_status: 2000
title:
  ISO/IEC AWI 23888-5: Information technology — Artificial intelligence for multimedia — Part 5: AI-based dynamic point cloud compression

abstract:
  This project will define bitstream syntax and semantics of encoded point clouds, and decoding procedure to reconstruct point clouds.


name: iso-iec-awi-23888-4
rev: 00
title: ISO/IEC AWI 23888-4: Artificial intelligence for multimedia — Part 4: Feature coding for machines
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.793521+00:00
source: iso
source_id: ISO/IEC AWI 23888-4
source_url: https://www.iso.org/standard/ISO%2FIEC%20AWI%2023888-4.html
doc_status: 2000
abstract:
  This project will define a bitstream format and decoding process for compression of features extracted from video that is efficient in terms of bitrate, performance of machine tasks and computational complexity.


name: iso-iec-awi-26090-1
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.796424+00:00
source: iso
source_id: ISO/IEC AWI 26090-1
source_url: https://www.iso.org/standard/ISO%2FIEC%20AWI%2026090-1.html
doc_status: 2000
title:
  ISO/IEC AWI 26090-1: Information technology — City Knowledge trustworthiness evaluation — Part 1: Overview and concepts

abstract:
  This document provides an overview of city knowledge trustworthiness and its evaluation in the context of smart cities, including the following: concepts relevant to city knowledge trustworthiness and its evaluation; characteristics of trustworthiness of city knowledge; and methodology for the evaluation of city knowledge trustworthiness.This document also provides some use cases for city knowledge use in smart cities and some cases for city knowledge trustworthiness evaluation.


name: iso-iec-awi-26160
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.799485+00:00
source: iso
source_id: ISO/IEC AWI 26160
source_url: https://www.iso.org/standard/ISO%2FIEC%20AWI%2026160.html
doc_status: 2000
title:
  ISO/IEC AWI 26160: Information security, cybersecurity and privacy protection — Enhancing the ISO/IEC 15408 series and ISO/IEC 18045 for the Evaluation of Artificial Intelligence (AI) Functionality

abstract:
  This document provides:•	AI-specific application notes for relevant security assurance requirements (SARs) from ISO/IEC 15408-3 (CC Part 3), and•	AI-specific application notes for relevant work units (WUs) from ISO/IEC 18045 (CEM) presented as defined in ISO/IEC 15408-4 (CC Part 4).The document also considers AI-specific security functional requirements (SFRs) in an extended security functional requirement class for AI (based on ISO/IEC 15408-3 (CC Part 2)).


name: iso-iec-pwi-26200
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.802754+00:00
source: iso
source_id: ISO/IEC PWI 26200
source_url: https://www.iso.org/standard/ISO%2FIEC%20PWI%2026200.html
doc_status: 60
title:
  ISO/IEC PWI 26200: Standard Framework for Evaluation, Ethical Use, and Interoperability of Large Language Models (LLMs) in AI Systems

abstract:
  This proposal aims to establish an international standard for the evaluation, ethical governance, and interoperability of Large Language Models (LLMs) in AI systems. The standard will define testing methodologies, performance assessment criteria, bias mitigation strategies, risk management protocols, and best practices for responsible deployment. It will also outline security considerations, industry-specific applications, and regulatory alignment to ensure the safe and effective integration of LLMs across various domains, including healthcare, finance, education, and public services.This standard does not address the evaluation of non-language AI models or proprietary language models, and the focus is on open, general-purpose LLMs and their integration into AI systems.


name: iso-np-ts-25280-1
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.806167+00:00
source: iso
source_id: ISO/NP TS 25280-1
source_url: https://www.iso.org/standard/ISO%2FNP%20TS%2025280-1.html
doc_status: 1060
title:
  ISO/NP TS 25280-1: Information and documentation — Records management and Artificial Intelligence — Principles and Considerations — — Part 1: Part 1: Records management in artificial intelligence enabled environment

abstract:
  This document provides principles and outlines consideration for records management in support of AI-enabled business, covering both AI-generated and AI-associated records.Note: This document is applicable to records management for artificial intelligence in all types of organizations.


name: iso-np-ts-25280-2
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.809476+00:00
source: iso
source_id: ISO/NP TS 25280-2
source_url: https://www.iso.org/standard/ISO%2FNP%20TS%2025280-2.html
doc_status: 1060
title:
  ISO/NP TS 25280-2: Information and documentation — Records management and Artificial Intelligence — Principles and Considerations — — Part 2: Part 2: Application of artificial intelligence capabilities for records management

abstract:
  This document provides principles and outlines considerations for applying AI to records controls, records processes, as well as records and archives systems.Note: This document is applicable to artificial intelligence for records management in all types of organizations.


name: iso-awi-26253
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.813274+00:00
source: iso
source_id: ISO/AWI 26253
source_url: https://www.iso.org/standard/ISO%2FAWI%2026253.html
doc_status: 2000
title:
  ISO/AWI 26253: Guidelines for establishing a centralized control system for hospital’s internal pharmaceutical logistics using autonomous mobile robots

abstract:
  This document offers guidelines for the management of Healthcare Organizations, inclusive of healthcare suppliers and manufacturers of Autonomous Mobile Robots (AMRs). It is applicable when these organizations implement internal logistics in hospitals using AMRs. The document delineates the fundamental guidelines for the establishment and the operation of a Centralized Control System (CCS) required for AMR operation. It includes the key components necessary to ensure the safe and reliable logistics of pharmaceuticals within the hospital. The document encompasses the roles of the CCS in a unexpected functional failure response procedures, real-time monitoring information, managing hardware operation, communication targets, schedule management and task allocation, as well as record-keeping.


name: iso-iec-22989-2022-awi-amd-2
rev: 00
time: 2022/AWI Amd 2
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.816570+00:00
source: iso
source_id: ISO/IEC 22989:2022/AWI Amd 2
source_url: https://www.iso.org/standard/ISO%2FIEC%2022989.html
doc_status: 2000
title:
  ISO/IEC 22989:2022/AWI Amd 2: Information technology — Artificial intelligence — Artificial intelligence concepts and terminology — Amendment 2

abstract:
  ISO/IEC standard: Information technology — Artificial intelligence — Artificial intelligence concepts and terminology — Amendment 2. Committee: ISO/IEC JTC 1/SC 42.


name: iso-iec-23053-2022-awi-amd-2
rev: 00
time: 2022/AWI Amd 2
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.819721+00:00
source: iso
source_id: ISO/IEC 23053:2022/AWI Amd 2
source_url: https://www.iso.org/standard/ISO%2FIEC%2023053.html
doc_status: 2000
title:
  ISO/IEC 23053:2022/AWI Amd 2: Framework for Artificial Intelligence (AI) Systems Using Machine Learning (ML) — Amendment 2

abstract:
  ISO/IEC standard: Framework for Artificial Intelligence (AI) Systems Using Machine Learning (ML) — Amendment 2. Committee: ISO/IEC JTC 1/SC 42.


name: iso-iec-np-ts-26312
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.822740+00:00
source: iso
source_id: ISO/IEC NP TS 26312
source_url: https://www.iso.org/standard/ISO%2FIEC%20NP%20TS%2026312.html
doc_status: 1020
title:
  ISO/IEC NP TS 26312: Information technology — Artificial intelligence — Identification and treatment of bias in AI by healthcare organizations

abstract:
  This document describes how to identify and address bias in AI systems for health serviceorganizations during procurement, implementation, and monitoring of these systems used to supportthe delivery and allocation of care and preventative services. This includes both clinician-facing, andpatient-facing AI applications provided to patients by their healthcare organization.This document is focused on bias in AI models, specifically models that exhibit decreasedaccuracy or cause differential impact that may unfairly disadvantage certain demographicgroups (also referred to as “protected classes” in some jurisdictions). This includesalgorithmic bias, data representation bias, labelling bias, and deployment-related bias. Thisdocument takes a broad view of bias, acknowledging that unfairness in AI outcomes mayarise from a variety of technical and non-technical sources throughout the AI systemlifecycle.This document is applicable to all types and sizes of health service organizations (e.g.hospitals, laboratories, pharmacies, community radiology clinics, and primary or ambulatorycare services), and stakeholders involved in regulating AI use within health serviceorganizations.This document does not consider AI system development or manufacturing processes, asthese are expected to be addressed in separate standards (noting that some health serviceorganizations may be directly involved in the development or manufacture of AI systems).Similarly, the document does not cover personal bias that may be exhibited by end users ofAI systems (e.g. cognitive or automation bias).


name: iso-iec-np-ts-26320.2
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.826102+00:00
source: iso
source_id: ISO/IEC NP TS 26320.2
source_url: https://www.iso.org/standard/ISO%2FIEC%20NP%20TS%2026320.2.html
doc_status: 1060
title:
  ISO/IEC NP TS 26320.2: Artificial intelligence — Corpus development and maintenance for natural language processing systems

abstract:
  This document establishes principles, frameworks and methods for developing and maintaining corpora that are used for natural language processing (NLP) systems. It includes requirements and recommendations for corpus construction and application, and provides guidance and measures for quality evaluation of corpora used for NLP systems.This document is applicable for all organizations involved in any stage of an AI system life cycle.


name: iso-cd-19178-2
rev: 00
title: ISO/CD 19178-2: Training data markup language for artificial intelligence — Part 2: JSON encoding
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.829210+00:00
source: iso
source_id: ISO/CD 19178-2
source_url: https://www.iso.org/standard/ISO%2FCD%2019178-2.html
doc_status: 3099
abstract:
  ISO/IEC standard: Training data markup language for artificial intelligence — Part 2: JSON encoding. Committee: ISO/TC 211.


name: iso-cd-19178-3
rev: 00
title: ISO/CD 19178-3: Training data markup language for artificial intelligence — Part 3: XML encoding
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.832427+00:00
source: iso
source_id: ISO/CD 19178-3
source_url: https://www.iso.org/standard/ISO%2FCD%2019178-3.html
doc_status: 3099
abstract:
  ISO/IEC standard: Training data markup language for artificial intelligence — Part 3: XML encoding. Committee: ISO/TC 211.


name: iso-iec-np-26582
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.835564+00:00
source: iso
source_id: ISO/IEC NP 26582
source_url: https://www.iso.org/standard/ISO%2FIEC%20NP%2026582.html
doc_status: 1020
title:
  ISO/IEC NP 26582: Artificial intelligence — Conformity assessment for the functional correctness of an AI system

abstract:
  This document specifies requirements and guidance for the conformity assessment of the functional correctness of an AI system based on the quality models for AI systems provided by ISO/IEC 25059.This document is applicable for all types of AI systems.


name: iso-np-26604-1
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.838398+00:00
source: iso
source_id: ISO/NP 26604-1
source_url: https://www.iso.org/standard/ISO%2FNP%2026604-1.html
doc_status: 1020
title:
  ISO/NP 26604-1: Agricultural machinery and tractors — Safety of autonomous machinery — Part 1: Soil-Working Machinery

abstract:
  This document specifies the safety requirements and the means of verification for the design and construction of agricultural machinery and tractors and their use with the intended implements, interchangeable equipment and tools that operate autonomously (autonomous machinery (see 3.1) / autonomous operation (see 3.2)) in agricultural soil-working applications (soil-working machinery). Additionally, it provides guidance on the type of information to be provided by the manufacturer on safe working practices (including information about residual risks).  Soil-working applications include (but not limited to):  tilling (e.g. plowing, soil conditioning); mechanical weeding; land levelling; Etc. Agriculture includes (but not limited to):  row crop fields; orchards; vineyards; greenhouses; Etc. This document deals with significant hazards, hazardous situations and events, as listed in Annex C, relevant to this autonomous machinery when used as intended and under the conditions of misuse reasonably foreseeable by the manufacturer during normal operation and service.  NOTE 1		Safety requirements for specific non-automated and partially automated functions of agricultural machinery and tractors, as well as machine-specific components (e.g. working tools), can be available in machine-specific type-C standards. This document is not applicable to: forestry applications; operations on public roads including relevant requirements for braking and steering systems; environmental hazards; pedestrian controlled2 machinery; machinery requiring or allowing the option for a local operator in a local operator station to provide manual non-automated or partially automated functions or operations to complete a soil-working cycle of work in autonomous operation; application of crop or soil products; application of crop or soil products in combination with soil-working. The use of partially or fully self-evolving behavior or logic with varying levels of autonomy in the design and constructio


name: iso-np-26609
rev: 00
abstract: This document sets requirements for assessing AI and AuI systems used with 2D radiographs.
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.841731+00:00
source: iso
source_id: ISO/NP 26609
source_url: https://www.iso.org/standard/ISO%2FNP%2026609.html
doc_status: 1020
title:
  ISO/NP 26609: Dentistry — Requirements for Assessing 2D Dental Radiography Artificial Intelligence (AI) and Augmented Intelligence (AuI) Analysis Applications


name: iso-np-pas-8800-1
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.845024+00:00
source: iso
source_id: ISO/NP PAS 8800-1
source_url: https://www.iso.org/standard/ISO%2FNP%20PAS%208800-1.html
doc_status: 1000
title:
  ISO/NP PAS 8800-1: Road vehicles — Safety and artificial intelligence — Part 1: Definitions and concepts

abstract:
  ISO/IEC standard: Road vehicles — Safety and artificial intelligence — Part 1: Definitions and concepts. Committee: ISO/TC 22.


name: iso-np-pas-8800-2
rev: 00
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:31.848269+00:00
source: iso
source_id: ISO/NP PAS 8800-2
source_url: https://www.iso.org/standard/ISO%2FNP%20PAS%208800-2.html
doc_status: 1000
title:
  ISO/NP PAS 8800-2: Road vehicles — Safety and artificial intelligence — Part 2: General requirements

abstract:
  <p class='MsoBodyText'><span lang='EN-GB'>This document applies to safety-related systems that include one or more electrical and/or electronic (E/E) systems that use AI technology and that is installed in series production road vehicles, excluding mopeds. It does not address unique E/E systems in special vehicles, such as E/E systems designed for drivers with disabilities.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document addresses the risk of undesired safety-related behaviour at the vehicle level due to output insufficiencies, systematic errors and random hardware errors of AI elements within the vehicle. This includes interactions with AI elements that are not part of the vehicle itself but that can have a direct or indirect impact on vehicle safety.</span></p><p class='Example'><span lang='EN-GB'>EXAMPLE 1<span style='mso-tab-count: 1;'>         </span>Examples of AI elements within the vehicle include the trained AI model and AI system.</span></p><p class='Example'><span lang='EN-GB'>EXAMPLE 2<span style='mso-tab-count: 1;'>         </span>Direct impact on safety can be due to object detection by elements external to the vehicle.</span></p><p class='Example'><span lang='EN-GB'>EXAMPLE 3<span style='mso-tab-count: 1;'>         </span>Indirect impact on safety can be due to field monitoring by elements external to the vehicle.</span></p><p class='MsoBodyText'><span lang='EN-GB'>The development of AI elements that are not part of the vehicle is not within the scope of this document. These elements can conform to domain-specific safety guidance. This document can be used as a reference where such domain-specific guidance does not exist.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document describes safety-related properties of AI systems that can be used to construct a convincing safety assurance claim for the absence of unreasonable risk.</span></p><p class='MsoBodyText'><span lang='EN-GB'>This document does not provide specific guide


name: nist-ai-100-1
rev: 00
title: NIST AI 100-1: Artificial Intelligence Risk Management Framework (AI RMF 1.0)
time: 2023-01-26
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:35.855438+00:00
source: nist
source_id: AI 100-1
source_url: https://csrc.nist.gov/pubs/ai/100/1/final
doc_status: final
abstract:
  The AI RMF provides a framework for managing risks associated with AI systems throughout their lifecycle, addressing characteristics of trustworthy AI including validity, reliability, safety, security, resilience, accountability, transparency, explainability, interpretability, privacy, and fairness.


name: nist-ai-100-2-e2025
rev: 00
time: 2025-03-24
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:35.869813+00:00
source: nist
source_id: AI 100-2 E2025
source_url: https://csrc.nist.gov/pubs/ai/100/2/e2025/final
doc_status: final
title:
  NIST AI 100-2 E2025: Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations

abstract:
  Establishes a taxonomy of adversarial machine learning attacks and mitigations, covering evasion, poisoning, and privacy attacks against predictive AI and generative AI systems including LLMs.


name: nist-ai-100-4
rev: 00
title: NIST AI 100-4: Reducing Risks Posed by Synthetic Content
time: 2024-07-26
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:35.874109+00:00
source: nist
source_id: AI 100-4
source_url: https://csrc.nist.gov/pubs/ai/100/4/final
doc_status: final
abstract:
  Provides guidance on approaches to manage risks from synthetic content generated by AI, including authentication, provenance tracking, and content labeling.


name: nist-ai-600-1
rev: 00
title: NIST AI 600-1: Artificial Intelligence Risk Management Framework: Generative AI Profile
time: 2024-07-26
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:35.877875+00:00
source: nist
source_id: AI 600-1
source_url: https://csrc.nist.gov/pubs/ai/600/1/final
doc_status: final
abstract:
  Companion resource for the AI RMF focusing on risks unique to or exacerbated by generative AI, covering hallucinations, data privacy, intellectual property, and CBRN information risks.


name: nist-sp-800-218a
rev: 00
time: 2024-07-26
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:35.882397+00:00
source: nist
source_id: SP 800-218A
source_url: https://csrc.nist.gov/pubs/sp/800/218/a/final
doc_status: final
title:
  NIST SP 800-218A: Secure Software Development Practices for Generative AI and Dual-Use Foundation Models

abstract:
  An SSDF community profile providing secure software development practices specific to generative AI and dual-use foundation models, addressing data management, model training, and deployment security.


name: nist-ir-8596
rev: 00
title: NIST IR 8596: Cybersecurity Framework Profile for Artificial Intelligence
time: 2025-12-16
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:35.885887+00:00
source: nist
source_id: IR 8596
source_url: https://csrc.nist.gov/pubs/ir/8596/ipd
doc_status: draft
abstract:
  A community profile mapping NIST Cybersecurity Framework functions to AI-specific risks and controls, helping organizations manage cybersecurity risks in AI systems.


name: nist-cswp-31
rev: 00
title: NIST CSWP 31: Proxy Validation and Verification for Critical AI Systems
time: 2024-09-26
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:35.889563+00:00
source: nist
source_id: CSWP 31
source_url: https://csrc.nist.gov/pubs/cswp/31/final
doc_status: final
abstract:
  Describes a proxy design process for validation and verification of critical AI systems, addressing challenges of testing AI systems that are complex and opaque.


name: nist-ir-8579
rev: 00
title: NIST IR 8579: Developing the NCCoE Chatbot: Technical and Security Learnings
time: 2025-07-31
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:35.893622+00:00
source: nist
source_id: IR 8579
source_url: https://csrc.nist.gov/pubs/ir/8579/ipd
doc_status: draft
abstract:
  Documents technical and security lessons from implementing an LLM-based chatbot at the National Cybersecurity Center of Excellence, including prompt injection mitigations.


name: nist-nist-ai-agent-iam
rev: 00
time: 2026-02-05
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:35.897582+00:00
source: nist
source_id: NIST-AI-Agent-IAM
doc_status: draft
title:
  NIST NIST-AI-Agent-IAM: Accelerating the Adoption of Software and AI Agent Identity and Authorization

abstract:
  Concept paper on identity and authorization for AI agents, addressing how software agents authenticate, authorize, and maintain accountability in automated systems.

source_url:
  https://csrc.nist.gov/publications/detail/other/2026/02/05/accelerating-the-adoption-of-software-and-artificial-intelligence-agent-identity-and-authorization/draft


name: nist-ai-100-6
rev: 00
title: NIST AI 100-6: AI Measurement and Evaluation
time: 2024-04-29
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:35.901608+00:00
source: nist
source_id: AI 100-6
source_url: https://csrc.nist.gov/pubs/ai/100/6/final
doc_status: final
abstract:
  Guidance on measurement and evaluation approaches for AI systems to assess trustworthiness characteristics including accuracy, fairness, robustness, and security.


name: nist-ai-100-1-playbook
rev: 00
title: NIST AI 100-1 Playbook: AI RMF Playbook
time: 2023-01-26
states: []
categories: []
tags: []
fetched_at: 2026-03-08T17:36:35.905438+00:00
source: nist
source_id: AI 100-1 Playbook
source_url: https://airc.nist.gov/AI_RMF_Playbook
doc_status: final
abstract:
  Practical companion to the AI RMF providing suggested actions for achieving AI risk management outcomes, organized by the framework's functions: Govern, Map, Measure, and Manage.


name: draft-li-rtgwg-distributed-lossless-framework
rev: 00
title: Framework of Distributed AIDC Network
time: 2025-04-24T07:05:48Z
group_uri: /api/v1/group/group/1027/
expires: 2025-04-24T13:15:14Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:46.185224+00:00
source: ietf
source_id: 139886
source_url: https://datatracker.ietf.org/doc/draft-li-rtgwg-distributed-lossless-framework/
doc_status: active
abstract:
  With the rapid development of large language models, it puts forward
     higher requirements for the networking scale of data centers.
     Distributed model training has been proposed to shorten the training
     time and relieve the resource demand in a single data center.This
     document proposes a framework to address the challenge of efficient
     lossless interconnection and reliable data transmission between
     multiple data centers, which can connect multiple data centers to
     form a larger cluster through network connection.  The document
     further conducts in-depth research on the key technologies and
     application scenarios of this distributed AIDC network.


name: draft-voit-rats-trustworthy-path-routing
rev: 12
title: Trusted Path Routing
time: 2026-01-09T07:09:03Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-08T15:06:07Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:46.198949+00:00
source: ietf
source_id: 96900
source_url: https://datatracker.ietf.org/doc/draft-voit-rats-trustworthy-path-routing/
doc_status: active
abstract:
  There are end-users who believe encryption technologies like IPSec
     alone are insufficient to protect the confidentiality of their highly
     sensitive traffic flows.  These end-users want their flows to
     traverse devices which have been freshly appraised and verified for
     trustworthiness.  This specification describes Trusted Path Routing.
     Trusted Path Routing protects sensitive flows as they transit a
     network by forwarding traffic to/from sensitive subnets across
     network devices recently appraised as trustworthy.


name: draft-toorop-dnsop-ranking-dns-data
rev: 00
title: Ranking Domain Name System data
time: 2024-09-05T07:06:28Z
group_uri: /api/v1/group/group/1027/
expires: 2024-09-05T21:12:25Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:46.206933+00:00
source: ietf
source_id: 133931
source_url: https://datatracker.ietf.org/doc/draft-toorop-dnsop-ranking-dns-data/
doc_status: active
abstract:
  This document extends the list ranking the trustworthiness of domain
     name system (DNS) data (see Section 5.4.1 of [RFC2181]).  The list is
     extended with entries for root server names and addresses built-in
     resolvers, and provided via a root hints file with the lowest
     trustworthiness, as wel as an entry for data which is verifiable
     DNSSEC secure with the highest trustworthiness.  This document
     furthermore assigns ranked values to the positions of the list for
     easier reference and comparison of trustworthiness of DNS data.


name: draft-sandowicz-httpbis-httpa2
rev: 03
title: The Hypertext Transfer Protocol Attestable (HTTPA) Version 2
time: 2024-05-07T07:05:01Z
group_uri: /api/v1/group/group/1027/
expires: 2024-05-08T02:04:50Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:46.210443+00:00
source: ietf
source_id: 110746
source_url: https://datatracker.ietf.org/doc/draft-sandowicz-httpbis-httpa2/
doc_status: active
abstract:
  The Hypertext Transfer Protocol Attestable version 2 (HTTPA/2) is an
     HTTP extension.  It is a transaction-based protocol agnostic to
     Transport Layer Security (TLS) in which the Trusted Execution
     Environment (TEE) is considered a new type of requested resource over
     the Internet.  The original Hypertext Transfer Protocol Attestable
     (HTTPA) (referred to as HTTPA/1 in the rest of the document) includes
     remote attestation (RA) process onto the HTTPS protocol in the
     assumption of using Transport Layer Security (TLS) across the
     Internet.  In contrast, the design of HTTPA/2 could establish a
     trusted (attested) and more secure communication without dependence
     on TLS.

     The definition of Attestation for the purposes of this draft:

     The process of vouching for the accuracy of TEE based services,
     configuration, and data where the TEE conveys Evidence about its
     environment, roots of trust and protected functions.  The Evidence is
     a digital expression of TEE trustworthiness.


name: draft-chen-secure-routing-use-cases
rev: 03
title: The Use Cases for Secure Routing Path
time: 2024-05-18T07:05:01Z
group_uri: /api/v1/group/group/1027/
expires: 2024-05-19T03:43:22Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:46.223128+00:00
source: ietf
source_id: 114460
source_url: https://datatracker.ietf.org/doc/draft-chen-secure-routing-use-cases/
doc_status: active
abstract:
  Current routing mechanism is based on the shortest path, which only
     take the link status and the path accessibility into consideration,
     without the security and trustworthiness of links and forwarding
     nodes.  As security has become an important factor to the user.  This
     paper proposes to add security factor in the routing process.

     With the frequent occurrence of security incidents, services security
     is an essential demand for the users.  As there are many security
     devices in the ISP's network, this draft proposes secure routing
     mechanism.  The purpose of secure routing is to converge security and
     routing to ensure the secure data transmission.

     The scope is transmission process security, while end-to-end security
     and application layer security are out of scope.


name: draft-howe-vcon-agent-session
rev: 00
title: vCon Agent Session
time: 2026-05-20T20:14:16Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-21T20:14:16Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Data formats/interop", "Human-agent interaction", "Policy/governance"]
tags: []
fetched_at: 2026-05-22T09:24:40.604081+00:00
source: ietf
abstract:
  This document defines an "agent_session" extension for Virtualized
     Conversations (vCon) that profiles the use of vCon parties, dialog,
     analysis, and attachments to carry the record of an autonomous AI
     agent's internal session - its prompts, tool invocations, tool
     results, reasoning, and file or artifact provenance - alongside the
     human-facing conversation that the agent participated in or acted
     upon.

     The extension is a Compatible vCon extension.  It introduces no new
     top-level fields and does not alter the semantics of existing ones.
     Instead, it specifies (a) how an autonomous agent is represented as a
     vCon party, (b) how agent message turns are placed in the dialog
     array, (c) how the internal agent trace (tool calls, results,
     reasoning, system events) is carried as a structured analysis entry
     whose body conforms to the Verifiable Agent Conversations (VAC) CDDL
     schema [I-D.draft-birkholz-verifiable-agent-conversations], and (d)
     how files and artifacts modified by the agent are carried as
     attachments.

     By projecting agent-session data into the vCon model, implementations
     inherit vCon's party/identity model, the lawful basis framework
     [I-D.draft-howe-vcon-lawful-basis], the lifecycle and redaction
     machinery [I-D.draft-howe-vcon-lifecycle], and JWS-based signing,
     without re-specifying any of those concerns.

full_text:
  vCon                                                    T. McCarthy-Howe
  Internet-Draft                                                    VCONIC
  Intended status: Standards Track                             20 May 2026
  Expires: 21 November 2026


                             vCon Agent Session
                      draft-howe-vcon-agent-session-00

  Abstract

     This document defines an "agent_session" extension for Virtualized
     Conversations (vCon) that profiles the use of vCon parties, dialog,
     analysis, and attachments to carry the record of an autonomous AI
     agent's internal session - its prompts, tool invocations, tool
     results, reasoning, and file or artifact provenance - alongside the
     human-facing conversation that the agent participated in or acted
     upon.

     The extension is a Compatible vCon extension.  It introduces no new
     top-level fields and does not alter the semantics of existing ones.
     Instead, it specifies (a) how an autonomous agent is represented as a
     vCon party, (b) how agent message turns are placed in the dialog
     array, (c) how the internal agent trace (tool calls, results,
     reasoning, system events) is carried as a structured analysis entry
     whose body conforms to the Verifiable Agent Conversations (VAC) CDDL
     schema [I-D.draft-birkholz-verifiable-agent-conversations], and (d)
     how files and artifacts modified by the agent are carried as
     attachments.

     By projecting agent-session data into the vCon model, implementations
     inherit vCon's party/identity model, the lawful basis framework
     [I-D.draft-howe-vcon-lawful-basis], the lifecycle and redaction
     machinery [I-D.draft-howe-vcon-lifecycle], and JWS-based signing,
     without re-specifying any of those concerns.

  About This Document

     This note is to be removed before publishing as an RFC.

     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-howe-vcon-agent-session/.

     Discussion of this document takes place on the vCon Working Group
     mailing list (mailto:vcon@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/vcon/.  Subscribe at
     https://www.ietf.org/mailman/listinfo/vcon/.




  McCarthy-Howe           Expires 21 November 2026                [Page 1]


  Internet-Draft             vCon Agent Session                   May 2026


     Source for this draft and an issue tracker can be found at
     https://github.com/vcon-dev/draft-howe-vcon-agent-session.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 21 November 2026.

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
       2.1.  Core Terms  . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Extension Classification and Registration . . . . . . . . . .   4
     4.  Representing the Agent as a Party . . . . . . . . . . . . . .   5
     5.  Representing Agent Dialog Turns . . . . . . . . . . . . . . .   6
     6.  Representing the Internal Agent Trace . . . . . . . . . . . .   7
       6.1.  Analysis Entry Shape  . . . . . . . . . . . . . . . . . .   7
       6.2.  Granularity Variants  . . . . . . . . . . . . . . . . . .   7
       6.3.  CBOR Encoding (Optional)  . . . . . . . . . . . . . . . .   8
     7.  Representing File and Artifact Provenance . . . . . . . . . .   8
       7.1.  Purpose Registry  . . . . . . . . . . . . . . . . . . . .   9



  McCarthy-Howe           Expires 21 November 2026                [Page 2]


  Internet-Draft             vCon Agent Session                   May 2026


     8.  Signing, Transparency, and SCITT Integration  . . . . . . . .   9
     9.  Lawful Basis and Consent  . . . . . . . . . . . . . . . . . .   9
     10. Lifecycle, Redaction, and Reasoning Encryption  . . . . . . .  10
     11. Security Considerations . . . . . . . . . . . . . . . . . . .  10
     12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
       13.1.  Normative References . . . . . . . . . . . . . . . . . .  11
       13.2.  Informative References . . . . . . . . . . . . . . . . .  12
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  12
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13

  1.  Introduction

     Autonomous AI agents now read, write, and act on conversations
     involving human participants.  Two categories of evidentiary record
     are typically required:

     1.  The conversation between people (and between people and the
         agent), captured today by vCon [I-D.draft-ietf-vcon-vcon-core]
         (see also [I-D.draft-ietf-vcon-overview] for background).

     2.  The agent's internal session - the prompts it received, the tools
         it invoked, the results it observed, the chains of reasoning it
         produced, and the files or external systems it modified -
         captured by Verifiable Agent Conversations (VAC)
         [I-D.draft-birkholz-verifiable-agent-conversations].

     These two records have substantial overlap (parties, turns,
     artifacts, provenance, signing) and substantial complementarity (vCon
     has a rich party and consent model; VAC has a rich tool-call and
     reasoning model).  Maintaining them as fully independent containers
     forces every implementer to invent linkage, duplicate identity, and
     re-solve consent.

     This document defines a Compatible vCon extension (Section 2.5 of
     [I-D.draft-ietf-vcon-vcon-core]) that allows a single vCon to carry
     both records together: the human-facing conversation in the usual
     vCon shape, and the agent's internal session as structured analysis
     and attachment entries whose bodies conform to the VAC schema.

     Regulatory drivers include the [EU-AI-ACT], the [NIST-AI-RMF], and
     sectoral regimes (HIPAA, PCI DSS, ISO 42001) that require auditable,
     non-repudiable records of automated decision-making.








  McCarthy-Howe           Expires 21 November 2026                [Page 3]


  Internet-Draft             vCon Agent Session                   May 2026


  2.  Conventions and Definitions

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

     All timestamps in vCon documents conforming to this extension are
     formatted as Internet date and time strings per [RFC3339], matching
     the requirement in [I-D.draft-ietf-vcon-vcon-core].

  2.1.  Core Terms

     *Agent*: An autonomous software system, typically backed by a large
     language model, that produces messages, invokes tools, and/or
     modifies external state in response to instructions.

     *Agent Session*: A single bounded run of an agent, with a defined
     start and end, identified by a session identifier.

     *Agent Party*: A vCon parties[] entry of role "agent" that identifies
     an agent participating in the conversation.

     *Agent Trace*: The ordered, possibly tree-structured set of internal
     entries produced during an agent session - tool calls, tool results,
     reasoning, and system events.  Distinct from the agent's outward-
     facing dialog turns.

     *VAC Record*: A verifiable-agent-record as defined in
     [I-D.draft-birkholz-verifiable-agent-conversations], or its
     projection into JSON for use as an analysis body.

     *Compatible Extension*: A vCon extension that introduces additional
     data without altering the meaning or structure of existing elements,
     as defined in [I-D.draft-ietf-vcon-vcon-core].

  3.  Extension Classification and Registration

     The agent session extension is a *Compatible Extension* as defined in
     Section 2.5 of [I-D.draft-ietf-vcon-vcon-core].  It:

     *  Introduces no new top-level fields.

     *  Defines new values for the role field of a party, the purpose
        field of an attachment, and the type field of an analysis entry.





  McCarthy-Howe           Expires 21 November 2026                [Page 4]


  Internet-Draft             vCon Agent Session                   May 2026


     *  Can be safely ignored by implementations that do not support agent
        session processing; the vCon remains a well-formed conversation
        record.

     *  Does not require listing in the critical parameter unless the
        application requires that consumers honor agent session semantics
        (e.g. for redaction or replay).

     This document defines the "agent_session" extension token for
     registration in the vCon Extensions Names Registry:

     *  *Extension Name*: agent_session

     *  *Extension Description*: Representation of an autonomous AI
        agent's internal session (tool calls, reasoning, file provenance)
        within a vCon conversation record.

     *  *Change Controller*: IESG

     *  *Specification Document*: This document

     vCon instances that include agent session data SHOULD include
     "agent_session" in the extensions array.  They SHOULD include
     "agent_session" in critical if downstream consumers MUST process the
     agent trace (for example, when the only record of an authorizing tool
     call lives there).

  4.  Representing the Agent as a Party

     Each distinct agent that participated in the conversation MUST be
     represented as a single entry in the vCon parties[] array, with role
     set to "agent".  The party entry MAY include a meta object containing
     an agent_session member that captures the agent's identity:


















  McCarthy-Howe           Expires 21 November 2026                [Page 5]


  Internet-Draft             vCon Agent Session                   May 2026


     {
       "name": "Claude Opus 4.6",
       "role": "agent",
       "validation": "system",
       "meta": {
         "agent_session": {
           "model_id": "claude-opus-4-6",
           "provider": "anthropic",
           "recording_agent": "claude-code/1.2.0",
           "environment": {
             "cwd": "/Users/example/project",
             "vcs_branch": "main",
             "vcs_commit": "abc123def456"
           }
         }
       }
     }

     Fields under parties[i].meta.agent_session:

     *  *model_id* (string, REQUIRED): Vendor identifier for the model.

     *  *provider* (string, REQUIRED): Organization providing the model
        (e.g. "anthropic", "openai", "google").

     *  *recording_agent* (string, RECOMMENDED): The harness, IDE, or CLI
        that recorded the session (e.g. "claude-code/1.2.0").

     *  *environment* (object, OPTIONAL): Runtime environment context.
        When the session edited a source repository, vcs_branch and
        vcs_commit SHOULD be set.

     When multiple agents (e.g. orchestrator + sub-agent) participated,
     each MUST appear as a distinct party.  Dialog and analysis entries
     reference them by index in the usual vCon way.

  5.  Representing Agent Dialog Turns

     User prompts and assistant replies (the externally-visible side of
     the agent session - what a person would read in a transcript) are
     ordinary vCon dialog[] entries.  The user is one party; the agent is
     another.  No new dialog type is required.

     When an agent reply is generated by a single agent in response to a
     single prompt, the dialog entry's parties field MUST reference the
     agent party.  When the reply was produced by a multi-agent
     collaboration, parties MAY list all contributing agents.




  McCarthy-Howe           Expires 21 November 2026                [Page 6]


  Internet-Draft             vCon Agent Session                   May 2026


  6.  Representing the Internal Agent Trace

     The internal agent trace - tool calls, tool results, reasoning
     entries, and system events - is carried in the vCon analysis[] array.
     A single agent session SHOULD produce one analysis entry spanning all
     of its dialog turns, with the full trace embedded as a JSON-encoded
     VAC record in the body.

  6.1.  Analysis Entry Shape

     {
       "type": "agent_trace",
       "dialog": [0, 1],
       "vendor": "anthropic",
       "product": "claude-opus-4-6",
       "schema": "https://datatracker.ietf.org/doc/...vac.../",
       "encoding": "json",
       "body": "{\"version\":\"1.0\",\"session-trace\":...}"
     }

     The analysis entry MUST set:

     *  *type*: "agent_trace".

     *  *dialog*: Array of dialog indices to which this trace applies.

     *  *vendor*: The model provider (mirrors
        parties[i].meta.agent_session.provider).

     *  *product*: The model identifier (mirrors model_id).

     *  *schema*: The URL of the VAC specification (or a specific version
        thereof), e.g. the canonical datatracker URL for
        [I-D.draft-birkholz-verifiable-agent-conversations].

     *  *encoding*: "json".

     *  *body*: A JSON-encoded verifiable-agent-record per the VAC schema.
        The CDDL-defined structure - session-trace.entries[] with message-
        entry, tool-call-entry, tool-result-entry, reasoning-entry, and
        event-entry variants - is preserved verbatim in the body.  The
        parent-id / children tree relationships are retained.

  6.2.  Granularity Variants

     Implementations MAY choose finer granularity:





  McCarthy-Howe           Expires 21 November 2026                [Page 7]


  Internet-Draft             vCon Agent Session                   May 2026


     *  *Per-tool-call*: one analysis entry per tool invocation, each
        referencing the specific dialog turn it served.  This enables
        fine-grained redaction (e.g. removing a single reasoning entry
        containing PII) using the lifecycle extension
        [I-D.draft-howe-vcon-lifecycle], but produces more analysis
        entries.

     *  *Per-branch*: one analysis entry per sub-agent branch in a multi-
        agent session.

     The whole-session form is RECOMMENDED for archival.  The per-tool-
     call form is RECOMMENDED when granular redaction or selective
     disclosure is anticipated.

  6.3.  CBOR Encoding (Optional)

     When CBOR [RFC8949]-native representation is required (for example,
     for interoperability with COSE [RFC8152]-signed VAC records or SCITT
     transparency services), implementations MAY set encoding to
     "base64url" and place a base64url-encoded CBOR encoding of the VAC
     record in body, with schema qualified by ?encoding=cbor.  Consumers
     MUST examine the schema URL to determine the encoding.

  7.  Representing File and Artifact Provenance

     When an agent modifies files or produces artifacts (a source code
     edit, a generated document, a database row insertion), each such
     change SHOULD be represented as a vCon attachments[] entry with
     purpose set to "agent_file_change" (or a more specific purpose, see
     Section 7.1).

     {
       "purpose": "agent_file_change",
       "party": 1,
       "dialog": 5,
       "encoding": "json",
       "body": {
         "path": "src/foo.py",
         "contributor": "agent",
         "line_range": [10, 25],
         "operation": "edit",
         "commit": "abc123",
         "content_hash": "sha512-..."
       }
     }






  McCarthy-Howe           Expires 21 November 2026                [Page 8]


  Internet-Draft             vCon Agent Session                   May 2026


     The party index MUST identify the agent party that made the change.
     The dialog index SHOULD identify the dialog turn whose tool call
     effected the change (or, if the change is summary-level, the closing
     assistant turn).

     For binary or large file content, the attachment SHOULD use vCon's
     external media pattern (url + content_hash) rather than inlining the
     body.

  7.1.  Purpose Registry

     This document defines initial values for the purpose field of an
     attachment produced by an agent session:

     *  agent_file_change - source file modified by the agent.

     *  agent_artifact - non-file artifact generated by the agent (e.g. a
        database write, an API call payload, a generated document).

     *  agent_environment - snapshot of relevant agent environment state
        (working directory listing, package manifest, etc.).

     Additional purpose values MAY be registered through the usual vCon
     attachment purpose registry process.

  8.  Signing, Transparency, and SCITT Integration

     The agent session extension inherits vCon's signing model: a vCon
     containing agent session data is signed as a whole, using JWS as
     defined in [I-D.draft-ietf-vcon-vcon-core].

     When the agent trace was independently signed and submitted to a
     SCITT transparency service (as defined in
     [I-D.draft-birkholz-verifiable-agent-conversations] Section 9), the
     SCITT receipt and the original COSE_Sign1 envelope MAY be carried as
     additional attachments with purpose set to "scitt_receipt" and
     "agent_trace_cose_sign1" respectively.  Consumers can then
     independently verify the agent trace against both the vCon JWS
     signature and the COSE/SCITT chain.

  9.  Lawful Basis and Consent

     An agent session that processes personal data MUST be governed by a
     documented lawful basis [I-D.draft-howe-vcon-lawful-basis].
     Implementations SHOULD include a lawful_basis attachment that:

     *  Identifies the data subject(s) by party index.




  McCarthy-Howe           Expires 21 November 2026                [Page 9]


  Internet-Draft             vCon Agent Session                   May 2026


     *  Lists purpose_grants covering at minimum: agent_session_recording,
        agent_session_analysis, and (where applicable)
        agent_session_redistribution.

     *  Has expiration set per applicable regulation.

     When the agent session was authorized only under a lawful basis that
     prohibits redistribution, the vCon containing the agent session MUST
     NOT be transmitted to parties outside the scope of that grant.  The
     vCon redacted mechanism and the lifecycle extension
     [I-D.draft-howe-vcon-lifecycle] provide the standard means for
     producing a redacted form for broader distribution.

  10.  Lifecycle, Redaction, and Reasoning Encryption

     Internal reasoning entries (reasoning-entry in the VAC schema)
     frequently contain sensitive intermediate state.  The lifecycle
     extension's redaction mechanism MAY be used to remove or replace
     specific reasoning entries while preserving the rest of the agent
     trace.  The recommended approach is the per-tool-call analysis
     granularity described in Section "Analysis Entry Shape" so that each
     reasoning entry can be addressed individually.

     Where reasoning entries must be retained but kept confidential from
     some recipients, implementations MAY encrypt the analysis body using
     JWE and place the encrypted form in body with encoding set to "jwe".

  11.  Security Considerations

     Carrying an agent's internal trace within a vCon expands the vCon's
     privacy surface.  In particular:

     *  Tool call arguments and tool results frequently contain
        credentials, identifiers, and PII not present in the human-facing
        dialog.  Implementations MUST scrub or redact these before any
        distribution outside the lawful basis grant.

     *  Reasoning entries may reveal internal heuristics that are
        themselves sensitive (e.g. fraud-detection logic).  Such entries
        SHOULD be encrypted or removed before distribution.

     *  The agent's identity, as recorded in
        parties[i].meta.agent_session, is asserted by the recording party
        and is not by itself cryptographic evidence that a particular
        model produced the trace.  Trace authenticity rests on the JWS
        signature over the vCon and, when present, on the COSE/SCITT
        receipt for the embedded VAC record.




  McCarthy-Howe           Expires 21 November 2026               [Page 10]


  Internet-Draft             vCon Agent Session                   May 2026


  12.  IANA Considerations

     This document registers the agent_session extension in the vCon
     Extensions Names Registry (see Section "Extension Classification and
     Registration").

     This document registers the following values in the vCon analysis
     type registry:

     *  agent_trace

     This document registers the following values in the vCon attachment
     purpose registry:

     *  agent_file_change

     *  agent_artifact

     *  agent_environment

     *  scitt_receipt

     *  agent_trace_cose_sign1

  13.  References

  13.1.  Normative References

     [I-D.draft-birkholz-verifiable-agent-conversations]
                Birkholz, H., "Verifiable Agent Conversations", 2026,
                <https://datatracker.ietf.org/doc/draft-birkholz-
                verifiable-agent-conversations/>.

     [I-D.draft-howe-vcon-lawful-basis]
                McCarthy-Howe, T., "vCon Lawful Basis", 2026,
                <https://datatracker.ietf.org/doc/draft-howe-vcon-lawful-
                basis/>.

     [I-D.draft-ietf-vcon-vcon-core]
                Petrie, D. G., "The JSON format for vCon - Conversation
                Data Container", Work in Progress, Internet-Draft, draft-
                ietf-vcon-vcon-core-02, January 2026,
                <https://datatracker.ietf.org/doc/draft-ietf-vcon-vcon-
                core/>.







  McCarthy-Howe           Expires 21 November 2026               [Page 11]


  Internet-Draft             vCon Agent Session                   May 2026


     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC3339]  Klyne, G., "Date and Time on the Internet: Timestamps",
                July 2002, <https://www.rfc-editor.org/rfc/rfc3339.html>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

  13.2.  Informative References

     [EU-AI-ACT]
                European Union, "Regulation (EU) 2024/1689 (Artificial
                Intelligence Act)", 2024,
                <https://artificialintelligenceact.eu/>.

     [I-D.draft-howe-vcon-lifecycle]
                McCarthy-Howe, T., "vCon Lifecycle", 2026,
                <https://datatracker.ietf.org/doc/draft-howe-vcon-
                lifecycle/>.

     [I-D.draft-ietf-vcon-overview]
                McCarthy-Howe, T., "The vCon - Conversation Data Container
                - Overview", 2025, <https://datatracker.ietf.org/doc/
                draft-ietf-vcon-overview/>.

     [NIST-AI-RMF]
                National Institute of Standards and Technology, "AI Risk
                Management Framework 1.0", January 2023,
                <https://www.nist.gov/itl/ai-risk-management-framework>.

     [RFC8152]  Schaad, J., "CBOR Object Signing and Encryption (COSE)",
                July 2017, <https://www.rfc-editor.org/rfc/rfc8152.html>.

     [RFC8949]  Bormann, C., "Concise Binary Object Representation
                (CBOR)", December 2020,
                <https://www.rfc-editor.org/rfc/rfc8949.html>.

  Acknowledgments

     Thanks to the vCon working group and the authors of
     [I-D.draft-birkholz-verifiable-agent-conversations] for discussions
     that motivated this extension.





  McCarthy-Howe           Expires 21 November 2026               [Page 12]


  Internet-Draft             vCon Agent Session                   May 2026


  Author's Address

     Thomas McCarthy-Howe
     VCONIC
     United States
     Email: ghostofbasho@gmail.com













































  McCarthy-Howe           Expires 21 November 2026               [Page 13]


name: draft-zhang-rtgwg-agent-policy-aware-network
rev: 00
title: Use Cases and Requirements for AI Agent Policy-Aware Network
time: 2026-03-15T02:40:36Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-16T02:40:36Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["ML traffic mgmt", "Policy/governance", "Autonomous netops"]
tags: []
fetched_at: 2026-05-22T09:24:40.604488+00:00
source: ietf
abstract:
  With the widespread adoption of AI Agents, traditional network
     architectures can no longer meet the demand for efficient
     collaboration between Agents and networks.  This document proposes a
     new paradigm of "AI Agent Policy-Aware Network", enabling three key
     transformations: from Flow-aware to Agent-aware, from QoS-based to
     Policy-intent-based, and from Network-driven to Agent-network
     collaborative.  By defining core components such as the Agent Policy-
     aware Controller and Agent Policy-Aware Device, this paradigm
     establishes a dynamic mapping mechanism between Agent intents and
     network policies, supporting key scenarios including autonomous
     performance measurement, path optimization, SLA assurance, and secure
     transmission.  This document outlines the background, scenarios, use
     cases and requirements of Agent Policy-aware Network.

full_text:
  RTGWG                                                           X. Zhang
  Internet-Draft                                              China Mobile
  Intended status: Standards Track                           15 March 2026
  Expires: 16 September 2026


        Use Cases and Requirements for AI Agent Policy-Aware Network
              draft-zhang-rtgwg-agent-policy-aware-network-00

  Abstract

     With the widespread adoption of AI Agents, traditional network
     architectures can no longer meet the demand for efficient
     collaboration between Agents and networks.  This document proposes a
     new paradigm of "AI Agent Policy-Aware Network", enabling three key
     transformations: from Flow-aware to Agent-aware, from QoS-based to
     Policy-intent-based, and from Network-driven to Agent-network
     collaborative.  By defining core components such as the Agent Policy-
     aware Controller and Agent Policy-Aware Device, this paradigm
     establishes a dynamic mapping mechanism between Agent intents and
     network policies, supporting key scenarios including autonomous
     performance measurement, path optimization, SLA assurance, and secure
     transmission.  This document outlines the background, scenarios, use
     cases and requirements of Agent Policy-aware Network.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 16 September 2026.

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.





  Zhang                   Expires 16 September 2026               [Page 1]


  Internet-Draft         Agent,policy-aware,network             March 2026


     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
       1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Scenarios of Agent Policy-aware Networks  . . . . . . . . . .   3
       2.1.  Medical Emergency Rescue  . . . . . . . . . . . . . . . .   3
       2.2.  Game Multi-Agent Collaboration  . . . . . . . . . . . . .   4
       2.3.  Government Cross-Domain Secure Transmission . . . . . . .   4
     3.  Use cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Agent Policy-aware Performance Measurement  . . . . . . .   5
       3.2.  Agent Policy-aware Path Optimization  . . . . . . . . . .   5
       3.3.  Agent Policy-aware SLA Level Assurance  . . . . . . . . .   6
       3.4.  Agent Policy-aware Security . . . . . . . . . . . . . . .   7
     4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
       6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
       6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

  1.  Introduction

     Service Agent (SA): An autonomous intelligent entity capable of
     perceiving environmental information, making independent decisions,
     and executing tasks to achieve specific goals, which can interact
     with networks to express policy intents and obtain network resources
     and service guarantees.

     AI Agent Policy-Aware Network: A network paradigm that can identify,
     understand, and execute the policy intents of AI Agents, realizing
     dynamic mapping between Agent intents and network policies, and
     supporting bidirectional collaborative decision-making between Agents
     and networks.

     Agent Policy-Aware Controller (APC): A core component responsible for
     parsing Agent policy intents, dynamically mapping them to network
     policies, and coordinating resource allocation and policy enforcement
     across the network.



  Zhang                   Expires 16 September 2026               [Page 2]


  Internet-Draft         Agent,policy-aware,network             March 2026


     Agent Policy-Aware Device (APAD): A network device that can receive
     and execute policies issued by the Agent Policy-aware Controller or
     Service Agent, supporting real-time policy adjustment and enforcement
     based on network status and Agent requirements.

  1.1.  Requirements Language

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  1.2.  Terminology

     Service Agent (SA): An autonomous intelligent entity capable of
     perceiving environmental information, making independent decisions,
     and executing tasks to achieve specific goals, which can interact
     with networks to express policy intents and obtain network resources
     and service guarantees.

     AI Agent Policy-Aware Network: A network paradigm that can identify,
     understand, and execute the policy intents of AI Agents, realizing
     dynamic mapping between Agent intents and network policies, and
     supporting bidirectional collaborative decision-making between Agents
     and networks.

     Agent Policy-Aware Controller (APAC): A core component responsible
     for parsing Agent policy intents, dynamically mapping them to network
     policies, and coordinating resource allocation and policy enforcement
     across the network.

     Agent Policy-Aware Device (APAD): A network device that can receive
     and execute policies issued by the Agent Policy-aware Controller or
     Service Agent, supporting real-time policy adjustment and enforcement
     based on network status and Agent requirements.

  2.  Scenarios of Agent Policy-aware Networks

  2.1.  Medical Emergency Rescue

     When a home health agent detects an elderly person fainting, it needs
     to immediately initiate a medical rescue process.  During the rescue,
     vital sign data (such as heart rate and blood pressure) must be
     transmitted to the hospital in real time through an exclusive low-
     latency channel to ensure the timeliness of medical decisions.  At
     the same time, the channel must meet high security level requirements
     to prevent data leakage and strictly prohibit cross-domain



  Zhang                   Expires 16 September 2026               [Page 3]


  Internet-Draft         Agent,policy-aware,network             March 2026


     transmission to comply with medical privacy regulations.  The network
     system should dynamically create and maintain this channel without
     manual intervention to support efficient response within the "golden
     rescue time" and achieve seamless collaboration between the Agent and
     the network.

  2.2.  Game Multi-Agent Collaboration

     In real-time game battles, player Agents need to obtain low-latency
     and low-jitter network guarantees during highly dynamic operations
     such as team battles and skill casting.  Agents should be able to
     independently negotiate path switching with network Agents,
     supporting "lossless switching" requirements to avoid lag, while
     dynamically adapting to changes in game load.  Based on Agent policy
     intents (e.g., "skill casting"), the network needs to real-time
     optimize transmission paths to ensure smooth operation responses.
     The entire process requires no human intervention, reflecting the
     collaborative capability of Agent active decision-making and network
     dynamic response, and improving the real-time and immersion of the
     game experience.

  2.3.  Government Cross-Domain Secure Transmission

     Government departments need to securely transmit sensitive medical
     data (such as cross-provincial health records), requiring the network
     to automatically establish an ultra-high-security channel.  The
     security level of the channel must be dynamically adapted based on
     the trust domain to which the Agent belongs (e.g., enabling group
     security mechanisms within the health system), avoiding manual
     configuration of whitelists or security policies.  The network should
     be able to identify the identities of collaborating parties (such as
     digital agents of provincial health commissions and municipal medical
     insurance bureaus), and enable preconfigured security policies to
     ensure compliant and efficient data transmission.  At the same time,
     the channel needs to support cross-domain collaboration but be
     strictly limited to authorized trust scopes to meet the rigid
     requirements of government data security and compliance.

  3.  Use cases

     This section illustrates some use cases for Agent Policy-aware
     Networks.









  Zhang                   Expires 16 September 2026               [Page 4]


  Internet-Draft         Agent,policy-aware,network             March 2026


  3.1.  Agent Policy-aware Performance Measurement

     Service Agents have strict latency and jitter requirements for
     specific data flows (e.g., emergency rescue video streams), and need
     real-time end-to-end network quality perception to ensure business
     SLA compliance.

     Agent Actions:

     1.Collaborate with Measurement Agents on APAD, and issue structured
     measurement intents based on business SLA requirements (latency,
     jitter, packet loss, reliability).

     2.Receive structured measurement results fed back by APAD upon task
     initialization, service handover or network quality degradation, and
     extract quantitative performance characteristics of business flows
     (total session traffic, packet length, traffic time-series patterns,
     etc.).

     3.Predict traffic and security requirements based on measured
     performance characteristics, map business semantic actions to network
     traffic features, and output explicit QoS requirements (low latency,
     anti-jitter, bandwidth reservation, ultra-high security, etc.) to the
     network.

     Network Actions:

     1.Measurement Agents on APADs automatically select adaptive
     measurement protocols (e.g., in-band flow detection, TWAMP) according
     to Agent measurement intents.

     2.APADs structure and feed back collected performance data to Service
     Agents in a standardized format.

     3.Generate unique Agent policy-aware identifiers for business flows
     after receiving QoS requirements, and allocate dedicated network
     resources to implement differentiated quality guarantees.

  3.2.  Agent Policy-aware Path Optimization

     When congestion or faults occur on the current transmission path,
     service SLAs may be degraded.  The network should switch to a more
     optimal path without service interruption, enabling fault self-
     healing and experience self-optimization, thereby ensuring continuous
     service delivery.

     Agent Actions:




  Zhang                   Expires 16 September 2026               [Page 5]


  Internet-Draft         Agent,policy-aware,network             March 2026


     Service Agents receive network feedback of quality degradation
     alarms, and issue a request for "path recalculation and switching" to
     the network in combination with service tolerance (e.g., "temporary
     interruption allowed" or "lossless switching mandatory").

     Network Actions:

     The Agent Policy-aware Controller (APAC) calculates an optimal set of
     schedulable paths that meet constraints based on real-time network
     topology and link status, confirms the switching strategy with
     Service Agents, and finally executes seamless path migration.
     Schedulable Path Set Information Model: ‐Basic Identifier: Path ID /
     Path Group ID ‐Performance Attributes: Latency, jitter, packet loss,
     bandwidth, remaining bandwidth ‐O&M Attributes: Cost, priority,
     reliability, congestion probability ‐Constraint Attributes: Slicing
     support, cross-domain support, encryption support

  3.3.  Agent Policy-aware SLA Level Assurance

     Different types of traffic from Agents feature high dynamism,
     burstiness and periodicity (e.g., scheduled big data
     synchronization).  The network needs to allocate exclusive resources
     such as bandwidth on demand to realize "tidal scheduling" of network
     resources, greatly improve resource utilization, and ensure
     deterministic experience for critical services.

     Agent Actions:

     Service Agents predict future traffic trends and send "resource
     reservation intents" (including time window, bandwidth peak, and
     duration) to the network.

     Network Actions:

     The Resource Agent of APAC evaluates the global network load: if
     resources are sufficient, it temporarily locks the corresponding
     bandwidth slice; if resources are tight, it negotiates a degradation
     scheme with the Agent or suggests adjusting the time window.

     The Path Agent of APAC completes the full lifecycle management of
     bearer tunnels such as SRv6 Policy and network slicing, adjusting the
     level of SLA assurance and dismantling tunnels on demand.

     For Agent collaboration requirements that transmit information in a
     specified sequence, SRv6 service function chain evolution technology
     is adopted to ensure the order and reliability of information
     transmission, meeting the timing requirements of collaborative tasks.




  Zhang                   Expires 16 September 2026               [Page 6]


  Internet-Draft         Agent,policy-aware,network             March 2026


  3.4.  Agent Policy-aware Security

     When Agents in different trust domains conduct data interaction, the
     network needs to dynamically match the corresponding security levels
     and encryption mechanisms to realize identity and context-based
     dynamic zero-trust security, ensuring that data only flows within
     authorized scopes.

     Agent Actions:

     The communicating Agents exchange identity credentials and trust
     domain attributes, and declare the required security levels (e.g.,
     "national cryptographic algorithm encryption", "cross-domain
     isolation").

     Network Actions:

     The Network Security Agent parses the identities of both parties,
     automatically retrieves and matches preconfigured cross-domain mutual
     trust policies, and provides hierarchical security technologies on
     demand, including IPSec, QKD key distribution, and group secure
     transmission.  The policies are automatically revoked after the
     session ends.

  4.  IANA Considerations

     TBD.

  5.  Security Considerations

     TBD.

  6.  References

  6.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

  6.2.  Informative References





  Zhang                   Expires 16 September 2026               [Page 7]


  Internet-Draft         Agent,policy-aware,network             March 2026


     [I-D.yang-rtgwg-arn-framework-04]
                Yang, F. and C. Lin, "Application-Responsive Network
                Framework", Work in Progress, Internet-Draft, draft-yang-
                rtgwg-arn-framework-04, 29 June 2025,
                <https://datatracker.ietf.org/doc/html/draft-yang-rtgwg-
                arn-framework-04>.

     [I-D.li-rtgwg-apn-framework]
                Li, Z., Voyer, D., Li, C., Liu, P., Cao, C., Mishra, G.
                S., and N. Geng, "Application-aware Networking (APN)
                Framework", Work in Progress, Internet-Draft, draft-li-
                rtgwg-apn-framework-01, 12 November 2025,
                <https://datatracker.ietf.org/doc/html/draft-li-rtgwg-apn-
                framework-01>.

  Author's Address

     Xiaoqiu Zhang
     China Mobile
     China
     Email: zhangxiaoqiu@chinamobile.com






























  Zhang                   Expires 16 September 2026               [Page 8]


name: draft-shang-campus-agent-scope-down
rev: 00
title: Campus Agent Identification and Scope-Down Access Control
time: 2026-03-15T05:15:53Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-16T05:15:53Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Policy/governance", "Agent discovery/reg"]
tags: []
fetched_at: 2026-05-22T09:24:40.604493+00:00
source: ietf
abstract:
  AI agents operating in enterprise campus networks execute user-
     delegated tasks by invoking multiple tools and services, often
     without continuous user supervision.  Traditional authorization
     models assume stable applications and human-driven interactions,
     creating a mismatch when applied to autonomous agents that can chain
     actions across heterogeneous systems.

     Campus environments also contain heterogeneous and legacy services
     across diverse protocols, making per-service agent-aware
     authorization difficult to deploy consistently.  This document
     describes the problem space for campus agent access control and
     argues that agents require task-bound privilege reduction ("scope-
     down") and that enforcement can be provided by in-path network
     devices in order to preserve compatibility with existing systems.

full_text:
  Network Working Group                                           C. Shang
  Internet-Draft                                                  X. Liang
  Intended status: Informational                                  W. Jiang
  Expires: 13 September 2026                                        Huawei
                                                             12 March 2026


         Campus Agent Identification and Scope-Down Access Control
                   draft-shang-campus-agent-scope-down-00

  Abstract

     AI agents operating in enterprise campus networks execute user-
     delegated tasks by invoking multiple tools and services, often
     without continuous user supervision.  Traditional authorization
     models assume stable applications and human-driven interactions,
     creating a mismatch when applied to autonomous agents that can chain
     actions across heterogeneous systems.

     Campus environments also contain heterogeneous and legacy services
     across diverse protocols, making per-service agent-aware
     authorization difficult to deploy consistently.  This document
     describes the problem space for campus agent access control and
     argues that agents require task-bound privilege reduction ("scope-
     down") and that enforcement can be provided by in-path network
     devices in order to preserve compatibility with existing systems.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 13 September 2026.

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.



  Shang, et al.           Expires 13 September 2026               [Page 1]


  Internet-Draft           Campus Agent Scope-Down              March 2026


     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Status of This Memo . . . . . . . . . . . . . . . . . . . . .   2
     2.  Copyright Notice  . . . . . . . . . . . . . . . . . . . . . .   2
     3.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Example Campus Network Architecture . . . . . . . . . . . . .   3
     5.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     6.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   5
     7.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   5
     8.  Deployment Models . . . . . . . . . . . . . . . . . . . . . .   6
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
     10. Privacy Considerations  . . . . . . . . . . . . . . . . . . .   7
     11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
     13. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
       13.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     14. Normative References  . . . . . . . . . . . . . . . . . . . .   7
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

  1.  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  The list of current Internet-Drafts is available
     at:

     https://datatracker.ietf.org/drafts/current/
     (https://datatracker.ietf.org/drafts/current/)

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.

  2.  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.



  Shang, et al.           Expires 13 September 2026               [Page 2]


  Internet-Draft           Campus Agent Scope-Down              March 2026


     This document is subject to BCP 78 and the IETF Trust’s Legal
     Provisions Relating to IETF Documents.

  3.  Introduction

     Enterprise campus networks increasingly carry traffic generated by AI
     agents acting on behalf of users.  These agents may retrieve internal
     documents, query knowledge bases, invoke APIs, and automate workflows
     across multiple services.

     Unlike conventional applications, agents may be instantiated per task
     and autonomously chain operations based on intermediate results.
     Permissions that are safe for human operation may therefore become
     unsafe when exercised by an autonomous actor operating at machine
     speed.

     Existing standards such as OAuth 2.0 [RFC6749] and JSON Web Tokens
     [RFC7519] provide identity and delegation primitives.  However, these
     mechanisms alone do not address task-bound privilege reduction or
     enforcement in heterogeneous campus environments.

     Deployable campus agent security therefore requires two capabilities:

     *  recognition of agent-generated traffic

     *  enforcement of task-bound privilege scope

  4.  Example Campus Network Architecture























  Shang, et al.           Expires 13 September 2026               [Page 3]


  Internet-Draft           Campus Agent Scope-Down              March 2026


                         +----------------------+
                         |   Private Cloud RS   |
                         +----------^-----------+
                                    |
                         +----------------------+
                         |   Public Cloud RS    |
                         +----------^-----------+
                                    |
                              +-----+-----+
                              |   Gateway  |
                              +--+------+--+
                                 |      |
                                 |      +-------------+
                                 |                    |
                                 v                    v
     +------------------------------------+  +----------------------+
     |        Campus Network              |  |   Branch Network     |
     |                                    |  |                      |
     |      +--------------------+        |  |    +-------------+   |
     |      |     Core Switch    |        |  |    |   Switch    |   |
     |      +----+----------+----+        |  |    +--+---------++   |
     |           |          |             |  |       |         |    |
     |     +-----+----+  +----+----+      |  |    +--+--+   +--+--+ |
     |     | Switch   |  | Switch  |      |  |    | App |   |Agent| |
     |     +----+-----+  +----+----+      |  |    +--+--+   +--+--+ |
     |          |              |          |  |       |         |    |
     |       +--+--+        +--+--+       |  |    +--+--+   +--+--+ |
     |       | App |        |Agent|       |  |    |User |   |User | |
     |       +--+--+        +--+--+       |  |    +-----+   +-----+ |
     |          |              |          |  |                      |
     |       +--+--+        +--+--+       |  |                      |
     |       |User |        |User |       |  |                      |
     |       +-----+        +-----+       |  |                      |
     |                                    |  |                      |
     |  +--------------+  +-------------+ |  |                      |
     |  | Resource Svr |  | IdP / AS    | |  |                      |
     |  +--------------+  +-------------+ |  |                      |
     +------------------------------------+  +----------------------+

                                    Figure 1

  5.  Terminology

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     [RFC2119] and [RFC8174] when, and only when, they appear in all
     capitals, as shown here.



  Shang, et al.           Expires 13 September 2026               [Page 4]


  Internet-Draft           Campus Agent Scope-Down              March 2026


     Agent:  Software that performs tasks on behalf of a user or principal
        and may autonomously invoke services or tools.

     Agent Identifier (Agent-ID):  A verifiable identifier associated with
        a specific agent instance.

     Principal:  The human user or entity on whose behalf the agent
        operates.

     Authorization Server (AS):  The OAuth authorization server issuing
        tokens.

     Resource Server (RS):  A server hosting protected resources.

     In-Path Network Device (ND):  A network device positioned on the
        traffic path capable of enforcing policy decisions.

  6.  Problem Statement

     Traditional authorization models assume stable applications and
     human-driven workflows.  Agents violate these assumptions by
     dynamically selecting targets and chaining tools across systems.

     Without task-bound constraints, agent-driven workflows introduce
     several risks:

     *  over-broad aggregation of internal data across multiple systems

     *  cross-boundary exfiltration when generated output is transmitted
        externally

     *  unsupervised tool chaining across services without user review

     *  machine-scale amplification of data access or operations

     Campus environments also contain heterogeneous services and legacy
     protocols, making it operationally infeasible to require each service
     to implement agent-aware authorization.

  7.  Architecture











  Shang, et al.           Expires 13 September 2026               [Page 5]


  Internet-Draft           Campus Agent Scope-Down              March 2026


     Principal      Agent        Network      Auth         Resource
        |        Application     Device       Server        Server
        |             |             |            |             |
        | OAuth req   |             |            |             |
        |--------------------------------------->|             |
        |             |             |            |             |
        |             |             |  OAuth token             |
        |             |             |<-----------|             |
        |             | resource request + Agent-ID            |
        |             |------------------------->|             |
        |             |             |            |             |
        |             |       policy evaluation  |             |
        |             |             |            |             |
        |             | request + scoped token   |             |
        |             |------------------------->|             |

  8.  Deployment Models

     Different deployment models are possible.

     Model A: Network Device performs token validation and policy
     enforcement without issuing new tokens.

     Model B: Network Device obtains a reduced-scope token through OAuth
     Token Exchange [RFC8693] or via Authorization Server policy
     decisions.

     This document does not define a new OAuth grant type or token format
     and relies on existing OAuth mechanisms.

  9.  Security Considerations

     Deployments must address several threats.

     Agent identity spoofing: Deployments *MUST* ensure that Agent-ID
     cannot be forged or reused across devices.

     Token replay: Deployments *SHOULD* bind tokens to the Network Device
     as audience and *MAY* use mutual TLS or channel binding to reduce
     replay risk.

     Network bypass: Network architectures *SHOULD* enforce that agent
     traffic cannot bypass the Network Device through fabric policies, VRF
     isolation, or ACL enforcement.

     Intent mis-modeling: Scope-down mechanisms ensure that authorization
     does not expand privilege beyond the original delegation but cannot
     eliminate risks caused by incorrect intent interpretation.



  Shang, et al.           Expires 13 September 2026               [Page 6]


  Internet-Draft           Campus Agent Scope-Down              March 2026


  10.  Privacy Considerations

     Deployments may log Agent-ID and authorization decisions for
     auditing.

     Operators *SHOULD* minimize collection of unnecessary personal data
     and avoid storing sensitive token contents.

     Deployments *SHOULD* consider using short-lived or per-task Agent-IDs
     and *SHOULD* distinguish Principal identifiers from Agent-IDs in
     audit logs.

  11.  IANA Considerations

     This document makes no requests of IANA.

  12.  Acknowledgements

     The authors thank members of the research community for discussions
     on agent identity and authorization models in campus networks.

  13.  References

  13.1.  Normative References

     [RFC2119]

     [RFC8174]

     [RFC6749]

     [RFC7519]

     [RFC8693]

     [RFC9068]

  14.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/info/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/info/rfc8174>.




  Shang, et al.           Expires 13 September 2026               [Page 7]


  Internet-Draft           Campus Agent Scope-Down              March 2026


     [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
                RFC 6749, DOI 10.17487/RFC6749, October 2012,
                <https://www.rfc-editor.org/info/rfc6749>.

     [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
                (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
                <https://www.rfc-editor.org/info/rfc7519>.

     [RFC8693]  Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
                and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
                DOI 10.17487/RFC8693, January 2020,
                <https://www.rfc-editor.org/info/rfc8693>.

     [RFC9068]  Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0
                Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October
                2021, <https://www.rfc-editor.org/info/rfc9068>.

  Authors' Addresses

     Chao Shang
     Huawei
     Email: chao.shang@huawei.com


     Liang Xia
     Huawei
     Email: frank.xialiang@huawei.com


     Weiyu Jiang
     Huawei
     Email: jiangweiyu1@huawei.com



















  Shang, et al.           Expires 13 September 2026               [Page 8]


name: draft-han-agent-comm-enterprise
rev: 00
title: Considerations for AI Agent Communication and Networking in Enterprise
time: 2026-03-15T12:29:08Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-16T12:29:08Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent identity/auth", "Agent discovery/reg"]
tags: []
fetched_at: 2026-05-22T09:24:40.604497+00:00
source: ietf
abstract:
  This document focuses on enterprise scenarios, investigating key
     technologies including agent identification and registration,
     capability discovery, efficient communication, and secure
     collaboration.  It proposes an agent identifier and semantic routing
     mechanism to achieve trusted access and efficient collaboration among
     heterogeneous agents, providing a technical path for campus-level
     multi-agent cooperation.

full_text:
  Network Working Group                                        M. Han, Ed.
  Internet-Draft                                               Z. Han, Ed.
  Intended status: Standards Track                                   T. He
  Expires: 16 September 2026                                       R. Pang
                                                              China Unicom
                                                             15 March 2026


   Considerations for AI Agent Communication and Networking in Enterprise
                     draft-han-agent-comm-enterprise-00

  Abstract

     This document focuses on enterprise scenarios, investigating key
     technologies including agent identification and registration,
     capability discovery, efficient communication, and secure
     collaboration.  It proposes an agent identifier and semantic routing
     mechanism to achieve trusted access and efficient collaboration among
     heterogeneous agents, providing a technical path for campus-level
     multi-agent cooperation.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 16 September 2026.

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components



  Han, et al.             Expires 16 September 2026               [Page 1]


  Internet-Draft  Considerations for AI Agent Communicatio      March 2026


     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
       3.1.  AI Agent Protocol heterogeneity and interoperability
             barriers  . . . . . . . . . . . . . . . . . . . . . . . .   3
       3.2.  Massive Agent Connection and Addressing . . . . . . . . .   3
       3.3.  Performance, Reliability and QoS Guarantee  . . . . . . .   3
       3.4.  Trustworthy Access and Permission Control . . . . . . . .   3
     4.  Requirements of Agent Communication and Networking in
             Enterprise  . . . . . . . . . . . . . . . . . . . . . . .   4
       4.1.  Requirements for AI Agent . . . . . . . . . . . . . . . .   4
       4.2.  Requirements for Network  . . . . . . . . . . . . . . . .   4
       4.3.  Requirements for Agent Gateway  . . . . . . . . . . . . .   4
     5.  Potential Key Technologies for Network Infrastructure . . . .   4
       5.1.  Agent Service Awareness . . . . . . . . . . . . . . . . .   5
       5.2.  Agent Service Bearer  . . . . . . . . . . . . . . . . . .   5
       5.3.  Agent ID and Skill Identification . . . . . . . . . . . .   5
       5.4.  Token/Agent-aware Routing . . . . . . . . . . . . . . . .   5
     6.  Potential Key Technologies for AI Agent . . . . . . . . . . .   6
     7.  Potential Key Technologies for AI Agent Gateway . . . . . . .   6
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     10. Informative References  . . . . . . . . . . . . . . . . . . .   6
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

  1.  Introduction

  1.1.  Overview

     Artificial intelligence is evolving from a model-dominated stage
     toward autonomous and collaborative agents.  Constructing network
     infrastructure that supports efficient and secure agent collaboration
     has become critical.  To address the core challenges of large-scale
     multi-agent collaboration in enterprise digital transformation, this
     paper focuses on enterprise and campus scenarios and proposes an
     agent private network architecture centered on the Agent Gateway as
     the core device.  It investigates a key technical system covering
     agent identification and registration, capability discovery,
     efficient communication, and secure collaboration, and innovatively
     proposes an IPv6 address-based agent identifier and semantic routing
     mechanism.  Based on the Agent Gateway, this architecture achieves



  Han, et al.             Expires 16 September 2026               [Page 2]


  Internet-Draft  Considerations for AI Agent Communicatio      March 2026


     trusted access, capability discovery, and efficient collaboration
     among heterogeneous agents through synergy between network-layer and
     application-layer capabilities, providing a technical reference and
     practical approach for enterprise and campus-level agent
     collaboration.

  2.  Conventions and Definitions

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in BCP
     14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  3.  Problem Statement

  3.1.  AI Agent Protocol heterogeneity and interoperability barriers

     There are various types of devices, platforms, and applications
     within the AI agents.  Different agents vary in resources and
     supported protocols (e.g., ACP, A2A, ANP, etc.)., so adaptation and
     protocol conversion are required for agents' communication.

  3.2.  Massive Agent Connection and Addressing

     The number of agents in the enterprise (including robots, sensors,
     digital humans, edge AI units, etc.) can reach the million-level
     scale.  Traditional IP addressing and service discovery mechanisms
     (such as DNS and static configuration) are unable to support dynamic
     registration, real-time discovery, and high-concurrency connections,
     which leads to low addressing accuracy and high communication
     latency.

  3.3.  Performance, Reliability and QoS Guarantee

     AI agent services (such as real-time control, video analysis, and
     emergency response) have stringent requirements for low latency, high
     reliability, and deterministic QoS.  However, the best-effort
     transmission mode of traditional networks fails to meet these strict
     demands, which easily gives rise to issues such as transmission
     delay, jitter, packet loss, and congestion collapse.

  3.4.  Trustworthy Access and Permission Control

     During the cross-domain or cross-system communication of agents,
     there is a lack of unified identity authentication, fine-grained
     permission control, and behavior auditing mechanisms.  This brings
     about potential security risks.



  Han, et al.             Expires 16 September 2026               [Page 3]


  Internet-Draft  Considerations for AI Agent Communicatio      March 2026


  4.  Requirements of Agent Communication and Networking in Enterprise

  4.1.  Requirements for AI Agent

     Agent Identity Identification & Discovery: Distinguish agents from
     real users, integrate semantic understanding and addressing to match
     business needs with corresponding agents.  Heterogeneous
     Compatibility: Different agents vary in resources and supported
     protocols, so adaptation and protocol conversion are required for
     agents communication.

  4.2.  Requirements for Network

     Efficient Agent Communication: For agent interaction, consider
     network reachability, QoS guarantee, and differentiated SLA services.
     Due to high pressure in peer-to-peer collaboration among multiple
     agents, convergence is needed to enable hierarchical communication.
     Agent Scheduling & Management: Realize agent scheduling within and
     across enterprise campus; unify orchestration of network resources
     and agent services to align network and business.  Security &
     Privacy: Implement access management and permission control to
     enhance security.

  4.3.  Requirements for Agent Gateway

     As the core device of the enterprise agent private network, the agent
     gateway integrates the reliable transmission capability of
     communication gateways and the cognitive decision-making
     characteristics of agents.  It acts as the connection center, policy
     enforcer, and security guardian, supporting trusted access, efficient
     communication, and collaborative operations among agents.

     [I-D.han-rtgwg-agent-gateway-intercomm-framework] proposes the Agent
     Gateway Intercommunication Framework, with Application Service Layer,
     Orchestration & Control Layer, Agent Connectivity Layer, Network
     Communication Layer.

  5.  Potential Key Technologies for Network Infrastructure

     This section proposes several potential technologies, which are
     mainly used for agent communication and networking in enterprise
     scenarios.









  Han, et al.             Expires 16 September 2026               [Page 4]


  Internet-Draft  Considerations for AI Agent Communicatio      March 2026


  5.1.  Agent Service Awareness

     Agent Service Type Identification: Identifies services including
     real-time control, video analysis, semantic interaction, data
     synchronization, and emergency commands.  QoS Requirement Awareness:
     Recognizes differentiated service demands for latency, reliability,
     and throughput, and automatically matches appropriate network
     scheduling policies.  Traffic Feature and Behavior Awareness:
     Perceives agent communication patterns such as request-response,
     publish-subscribe, multicast, broadcast, and continuous streaming to
     optimize forwarding paths and resource allocation.

  5.2.  Agent Service Bearer

     Deterministic Forwarding and Low-Latency Transmission: Provides
     deterministic transmission with bandwidth reservation, low jitter,
     and low packet loss for real-time control and emergency agent
     services, guaranteeing SLAs for critical services.  High-Concurrency
     Connection Bearer: Supports concurrent access of massive agents, long
     connection keepalive, and lightweight signaling interaction, solving
     resource bottlenecks associated with million-scale agent access.

  5.3.  Agent ID and Skill Identification

     Globally Unique Agent Identifier: Defines a unified, routable, and
     cross-domain interoperable Agent ID to replace traditional IP
     addresses as the core identity of agents.  Standardized Description
     of Capabilities/Skills: Performs structured and parsable skill
     modeling for functions provided by agents, including perception,
     reasoning, execution, collaboration, and scheduling.  ID and Skill
     Registration and Publication: Supports automatic registration of an
     agent's ID, attributes, skills, location, and status, forming a
     global directory service.

  5.4.  Token/Agent-aware Routing

     Token-aware Routing: Forwards the first token and critical tokens
     with high priority to reduce first-packet latency.  Combined with
     token importance classification, differentiated QoS is achieved.
     Agent-aware Routing: Performs routing based on Agent ID, Skill, and
     intent; automatically selects the optimal service provider according
     to task objectives, capability requirements, and load status;
     supports cross-domain, cross-gateway, and cross-enterprise agent
     addressing.  It realizes routing by capability, forwarding by intent
     and supports automatic collaboration among multiple agents.






  Han, et al.             Expires 16 September 2026               [Page 5]


  Internet-Draft  Considerations for AI Agent Communicatio      March 2026


  6.  Potential Key Technologies for AI Agent

     TBD.

  7.  Potential Key Technologies for AI Agent Gateway

     TBD.

  8.  Security Considerations

     TBD.

  9.  IANA Considerations

     TBD.

  10.  Informative References

     [I-D.han-rtgwg-agent-gateway-intercomm-framework]
                Zhengxin, H., Ruan, Z., Han, M., Yan, J., He, T., and R.
                Pang, "Agent Gateway Intercommunication Framework", Work
                in Progress, Internet-Draft, draft-han-rtgwg-agent-
                gateway-intercomm-framework-01, 30 January 2026,
                <https://datatracker.ietf.org/doc/html/draft-han-rtgwg-
                agent-gateway-intercomm-framework-01>.

     [I-D.zgsgl-dispatch-a2a-requirements-enterprise]
                Zhang, L., Geng, N., Shang, X., Gao, Q., Li, Z., and J.
                Ge, "Enhanced A2A Requirements for Agents Collobration in
                Enterprise", Work in Progress, Internet-Draft, draft-
                zgsgl-dispatch-a2a-requirements-enterprise-01, 27 November
                2025, <https://datatracker.ietf.org/doc/html/draft-zgsgl-
                dispatch-a2a-requirements-enterprise-01>.

     [I-D.pang-agents-networking-scenarios]
                Pang, R., Han, M., Liu, B., Zhang, L., Gao, Q., Geng, N.,
                Shang, X., and Z. Li, "Agents Networking Scenarios in
                Enterprise and Broadband Networks", Work in Progress,
                Internet-Draft, draft-pang-agents-networking-scenarios-00,
                6 November 2025, <https://datatracker.ietf.org/doc/html/
                draft-pang-agents-networking-scenarios-00>.










  Han, et al.             Expires 16 September 2026               [Page 6]


  Internet-Draft  Considerations for AI Agent Communicatio      March 2026


     [I-D.zlgsgl-rtgwg-agents-networking-framework]
                Zhang, L., Liu, B., Geng, N., Shang, X., Gao, Q., and Z.
                Li, "Agents Networking Framework for Enterprise and
                Broadband", Work in Progress, Internet-Draft, draft-
                zlgsgl-rtgwg-agents-networking-framework-00, 3 November
                2025, <https://datatracker.ietf.org/doc/html/draft-zlgsgl-
                rtgwg-agents-networking-framework-00>.

  Authors' Addresses

     Mengyao Han (editor)
     China Unicom
     Beijing
     China
     Email: hanmy12@chinaunicom.cn


     Zhengxin Han (editor)
     China Unicom
     Beijing
     China
     Email: hanzx21@chinaunicom.cn


     Tao He
     China Unicom
     Beijing
     China
     Email: het21@chinaunicom.cn


     Ran Pang
     China Unicom
     Beijing
     China
     Email: pangran@chinaunicom.cn















  Han, et al.             Expires 16 September 2026               [Page 7]


name: draft-kiliram-agent-trust-auth-framework
rev: 00
title: A Trust and Authentication Framework for Cross-Domain Agent-to-Agent Communications
time: 2026-03-15T13:25:49Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-16T13:25:49Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "A2A protocols", "Policy/governance"]
tags: []
fetched_at: 2026-05-22T09:24:40.604502+00:00
source: ietf
abstract:
  AI-based agent-to-agent communication increasingly occurs across
     trust domains (e.g., between enterprises, service providers, SaaS
     platforms, and application third parties).  While many agent
     protocols and platforms can provide transport security and local
     permission models, deployments lack a coherent, interoperable
     baseline for verifiable agent identity, credentialing, cross-domain
     authorisation, delegation, revocation, and auditability.

     This document defines an architectural framework for a cross-domain
     trust substrate for AI-based agent ecosystems.  The framework is
     intended to be agent protocol-agnostic and to provide a consistent
     trust baseline that existing and emerging AI agent protocols can
     build upon.

full_text:
  Network Working Group                                            D. King
  Internet-Draft                                      Lancaster University
  Intended status: Informational                               R. Ramdhany
  Expires: 16 September 2026                                           BBC
                                                                    C. Liu
                                                       Huawei Technologies
                                                             15 March 2026


    A Trust and Authentication Framework for Cross-Domain Agent-to-Agent
                               Communications
                draft-kiliram-agent-trust-auth-framework-00

  Abstract

     AI-based agent-to-agent communication increasingly occurs across
     trust domains (e.g., between enterprises, service providers, SaaS
     platforms, and application third parties).  While many agent
     protocols and platforms can provide transport security and local
     permission models, deployments lack a coherent, interoperable
     baseline for verifiable agent identity, credentialing, cross-domain
     authorisation, delegation, revocation, and auditability.

     This document defines an architectural framework for a cross-domain
     trust substrate for AI-based agent ecosystems.  The framework is
     intended to be agent protocol-agnostic and to provide a consistent
     trust baseline that existing and emerging AI agent protocols can
     build upon.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 16 September 2026.






  King, et al.            Expires 16 September 2026               [Page 1]


  Internet-Draft         agent-trust-auth-framework             March 2026


  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.2.  Background  . . . . . . . . . . . . . . . . . . . . . . .   4
         1.2.1.  Agentic Systems Context . . . . . . . . . . . . . . .   4
         1.2.2.  Trust Domain Definition . . . . . . . . . . . . . . .   4
     2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   5
     3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   6
     4.  Threat Model  . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.  Design Goals and Non-Goals  . . . . . . . . . . . . . . . . .   8
     6.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   9
       6.1.  Entities and Roles  . . . . . . . . . . . . . . . . . . .  10
       6.2.  Trust Domains and Trust Anchors . . . . . . . . . . . . .  11
       6.3.  Agent Gateways  . . . . . . . . . . . . . . . . . . . . .  11
       6.4.  Registries and Discovery Interfaces . . . . . . . . . . .  11
       6.5.  Reference Flow Labels and Token Transitions . . . . . . .  12
     7.  Identity and Credential Model . . . . . . . . . . . . . . . .  14
       7.1.  Agent Identifiers . . . . . . . . . . . . . . . . . . . .  14
       7.2.  Credential Formats  . . . . . . . . . . . . . . . . . . .  15
       7.3.  Key Management and Proof-of-Possession  . . . . . . . . .  16
       7.4.  On-Behalf-Of Delegation . . . . . . . . . . . . . . . . .  16
       7.5.  Credential Lifecycle and Rotation . . . . . . . . . . . .  18
     8.  Authentication and Authorisation Patterns . . . . . . . . . .  18
       8.1.  Mutual Authentication . . . . . . . . . . . . . . . . . .  18
       8.2.  Delegation and Call-Chain Context . . . . . . . . . . . .  19
       8.3.  Policy Enforcement and Decision Points  . . . . . . . . .  20
       8.4.  Least-Privilege and Fine-Grained Access Tokens  . . . . .  21
       8.5.  Explicit Workflow and Step-Up Authentication  . . . . . .  22
     9.  Revocation, Rotation, and Lifecycle . . . . . . . . . . . . .  23
       9.1.  Automated Credential Issuance . . . . . . . . . . . . . .  23
       9.2.  Credential Rotation . . . . . . . . . . . . . . . . . . .  24
       9.3.  Revocation  . . . . . . . . . . . . . . . . . . . . . . .  24
       9.4.  Suspension and Resumption . . . . . . . . . . . . . . . .  25



  King, et al.            Expires 16 September 2026               [Page 2]


  Internet-Draft         agent-trust-auth-framework             March 2026


       9.5.  Operational Semantics and Grace Periods . . . . . . . . .  25
     10. Auditability, Transparency, and Evidence  . . . . . . . . . .  26
       10.1.  Audit Requirements . . . . . . . . . . . . . . . . . . .  26
       10.2.  Transparency and Evidence Services . . . . . . . . . . .  27
       10.3.  Decryption and Inspection for Compliance . . . . . . . .  27
     11. Operational Considerations  . . . . . . . . . . . . . . . . .  28
       11.1.  Relationship to OAuth Ecosystem  . . . . . . . . . . . .  28
       11.2.  OAuth Profiling for Agent-to-Agent Communication . . . .  29
       11.3.  Deployment Patterns  . . . . . . . . . . . . . . . . . .  29
       11.4.  Gateway Configuration and Policy . . . . . . . . . . . .  30
       11.5.  Interoperability and Testing . . . . . . . . . . . . . .  31
     12. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  31
     13. Security Considerations . . . . . . . . . . . . . . . . . . .  32
     14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  33
     15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  33
       15.1.  Normative References . . . . . . . . . . . . . . . . . .  33
       15.2.  Informative References . . . . . . . . . . . . . . . . .  33
     Appendix A.  Example Flows (Informative)  . . . . . . . . . . . .  35
       A.1.  Same-Protocol, Cross-Domain Invocation with Token
             Exchange  . . . . . . . . . . . . . . . . . . . . . . . .  35
       A.2.  Cross-Protocol Invocation Through a Gateway . . . . . . .  36
     Appendix B.  Current Agentic Risk Landscape (Informative) . . . .  36
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  37

  1.  Introduction

     AI agent ecosystems are moving from single-agent-service-operator
     deployments to multi-party environments, where independently operated
     AI agents interact across organisational and administrative
     boundaries.  In these environments, trust is partial and dynamic, and
     is constrained by policy, contracts, and regulation.

     Existing AI agent protocols and platforms often provide transport
     security and local permission models.  They do not, by themselves,
     provide a consistent cross-domain baseline for verifiable agent
     identity, accountable delegation, interoperable credential handling,
     and audit evidence.  Interoperability is therefore frequently
     implemented through bespoke integrations with uneven security
     properties and unclear lifecycle semantics.

     This document composes established IETF security and identity
     building blocks into a cross-domain trust substrate for AI agent
     communications.  It also identifies remaining interoperability gaps.

     This document defines a Trust and Authentication Framework and key
     requirements for Agent-to-Agent Communications across domain
     boundaries.  It specifies an architectural model, threat model, and a
     set of requirements for interoperable trust establishment, including:



  King, et al.            Expires 16 September 2026               [Page 3]


  Internet-Draft         agent-trust-auth-framework             March 2026


     trust domains and trust anchors; agent gateways and their security
     roles; identity and credential models; authentication and
     authorisation patterns (including delegation); and operational
     requirements for policy enforcement, lifecycle management, and
     auditability.

  1.1.  Scope

     This framework targets deployments where AI-based agents interact
     across trust domains, including cloud providers and other agent
     service operators hosting agent runtimes, agent gateways, and third-
     party AI agent services.  In these environments, the agent-to-agent
     transport protocol alone does not provide a sufficient basis for
     verifiable agent identity, cross-domain authorisation, delegation,
     and audit.  In this document, a trust domain is a policy and
     governance scope, not simply the set of agents that implement the
     same communication protocol.

     This document does not define a new agent communication protocol.  It
     also does not standardise a global naming or discovery mechanism;
     instead, it defines the trust requirements that any discovery or
     registry interface must satisfy in order to bind endpoints and
     capabilities to verifiable identities and trust anchors across
     domains.  Non-AI software agents are out of scope.

  1.2.  Background

  1.2.1.  Agentic Systems Context

     This document focuses on agentic systems in which software agents can
     plan, invoke tools or services, and execute multi-step tasks across
     organisational boundaries.  These interactions require interoperable
     trust, identity, delegation, and authorisation controls that remain
     consistent across trust domains.

  1.2.2.  Trust Domain Definition

     In this document, a Trust Domain is a bounded policy and governance
     scope in which agents, gateways, identities, and credentials are
     governed under common administrative control or federated trust
     agreements.

     A Trust Domain can align with network boundaries, application/content
     boundaries, protocol ecosystem boundaries, or combinations of these.







  King, et al.            Expires 16 September 2026               [Page 4]


  Internet-Draft         agent-trust-auth-framework             March 2026


     Membership in the same trust domain does not imply universal trust
     between agents; authentication and authorisation are evaluated per
     interaction according to policy.  Therefore, "cross-domain" includes
     interactions across any of these trust-domain scopes.

  2.  Conventions and Terminology

     Even though this document is not a protocol specification, it makes
     use of upper case key words to define requirements unambiguously.

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in BCP
     14 ([RFC2119] and [RFC8174]) when, and only when, they appear in all
     capitals, as shown here.

     Agent: An AI-based software entity that can initiate actions, invoke
     other services, and exchange messages to accomplish tasks.

     Agent Service Operator: The entity responsible for operating an AI
     agent runtime, agent gateway, or related control-plane service.  This
     is distinct from a network infrastructure operator.

     Domain Boundary: A logical boundary between two domains such that
     membership, credentials, and policy assertions from one side are not
     assumed to be valid on the other side without explicit trust
     establishment and enforcement.  Domain boundaries often coincide with
     agent gateways or mediation components.

     Agent Gateway: A policy-enforcing intermediary that mediates agent-
     to-agent communications across trust domains.

     Calling Agent: The initiating agent in a cross-domain interaction.

     Gateway Coordinator: Gateway-side logic that performs policy
     enforcement, token exchange, and context propagation for cross-domain
     interactions.

     Resource Agent: The target agent or service in the destination trust
     domain.

     Subject Token: A token presented by the calling side as input for
     token exchange.

     Exchanged Access Token: A domain-scoped, policy-constrained token
     issued for use in the destination trust domain (i.e., the issued
     token in OAuth 2.0 Token Exchange [RFC8693]).




  King, et al.            Expires 16 September 2026               [Page 5]


  Internet-Draft         agent-trust-auth-framework             March 2026


     Transaction Token: A token that carries workflow and task-intent
     context across delegated or multi-step interactions.

     Relying Party: An entity that evaluates credentials, policy, and
     evidence before accepting agent requests.

     Trust Domain: A bounded policy and governance scope that may align
     with network boundaries, application/content boundaries, protocol
     ecosystem boundaries, or combinations of these.  This document uses
     the term in the same OAuth federation sense as token exchange between
     independently governed domains (see [RFC8693] and
     [I-D.ietf-oauth-identity-chaining]).

     Trust Domain Authority: The policy authority within a trust domain
     that defines trust anchors, identity acceptance criteria, and cross-
     domain policy constraints.

  3.  Problem Statement

     Early AI agent deployments are often single-domain: one agent service
     operator controls runtime, identity lifecycle, and policy
     enforcement.  In that setting, proprietary identity, authorisation,
     and audit mechanisms may be operationally sufficient.

     Cross-domain deployments are different.  They span independent agent
     service operators (for example, enterprises, cloud providers, SaaS
     platforms, and third-party AI agent services) with different issuers,
     policy semantics, and lifecycle processes.  In these settings, the
     transport protocol alone is not sufficient for interoperable trust
     establishment, delegation control, lifecycle handling, and
     auditability.

     Three recurring deployment cases illustrate the problem space:

     *  Same protocol, different providers: an enterprise AI agent hosted
        by one cloud provider or agent service operator invokes a partner
        or supplier AI agent hosted by a different agent service operator
        using the same agent-to-agent protocol.  Despite protocol
        interoperability, the parties still require a consistent approach
        to verifying agent identity and agent service operator
        accountability, evaluating credentials from different issuers,
        applying policy constraints (e.g., least privilege and step-up
        requirements), and handling credential lifecycle events across
        domains.

     *  Different protocols across domains: an agent service operator uses
        one protocol internally while an external AI agent ecosystem uses
        another.  An agent gateway (or protocol bridge) mediates between



  King, et al.            Expires 16 September 2026               [Page 6]


  Internet-Draft         agent-trust-auth-framework             March 2026


        protocols, but trust and authorisation decisions must remain
        coherent end-to-end.  In particular, identity and claims need
        stable representation across the boundary, delegation semantics
        must survive translation, and resulting actions must remain
        attributable and auditable.

     *  Multi-operator media agent pipelines: in Object-Based Media (OBM)
        deployments, AI agents dynamically assemble discrete media objects
        (video segments, audio layers, and associated metadata) across
        independently operated infrastructure, compute, and content
        delivery services.  Agents acting on behalf of different service
        operators must authenticate their task invocations and obtain
        authorisation to access or manipulate media objects, with
        delegation semantics and audit evidence preserved across operator
        boundaries.  This use case is described in
        [I-D.rrk-object-based-media-usecase].

     These cases require a protocol-agnostic trust substrate that can be
     applied consistently across providers, gateways, and heterogeneous
     protocol ecosystems.  A primary interoperability challenge is
     preserving identity, delegation semantics, and policy intent when
     requests are translated between different agent communication
     protocols.

     Cross-domain AI agent deployments face the following recurring gaps:

     *  Verifiable identity: recipients need to authenticate an agent and
        bind that identity to an accountable owner/agent service operator.

     *  Because agents frequently act on delegated authority, recipients
        need a verifiable delegation chain and a way to constrain scope
        and purpose.

     *  Heterogeneous systems — including gateways and intermediaries —
        require consistent policy enforcement across trust domains.

     *  Credential lifecycle: rotation and revocation must be supported
        with clear operational semantics.

     *  Actions and delegation chains must be auditable, with tamper-
        evident evidence for regulated environments.

  4.  Threat Model

     This document considers (non-exhaustive):

     *  Impersonation of agents or agent providers.




  King, et al.            Expires 16 September 2026               [Page 7]


  Internet-Draft         agent-trust-auth-framework             March 2026


     *  Compromise of agent execution environment or keys.

     *  Confused-deputy and privilege escalation via delegation chains.

     *  Replay, token substitution, and context injection.

     *  Cross-domain policy bypass at intermediaries.

     *  Downgrade of trust signals and audit/evidence manipulation.

  5.  Design Goals and Non-Goals

     Goals:

     *  A protocol-agnostic trust baseline for cross-domain agent
        communications (CDAC).

     *  Interoperable identity binding (agent <-> owner/agent service
        operator <-> keys).

     *  Independent agent identities with support for on-behalf-of
        delegation to distinguish agent and principal.

     *  Short-lived, rapidly-rotated credentials that avoid long-term
        static secrets.

     *  Authorisation with constrained scope/purpose, fine-grained access
        tokens, and task-triggered issuance based on least-privilege
        principles.

     *  Delegation chain preservation and verification to prevent
        confused-deputy and privilege escalation attacks.

     *  Standardised lifecycle semantics (issue/rotate/revoke/suspend)
        with automated, zero-touch rotation.

     *  Capability registration, advertisement, and parsing mechanisms
        that reduce the risk of malicious discovery behaviour, spoofed
        announcements, or unsafe consumption of registry data.

     *  Evidence and audit hooks suitable for transparency services,
        regulatory compliance, and operational troubleshooting.

     Non-Goals (initially):

     *  Defining a new agent communication protocol.





  King, et al.            Expires 16 September 2026               [Page 8]


  Internet-Draft         agent-trust-auth-framework             March 2026


     *  Standardising underlying secure transport or message protection
        mechanisms.  These are expected to be provided by existing
        transports (for example, HTTPS/TLS or IPsec) and, where needed,
        application-layer message protection mechanisms such as JOSE/COSE
        [RFC7515] [RFC9052].  This framework builds on top of such
        mechanisms rather than redefining them.

     *  Standardising a global naming or discovery system (the framework
        defines trust requirements for discovery, but not discovery
        protocols themselves).

     *  Defining runtime safety, model alignment mechanisms, or content
        filtering (these are application-layer concerns outside the scope
        of cross-domain trust establishment).

  6.  Architecture

     This section describes the reference architecture used in this
     document: the entities in each trust domain, the cross-domain
     mediation points, and the control points for authentication,
     authorisation, credential lifecycle, and evidence generation.  The
     architecture is protocol-agnostic and can be applied to multiple
     agent messaging protocols and deployment models.

     Figure 1 shows the high-level components and trust relationships.


























  King, et al.            Expires 16 September 2026               [Page 9]


  Internet-Draft         agent-trust-auth-framework             March 2026


              +-----------------------------------------------+
              | Trust Domain A                                |
              |                                               |
              |  +---------+   +---------------------------+  |
              |  | Agent A |-->| Agent Gateway A           |  |
              |  +---------+   | (PEP with PDP interface)  |  |
              |                +---------------------------+  |
              |  +--------------------------+ +----------+    |
              |  | Trust Domain Authority A | | Issuer A |    |
              |  +--------------------------+ +----------+    |
              +-----------------------------------------------+
                          ||  Cross-domain boundary  ||
                          ||  mutual auth + context  ||
              +-----------------------------------------------+
              | Trust Domain B                                |
              |                                               |
              |  +---------------------------+   +---------+  |
              |  | Agent Gateway B           |-->| Agent B |  |
              |  | (PEP with PDP interface)  |   +---------+  |
              |  +---------------------------+                |
              |  +--------------------------+ +----------+    |
              |  | Trust Domain Authority B | | Issuer B |    |
              |  +--------------------------+ +----------+    |
              +-----------------------------------------------+

        +-----------------------------+  +----------------------------+
        | Registry / Discovery        |  | Evidence / Transparency    |
        | (signed, authenticated data)|  | (tamper-evident logs)      |
        +-----------------------------+  +----------------------------+

              Figure 1: Reference Cross-Domain Trust Architecture

  6.1.  Entities and Roles

     *  Agent (caller, callee)

     *  Agent Provider / Operator

     *  Trust Domain Authority (policy + trust anchors)

     *  Agent Gateway (cross-domain mediation)

     *  Credential Issuer (PKI, token issuer, or equivalent)

     *  Transparency / Evidence Service (optional)






  King, et al.            Expires 16 September 2026              [Page 10]


  Internet-Draft         agent-trust-auth-framework             March 2026


  6.2.  Trust Domains and Trust Anchors

     A trust domain MUST define:

     *  One or more trust anchors used to validate agent credentials.

     *  Policy governing acceptable credential types and assurance levels.

     *  Operational requirements for issuance, rotation, and revocation.

     *  Audit and evidence requirements for cross-domain interactions.

  6.3.  Agent Gateways

     Gateways SHOULD support:

     *  Mutual authentication on both sides of the gateway.

     *  Verification of delegation chain and policy constraints.

     *  Policy enforcement (PEP) with a decision interface (PDP).

     *  Evidence emission (logs/receipts) for audited actions.

  6.4.  Registries and Discovery Interfaces

     Discovery mechanisms (DNS, directories, registries, APIs) enable
     agents to locate and interact with other agents or services.  In
     deployments where discovery information influences trust or routing
     decisions, discovery and registration mechanisms MUST support
     verifiable bindings between discovered endpoints and associated
     identities.

     Registration Security:

     *  Capability and endpoint registrations MUST be authenticated.  Only
        agents or operators with valid credentials and appropriate
        authorisation SHOULD be able to register or update entries in a
        discovery registry.

     *  Registrations SHOULD be signed or otherwise cryptographically
        bound to the registering agent's identity to enable verification
        by consumers.

     *  Registries SHOULD implement rate limiting, abuse detection, and
        validation checks to prevent flooding, enumeration, or injection
        of malicious entries.




  King, et al.            Expires 16 September 2026              [Page 11]


  Internet-Draft         agent-trust-auth-framework             March 2026


     Broadcast and Advertisement Security:

     *  Where capability advertisements are broadcast (e.g., via mDNS,
        DNS-SD, or multicast protocols), recipients MUST verify the
        authenticity and authorisation of the broadcaster before trusting
        advertised endpoints or capabilities.

     *  Broadcast mechanisms SHOULD include anti-spoofing protections
        (e.g., cryptographic signatures, nonce-based freshness, or
        network-level source authentication).

     Parsing and Consumption Security:

     *  Agents consuming discovery information MUST implement robust
        parsing and validation to prevent exploitation via malformed or
        malicious registry entries (e.g., buffer overflows, injection
        attacks, or resource exhaustion).

     *  Discovered endpoints and capabilities SHOULD be treated as
        untrusted until verified through authentication and authorisation
        (see Section 8).

     Identity and Trust Anchor Binding:

     *  Discovery mechanisms SHOULD enable consumers to bind discovered
        endpoints or capabilities to verifiable agent identities and
        relevant trust anchors.  For example, a registry entry MAY include
        or reference the agent's credential, public key fingerprint, or
        trust domain identifier.

     *  This document defines requirements for such bindings, but does not
        standardise specific discovery protocols or registry formats.

  6.5.  Reference Flow Labels and Token Transitions

     This subsection introduces flow labels and token terms used across
     Sections 6, 8, 9, and 10.

     *  Calling Agent: the initiating agent in the source trust domain.

     *  Gateway Coordinator: gateway-side logic that performs policy
        enforcement, token handling, and cross-domain mediation.

     *  Resource Agent: the target agent or service in the destination
        trust domain.

     *  Subject Token: token presented by the calling side as input to
        token exchange.



  King, et al.            Expires 16 September 2026              [Page 12]


  Internet-Draft         agent-trust-auth-framework             March 2026


     *  Exchanged Access Token: policy-constrained token issued for the
        destination trust domain (i.e., the issued token in OAuth 2.0
        Token Exchange [RFC8693]).

     *  Transaction Token: token carrying workflow and task-intent context
        across delegated steps.

     Figure 2 shows the reference sequence and control points.

     Domain A to Domain B (cross-trust-domain flow)

     +---------------------------+
     | Calling Agent (Domain A)  |
     +---------------------------+
                   | (F1) Subject Token + intent
                   v
     +-----------------------------------------------+
     | Agent Gateway / Gateway Coordinator           |
     | (PEP, context processor)                      |
     +-----------------------------------------------+
            | (F2) RFC8693 exchange
            v
     +-----------------------------------------------+
     | Authorisation Server / Credential Issuer      |
     +-----------------------------------------------+
            | (F3) Exchanged Access Token
            |      (domain-scoped, least privilege)
            v
     +-----------------------------------------------+
     | Resource Agent / API (Domain B)               |
     +-----------------------------------------------+
            | (F4) Request with Exchanged Access
            |      Token + Transaction context
            | (F5) Revocation / credential status
            |      checks at gateway and relying party
            v
     +-----------------------------------------------+
     | Evidence and Transparency Service             |
     +-----------------------------------------------+
            ^ (F6) Audit / evidence / telemetry records

     Figure 2: Reference Flow Labels for Context-Aware Cross-Domain Access









  King, et al.            Expires 16 September 2026              [Page 13]


  Internet-Draft         agent-trust-auth-framework             March 2026


  7.  Identity and Credential Model

     Cross-domain agent interactions require a consistent approach to
     identity representation, credential binding, and cryptographic proof.
     This section defines requirements for agent identifiers, credential
     formats, key management practices, and lifecycle operations that
     support short-lived credentials and avoid long-term static secrets.

  7.1.  Agent Identifiers

     An agent identifier MUST unambiguously identify an agent instance
     within and across trust domains.  Agent identifiers SHOULD:

     *  Be globally unique or unique within a well-defined namespace.

     *  Be stable across credential rotation events (i.e., the agent
        identity persists even as cryptographic keys are rotated).

     *  Support binding to an accountable agent service operator or owner
        entity (e.g., an organisation, cloud provider, or user principal).

     Agent identifiers MAY be represented using URIs, DIDs (Decentralised
     Identifiers), NAI-style identifiers [RFC7542], or domain-scoped
     naming schemes, provided that the chosen format supports verifiable
     binding to credentials and trust anchors.

     Use of NAI-style identifiers is optional and deployment-specific;
     this document does not require or prefer NAI over other identifier
     formats.

     In delegation scenarios (see Section 7.4), it MUST be possible to
     distinguish the agent's own identity from the identity of the
     principal (user or service) on whose behalf it is acting.

     Identity Schemes and Namespace Considerations:

     Agent identity is fundamentally tied to well-defined namespaces and
     trust contexts.  Different deployment scenarios employ different
     identity management approaches:

     *  Enterprise and Federated Identity: In enterprise consortia and
        federated environments, agent identity is often managed through
        Single Sign-On (SSO), federation, and related identity-provider
        infrastructure.  Provisioning and synchronisation mechanisms such
        as SCIM [RFC7643] [RFC7644] MAY be used operationally, but do not
        by themselves define runtime trust or authorisation semantics
        across domains.




  King, et al.            Expires 16 September 2026              [Page 14]


  Internet-Draft         agent-trust-auth-framework             March 2026


     *  Consumer and Citizen Identity: In consumer or citizen-facing
        scenarios, deployments MAY use verifiable credential ecosystems
        and related work building on the W3C Verifiable Credentials Data
        Model [W3C.VC].  The exact role of such credential formats,
        including CBOR- or JSON-based representations, is deployment-
        specific.

     *  Workload and Application Identity: For application and workload
        identities (including AI agents), emerging work in areas such as
        workload identity and credential management may be relevant to
        representing both the agent's identity and the identity of its
        owner or principal (see Section 7.4).

     These examples are illustrative rather than exhaustive, and the
     relationship between these identity ecosystems and cross-domain agent
     trust is to be discussed in more detail in a later version of this
     document.

     Deployments SHOULD select identity representation formats appropriate
     to their operational context and trust model.  Universal identity
     schemes face practical challenges in namespace governance, trust
     anchor distribution, and cross-context interoperability; agent
     service operators SHOULD design for namespace-scoped identity with
     explicit trust relationships between domains.

  7.2.  Credential Formats

     Agent credentials bind an agent identifier to cryptographic proof
     material (public keys or equivalent) and MAY include additional
     claims such as capabilities, agent service operator identity,
     assurance level, and validity constraints.

     Credentials MUST support:

     *  Cryptographic binding between agent identity and key material, so
        that possession of the credential implies control of the
        corresponding private key.

     *  Tamper-evident representation (e.g., signed by a trusted issuer).

     *  Time-bounded validity, with explicit expiration constraints.

     *  Revocation or suspension mechanisms (see Section 9).

     Credentials SHOULD support:

     *  Structured claims for authorisation context (e.g., scope, purpose,
        or allowed actions).



  King, et al.            Expires 16 September 2026              [Page 15]


  Internet-Draft         agent-trust-auth-framework             March 2026


     *  Where the agent acts on delegated authority, representation of the
        full delegation chain (see Section 7.4 and Section 8.2).

     Suitable credential formats include X.509 certificates, JSON Web
     Tokens (JWT), CBOR Web Tokens (CWT), Verifiable Credentials (W3C VC),
     or equivalent formats that meet the requirements above.  The choice
     of format SHOULD align with the operational and performance
     constraints of the deployment environment.

  7.3.  Key Management and Proof-of-Possession

     Agent credentials MUST be bound to cryptographic keys under the
     control of the agent or its runtime environment.  To mitigate key
     compromise and support operational agility, deployments SHOULD:

     *  Use short-lived credentials with validity periods measured in
        hours or days, rather than months or years.

     *  Rotate keys and credentials frequently and automatically.

     *  Avoid embedding long-term static secrets in agent code,
        configuration, or environment variables.

     Agent authentication MUST include proof-of-possession of the private
     key corresponding to the public key in the credential.  Acceptable
     proof-of-possession mechanisms include:

     *  Digital signatures over authentication challenges or request
        content (e.g., using JOSE or COSE signature schemes).

     *  Key agreement or key confirmation protocols.

     *  Cryptographic binding in token-based schemes (e.g., DPoP for OAuth
        2.0 [RFC9449]).

     Where hardware security modules (HSMs), trusted execution
     environments (TEEs), or secure enclaves are available, private keys
     SHOULD be protected within these environments to reduce exposure.

  7.4.  On-Behalf-Of Delegation

     Agents frequently act on behalf of a user, service, or organisation.
     In such cases, credentials and authorisation tokens MUST clearly
     represent both:

     *  The agent's own identity (the immediate actor).





  King, et al.            Expires 16 September 2026              [Page 16]


  Internet-Draft         agent-trust-auth-framework             March 2026


     *  The identity of the principal on whose behalf the agent is acting
        (the authorising party).

     This separation enables relying parties to:

     *  Attribute actions to the correct principal for audit and
        accountability purposes.

     *  Apply policy based on both agent and principal identity (e.g.,
        "agent X acting for user Y may access resource Z").

     *  Enforce constraints on delegation depth and scope (see
        Section 8.2).

     Delegation relationships SHOULD be cryptographically verifiable,
     either through structured token claims (e.g., JWT "act" or "may_act"
     claims) or through chained credentials that establish a delegation
     path from the principal to the agent.

     Dual Identity for AI Agents:

     One possible model for AI agents is a dual-identity representation
     comprising the agent's own identity and the identity of its owner or
     invoking principal [I-D.ni-wimse-ai-agent-identity].  Where such a
     model is used, it may provide additional context for access control
     decisions.  Potential benefits include:

     *  Reuse of existing Role-Based Access Control (RBAC) policies
        defined for human principals, while also applying agent-specific
        constraints.

     *  Differentiation between agent capabilities (what the agent itself
        is authorised to do) and principal authorisation (what the owner
        is authorised to do), allowing security engines to make better-
        informed decisions.

     *  Clear separation of accountability: the agent's virtual identity
        remains stable across different principals, while the principal's
        identity varies based on who invoked the agent.

     Where deployments implement such a dual-identity model, both
     identities SHOULD be represented in credentials, tokens, or
     equivalent policy inputs as appropriate.  The detailed representation
     and processing model is to be discussed in more detail in a later
     version of this document.






  King, et al.            Expires 16 September 2026              [Page 17]


  Internet-Draft         agent-trust-auth-framework             March 2026


  7.5.  Credential Lifecycle and Rotation

     To support operational resilience and security hygiene, agent
     credential issuance and rotation MUST be automated and SHOULD NOT
     require manual intervention under normal operating conditions.

     Deployments SHOULD implement:

     *  Automated credential issuance upon agent initialisation or
        registration.

     *  Proactive credential renewal before expiration (e.g., renewing
        when 50-75% of the validity period has elapsed).

     *  Graceful handling of overlapping validity periods to avoid service
        disruption during rotation.

     Credential rotation events SHOULD be logged for audit and
     troubleshooting.  Revocation and suspension mechanisms are described
     in Section 9.

  8.  Authentication and Authorisation Patterns

     This section defines authentication and authorisation requirements
     for cross-domain agent interactions.  The patterns described here are
     intended to support least-privilege access control, time-bound
     authorisation, task-specific scoping, and auditability across trust
     domain boundaries.

  8.1.  Mutual Authentication

     Agent-to-agent interactions across domain boundaries MUST use mutual
     authentication, in which both the calling agent and the receiving
     agent (or gateway) authenticate each other before exchanging
     sensitive data or performing actions.

     Mutual authentication ensures that:

     *  The caller can verify the identity and trustworthiness of the
        service or agent it is invoking.

     *  The callee can verify the identity and authorisation of the caller
        before granting access or performing requested actions.








  King, et al.            Expires 16 September 2026              [Page 18]


  Internet-Draft         agent-trust-auth-framework             March 2026


     Mutual authentication SHOULD be established at the transport layer
     (for example, mutual TLS) or, where appropriate, at the application
     layer using signed requests, proof-of-possession mechanisms, or
     equivalent message protection schemes (for example, HTTP Message
     Signatures [RFC9421]).

     Where agent gateways mediate cross-domain communication, mutual
     authentication MUST be performed on both sides of the gateway:
     between the calling agent and the gateway, and between the gateway
     and the target agent or service.

  8.2.  Delegation and Call-Chain Context

     When an agent acts on behalf of a user or invokes another agent as
     part of a multi-step workflow, the call chain context MUST be
     preserved and made available to downstream relying parties.

     In Figure 2 terms, call-chain context enters at (F1), is evaluated
     and transformed during (F2), and is propagated downstream at (F4)
     (typically via transaction tokens or equivalent structured context).

     Call-chain context includes:

     *  The identity of the original requesting principal (user or
        service).

     *  The identity of each intermediary agent in the delegation chain.

     *  Constraints on delegation depth (e.g., "may delegate at most one
        level further").

     *  Scope and purpose restrictions that apply to delegated authority.

     Relying parties MUST be able to inspect and verify the call-chain
     context in order to:

     *  Attribute actions to the correct principal for audit and
        compliance purposes.

     *  Detect and prevent confused-deputy attacks and privilege
        escalation.

     *  Enforce policy based on the full delegation path (e.g., "user A
        via agent B via agent C may not access resource X").







  King, et al.            Expires 16 September 2026              [Page 19]


  Internet-Draft         agent-trust-auth-framework             March 2026


     Call-chain context SHOULD be represented using structured tokens
     (e.g., JWT with nested or chained claims) or as a sequence of
     verifiable credentials that establish the delegation path.
     Cryptographic signatures MUST bind each step in the chain to prevent
     tampering or substitution.

     Transaction Tokens [I-D.ietf-oauth-transaction-tokens] may provide
     one useful mechanism for encoding and protecting workflow-related
     context across trust domains in multi-step interactions.  Depending
     on deployment requirements, such tokens may carry task, transaction,
     or purpose-related context that can assist downstream policy
     evaluation.  The exact representation of delegation chains, workflow
     state, and related semantics is deployment-specific and to be
     discussed in more detail in a later version of this document.

  8.3.  Policy Enforcement and Decision Points

     Access control decisions in cross-domain agent ecosystems require
     dynamic evaluation of policy based on agent identity, principal
     identity, call-chain context, resource attributes, and environmental
     conditions.

     Deployments SHOULD implement a clear separation between:

     *  Policy Enforcement Points (PEPs): components that intercept
        requests and enforce access decisions (e.g., agent gateways, API
        gateways, or runtime enforcement layers).

     *  Policy Decision Points (PDPs): components that evaluate policy
        rules and return authorisation decisions to PEPs.

     PDPs SHOULD support policy evaluation based on:

     *  Agent and principal identity.

     *  Delegation chain and call-chain depth.

     *  Resource being accessed and requested operation.

     *  Contextual attributes (e.g., time of day, source network,
        assurance level).

     Policy languages and decision engines are not standardised by this
     framework; however, policies MUST be enforceable consistently across
     gateways and relying parties within a trust domain, and SHOULD be
     auditable and versioned for governance and compliance purposes.





  King, et al.            Expires 16 September 2026              [Page 20]


  Internet-Draft         agent-trust-auth-framework             March 2026


  8.4.  Least-Privilege and Fine-Grained Access Tokens

     Access tokens issued to agents MUST implement the principle of least
     privilege by constraining:

     *  Scope: the set of resources or operations the token grants access
        to (e.g., "read messages in project X", "invoke workflow Y").

     *  Validity period: tokens SHOULD have short lifetimes (measured in
        minutes to hours) to limit exposure in the event of compromise.

     *  Purpose or task context: tokens MAY be bound to a specific task or
        workflow instance, and MUST NOT be reusable across unrelated
        operations unless explicitly permitted by policy.

     Fine-grained scoping reduces the impact of token leakage or misuse
     and supports auditability by creating a clear link between tokens and
     the tasks they authorise.

     Access tokens SHOULD be issued dynamically in response to specific
     task triggers (e.g., user initiation of a workflow, scheduled job
     execution, or event-driven invocation) rather than being provisioned
     statically at agent deployment time.

     Token formats SHOULD support structured scope representation (e.g.,
     OAuth 2.0 scopes, RBAC roles, or attribute-based claims) and MUST
     include expiration timestamps.  Deployments MUST support one or more
     revocation or status-validation mechanisms (e.g., token
     introspection, revocation endpoints, issuer-side deny lists, or
     equivalent controls) to enable lifecycle management (see Section 9).

     Cross-Domain Token Exchange:

     When agents interact across trust domains, access tokens issued in
     one domain often cannot be used directly in another domain.  OAuth
     2.0 Token Exchange [RFC8693] provides one established mechanism for
     exchanging a token from Domain A for a token acceptable in Domain B,
     subject to policy and trust relationships between the domains.

     Related OAuth extensions may be relevant in specific cross-domain
     scenarios:

     *  Identity Chaining [I-D.ietf-oauth-identity-chaining] may be
        applicable where identity information must be conveyed across
        trust domains in a form acceptable to a downstream authorisation
        system.





  King, et al.            Expires 16 September 2026              [Page 21]


  Internet-Draft         agent-trust-auth-framework             March 2026


     *  Identity Assertion Authorisation Grant
        [I-D.ietf-oauth-identity-assertion-authz-grant] may be relevant
        where identity assertions are used as inputs to obtain access
        tokens in federation scenarios.

     Deployments using OAuth-based authorisation SHOULD consider these
     existing standards before creating bespoke token exchange or
     assertion mechanisms.  Detailed profiling guidance for agent-specific
     use of these extensions is to be discussed in more detail in a later
     version of this document.

     In the reference sequence (Figure 2), this corresponds to:

     *  (F1) Subject Token presented by the calling side to the gateway.

     *  (F2) Token exchange request by the gateway/authorisation
        component.

     *  (F3) Issuance of a destination-domain exchanged access token.

     *  (F4) Use of the exchanged access token (and workflow context) to
        access destination resources.

  8.5.  Explicit Workflow and Step-Up Authentication

     In multi-step agent workflows, explicit workflow identifiers and
     step-up authentication MAY be required to ensure that sensitive
     actions are authorised at an appropriate assurance level.

     Explicit workflow context includes:

     *  A workflow or session identifier that links related agent
        interactions.

     *  The current step or phase within the workflow.

     *  Constraints on permissible transitions between steps.

     Step-up authentication is a mechanism in which an agent or user is
     required to re-authenticate or provide additional proof before
     performing a high-risk or sensitive operation.  For example:

     *  A low-assurance token may permit read-only operations, while write
        or delete operations require a higher-assurance token obtained
        through step-up.

     *  Delegation to a third-party agent may require explicit user
        consent or re-authentication.



  King, et al.            Expires 16 September 2026              [Page 22]


  Internet-Draft         agent-trust-auth-framework             March 2026


     Step-up requirements SHOULD be expressed in policy and enforced by
     PDPs and PEPs.  Workflow and step-up context SHOULD be included in
     call-chain tokens to ensure that downstream relying parties can
     verify compliance with workflow constraints.

  9.  Revocation, Rotation, and Lifecycle

     Credential lifecycle management is critical to the security and
     operational resilience of cross-domain agent ecosystems.  This
     section defines requirements for credential issuance, rotation,
     revocation, and suspension, with an emphasis on automation, short
     validity periods, and clear operational semantics.

     Relative to Figure 2, lifecycle controls govern tokens and
     credentials produced in (F2)/(F3), consumed in (F4), and continuously
     validated via (F5).

  9.1.  Automated Credential Issuance

     Agent credentials SHOULD be issued automatically as part of agent
     initialisation, registration, or onboarding processes.  Manual
     credential provisioning introduces operational overhead, increases
     the risk of misconfiguration, and delays agent deployment.

     Automated issuance mechanisms MUST:

     *  Authenticate the requesting agent or agent service operator before
        issuing credentials.

     *  Bind the issued credential to the agent's identity and
        cryptographic keys (see Section 7).

     *  Apply policy constraints (e.g., validity period, scope, trust
        domain) at issuance time.

     *  Log issuance events for audit and compliance purposes (see
        Section 10).

     Credential issuers MAY implement attestation or proof-of-identity
     requirements (e.g., requiring the agent to demonstrate control of a
     pre-registered public key, or to provide a bootstrapping token issued
     by a trust domain authority).









  King, et al.            Expires 16 September 2026              [Page 23]


  Internet-Draft         agent-trust-auth-framework             March 2026


  9.2.  Credential Rotation

     To limit exposure in the event of key compromise and to support
     cryptographic agility, agent credentials SHOULD be rotated
     frequently.  Rotation intervals depend on the threat model and
     operational context, but deployments SHOULD target validity periods
     measured in hours or days rather than months or years.

     Automated rotation MUST be supported without manual intervention.
     Rotation mechanisms SHOULD:

     *  Begin renewal before credential expiration (e.g., when 50-75% of
        the validity period has elapsed) to avoid service disruption.

     *  Support overlapping validity periods for old and new credentials
        during the rotation window, allowing graceful transition without
        breaking in-flight requests.

     *  Re-authenticate the agent and verify continued authorisation
        before issuing renewed credentials.

     *  Log rotation events and preserve a historical record of credential
        issuance for forensic analysis (see Section 10).

     Rotation SHOULD be triggered by time-based expiration, but MAY also
     be triggered by policy events (e.g., change of agent role, detected
     anomaly, or administrative action).

  9.3.  Revocation

     Revocation is the permanent invalidation of a credential before its
     natural expiration.  Revocation is necessary in response to key
     compromise, agent decommissioning, policy violation, or other
     security events.

     Revocation mechanisms MUST:

     *  Provide timely propagation of revocation status to relying
        parties.  Acceptable mechanisms include Online Certificate Status
        Protocol (OCSP), Certificate Revocation Lists (CRLs), token
        revocation endpoints, or equivalent real-time revocation services.

     *  Support query-based revocation checking by relying parties (i.e.,
        relying parties MUST be able to verify whether a credential is
        revoked before accepting it).

     *  Generate audit evidence when credentials are revoked, including
        the reason for revocation and the time of revocation.



  King, et al.            Expires 16 September 2026              [Page 24]


  Internet-Draft         agent-trust-auth-framework             March 2026


     Deployments using short-lived credentials (e.g., validity periods of
     hours or days) MAY rely on expiration rather than explicit revocation
     for routine lifecycle management, reserving revocation for emergency
     or high-severity events.  However, a revocation mechanism MUST still
     be available for such events.

     Revocation SHOULD be irreversible.  If an agent requires new
     credentials after revocation, it MUST re-authenticate and obtain a
     fresh credential through the issuance process.

  9.4.  Suspension and Resumption

     Suspension is the temporary invalidation of a credential, typically
     in response to a transient condition (e.g., suspected anomaly,
     pending investigation, or administrative hold).  Unlike revocation,
     suspension MAY be reversible.

     Suspension mechanisms SHOULD:

     *  Use the same propagation and checking mechanisms as revocation
        (e.g., OCSP, CRLs, or token introspection endpoints).

     *  Distinguish suspended credentials from revoked credentials in
        status responses, enabling relying parties to apply appropriate
        policy (e.g., temporary denial vs. permanent rejection).

     *  Log suspension and resumption events for audit purposes.

     Resumption (re-activation of a suspended credential) SHOULD require
     explicit administrative action or policy evaluation, and MUST be
     logged.  Resumed credentials retain their original expiration time;
     suspension does not extend validity.

  9.5.  Operational Semantics and Grace Periods

     To avoid service disruption during lifecycle transitions, deployments
     SHOULD implement grace periods and operational best practices:

     *  Clock skew tolerance: relying parties SHOULD tolerate small clock
        skew (e.g., +/- 5 minutes) when validating credential expiration
        times.

     *  Caching and refresh intervals: relying parties that cache
        revocation or suspension status SHOULD refresh cached data
        frequently (e.g., every few minutes for high-assurance
        environments, or hourly for lower-risk contexts).





  King, et al.            Expires 16 September 2026              [Page 25]


  Internet-Draft         agent-trust-auth-framework             March 2026


     *  Fallback and failover: if revocation status cannot be checked
        (e.g., due to network failure or service outage), deployments
        SHOULD implement a fail-safe policy (e.g., reject credentials when
        revocation status is unavailable in high-assurance environments,
        or accept credentials with logging and delayed verification in
        lower-risk environments).

     Operational semantics for lifecycle events (issuance, rotation,
     revocation, suspension, resumption) SHOULD be documented and
     consistent across trust domains to ensure interoperability.

  10.  Auditability, Transparency, and Evidence

     Cross-domain agent interactions often involve sensitive data, high-
     value transactions, or regulated decision-making processes.  To
     support accountability, compliance, and operational troubleshooting,
     this framework requires that agent interactions produce verifiable
     evidence available to operators and auditors.

  10.1.  Audit Requirements

     Agent platforms, gateways, and relying parties MUST generate audit
     logs for security-relevant events, including:

     *  Authentication and authorisation decisions (successful and
        failed).

     *  Credential issuance, renewal, revocation, and suspension events.

     *  Delegation and call-chain construction.

     *  Access to sensitive resources or execution of high-risk
        operations.

     *  Policy evaluation decisions and any policy violations or
        anomalies.

     Audit logs MUST include sufficient context to support forensic
     analysis and compliance reporting, including:

     *  Timestamp (with time zone or UTC offset).

     *  Agent identity and principal identity (if applicable).

     *  Call-chain context (see Section 8.2).

     *  Resource or operation being accessed.




  King, et al.            Expires 16 September 2026              [Page 26]


  Internet-Draft         agent-trust-auth-framework             March 2026


     *  Authorisation decision and policy identifier.

     *  Reference flow label(s) for the transaction path (e.g., F1-F6 from
        Figure 2), where available.

     Audit logs SHOULD be tamper-evident (e.g., signed, hash-chained, or
     committed to an append-only transparency log) to ensure integrity and
     non-repudiation.

  10.2.  Transparency and Evidence Services

     In deployments where auditability and public accountability are
     critical (e.g., regulated industries, cross-organisational
     collaborations, or high-assurance environments), operators MAY
     integrate transparency services such as:

     *  Certificate Transparency (CT) logs for agent credentials.

     *  Verifiable data structures (e.g., Merkle trees) for tamper-evident
        audit trails.

     *  Third-party attestation or notarisation services that provide
        independent verification of agent actions or credential lifecycle
        events.

     Transparency services enable:

     *  Detection of mis-issued or unauthorised credentials.

     *  Independent audit of agent behaviour and delegation chains.

     *  Compliance with regulatory requirements for auditability and
        traceability (e.g., GDPR Article 22 for automated decision-making,
        or financial services audit requirements).

     This framework does not mandate specific transparency log formats or
     protocols, but recommends that any transparency service integrated
     into an agent ecosystem support cryptographic proof of inclusion and
     consistency.

  10.3.  Decryption and Inspection for Compliance

     In some regulatory or enterprise environments, operators or
     compliance teams may require the ability to decrypt and inspect
     agent-to-agent traffic for security monitoring, data loss prevention
     (DLP), or regulatory compliance purposes.

     Where decryption and inspection are required, deployments SHOULD:



  King, et al.            Expires 16 September 2026              [Page 27]


  Internet-Draft         agent-trust-auth-framework             March 2026


     *  Implement inspection at controlled policy enforcement points
        (e.g., gateways or proxies) rather than passively intercepting
        encrypted traffic.

     *  Use explicit trust relationships and key escrow or key sharing
        arrangements that are disclosed to all parties and governed by
        policy.

     *  Log and audit all decryption and inspection events to ensure
        accountability and prevent misuse.

     Decryption and inspection mechanisms MUST NOT undermine the end-to-
     end integrity and authenticity guarantees provided by agent
     credentials and signed messages.  In particular:

     *  Inspection points MUST re-encrypt traffic after inspection to
        maintain cryptographic protection downstream.

     *  If an intermediary applies a new downstream signature, it MUST
        preserve verifiable evidence of the original upstream sender
        signature or attestation context so that accountability and
        provenance are not lost.

     *  Inspection MUST be authorised by policy and MUST NOT occur without
        the knowledge and consent of the trust domain authorities on both
        sides of the interaction.

     Where appropriate, operators MAY consider privacy-preserving
     inspection techniques, such as selective field decryption or other
     deployment-specific approaches.  Advanced techniques and their
     applicability are to be discussed in more detail in a later version
     of this document.

  11.  Operational Considerations

  11.1.  Relationship to OAuth Ecosystem

     This framework aligns with OAuth working group specifications for
     cross-domain authorisation and identity federation.  Deployments
     using OAuth 2.0 or OpenID Connect SHOULD prioritise existing
     extensions and profiles over proprietary mechanisms.

     OAuth specifications and drafts that may be relevant to this
     framework include:

     *  RFC 8693 [RFC8693] for token exchange between security domains.





  King, et al.            Expires 16 September 2026              [Page 28]


  Internet-Draft         agent-trust-auth-framework             March 2026


     *  Transaction Tokens [I-D.ietf-oauth-transaction-tokens] for
        carrying transaction-related context in multi-step workflows.

     *  Identity Chaining [I-D.ietf-oauth-identity-chaining] for cross-
        domain identity conveyance and related assertion patterns.

     *  Identity Assertion Authorisation Grant
        [I-D.ietf-oauth-identity-assertion-authz-grant] for using identity
        assertions as inputs to access-token issuance.

     These specifications and drafts illustrate possible building blocks
     for cross-domain authorisation, delegation, and workflow context
     handling.  Their precise application to agent-to-agent communication
     is to be discussed in more detail in a later version of this
     document.

  11.2.  OAuth Profiling for Agent-to-Agent Communication

     Deployments using OAuth 2.0 for agent communications SHOULD adopt or
     profile existing OAuth mechanisms where possible.  For example,
     [I-D.liu-oauth-a2a-profile] describes one approach to profiling OAuth
     2.0 for agent-to-agent communications, including reuse of
     transaction-related context fields for agent-specific semantics.

     Such profiles provide concrete guidance on:

     *  Token formats and claim structures for agent credentials and
        access tokens.

     *  Grant types and flows appropriate for agent initialisation,
        delegation, and cross-domain invocation.

     *  Integration with agent gateways and policy enforcement points.

     Operators SHOULD evaluate applicable profiles and contribute
     implementation experience to ongoing standardisation work.
     Additional profiling considerations are to be discussed in more
     detail in a later version of this document.

  11.3.  Deployment Patterns

     Cross-domain deployments commonly follow the patterns below.

     Same-Protocol, Different Providers:

     Agents hosted by different agent service operators (e.g., different
     cloud providers or enterprises) use the same agent-to-agent protocol
     but operate under different trust domains.  In this scenario, agent



  King, et al.            Expires 16 September 2026              [Page 29]


  Internet-Draft         agent-trust-auth-framework             March 2026


     gateways at domain boundaries handle mutual authentication,
     credential verification, token exchange (via RFC 8693 or equivalent),
     and policy enforcement, while preserving protocol compatibility end-
     to-end.

     Different Protocols with Gateway Mediation:

     Agents using different protocols (e.g., one domain uses Protocol X
     internally, another uses Protocol Y) communicate through a protocol-
     translating gateway.  The gateway acts as a relying party on both
     sides, performing mutual authentication, protocol translation, and
     policy enforcement.  Call-chain context and delegation semantics MUST
     be preserved across the gateway (see Section 8.2), and audit logs
     MUST capture the translation and policy decisions.

     Federated Multi-Domain Workflows:

     A workflow spans multiple domains, with agents in each domain
     performing subtasks and passing results to agents in other domains.
     Implementations MAY use transaction tokens or equivalent mechanisms
     to carry workflow-related context across domain boundaries.  Trust
     relationships MUST be established between domains (e.g., via pre-
     configured trust anchors or other agreed mechanisms), and each domain
     MUST enforce its own policy on inbound requests.  Additional details
     are to be discussed in more detail in a later version of this
     document.

  11.4.  Gateway Configuration and Policy

     Agent gateways are critical policy enforcement points in cross-domain
     deployments.  Operators SHOULD:

     *  Configure gateways to enforce mutual authentication on both sides
        (inbound and outbound) as described in Section 8.1.

     *  Integrate gateways with Policy Decision Points (PDPs) that
        evaluate authorisation policies based on agent identity, principal
        identity, call-chain context, and resource attributes (see
        Section 8.3).

     *  Enable audit logging and evidence emission for all gateway
        decisions (see Section 10).

     *  Implement rate limiting, anomaly detection, and abuse prevention
        mechanisms to protect against malicious or misconfigured agents.






  King, et al.            Expires 16 September 2026              [Page 30]


  Internet-Draft         agent-trust-auth-framework             March 2026


     Gateway policies SHOULD be versioned, auditable, and subject to
     governance review.  Policy updates SHOULD be tested in staging
     environments before deployment to production.

  11.5.  Interoperability and Testing

     Interoperability between agent platforms and trust domains requires
     consistent implementation of credential formats, token structures,
     policy semantics, and lifecycle operations.  Operators SHOULD:

     *  Participate in interoperability testing programs or working group
        plugfests to validate cross-domain interactions.

     *  Publish conformance statements describing supported credential
        types, token formats, policy languages, and lifecycle mechanisms.

     *  Use standardised test vectors and example flows (see Appendix A)
        to verify correct implementation of delegation chains, token
        exchange, and revocation checking.

     Interoperability issues SHOULD be reported to relevant standards
     bodies (for example, the IETF OAuth working group and relevant agent
     protocol communities) to inform future updates.

  12.  Privacy Considerations

     Cross-domain agent interactions can expose personal data, sensitive
     business context, and behavioural metadata across multiple operators.
     Deployments SHOULD apply privacy-by-design controls to identity,
     delegation, telemetry, and audit processing.

     In particular, deployments SHOULD:

     *  Apply data minimisation.  Credentials, tokens, and call-chain
        context SHOULD carry only the claims required for a specific
        transaction.

     *  Apply purpose limitation.  Identity and delegation claims SHOULD
        be scoped to an explicit task or workflow and SHOULD NOT be reused
        for unrelated processing.

     *  Avoid unnecessary disclosure of principal identity to downstream
        domains where pseudonymous or pairwise identifiers are sufficient.

     *  Limit retention of audit logs and telemetry to what is necessary
        for security, compliance, and operational purposes, consistent
        with applicable law and policy.




  King, et al.            Expires 16 September 2026              [Page 31]


  Internet-Draft         agent-trust-auth-framework             March 2026


     *  Logs, traces, and evidence services that may contain sensitive
        metadata SHOULD be protected by access controls, redaction
        policies, and compartmentalisation.

     *  Provide transparency and governance for cross-domain sharing,
        including documented legal basis, controller/processor roles, and
        cross-border transfer requirements where applicable.

     When decryption and inspection are used (Section 10.4), agent service
     operators SHOULD ensure the minimum disclosure necessary for the
     compliance use case and SHOULD log access to inspected content.

     Deployments that process personal data MUST comply with applicable
     privacy and data protection requirements in their jurisdictions.

  13.  Security Considerations

     This section summarises baseline controls and residual risks for
     cross-domain agent interactions.  The threat model is in Section 4.

     Deployments MUST:

     *  Enforce mutual authentication across domain boundaries
        (Section 8.1), including both sides of any mediating gateway.

     *  Validate proof-of-possession for presented credentials and tokens
        (Section 7.3).

     *  Call-chain context for delegated requests MUST be preserved and
        verified to mitigate confused-deputy and privilege escalation
        attacks (Section 8.2).

     *  Apply least-privilege, short-lived tokens, and explicit lifecycle
        controls (issuance, rotation, revocation, suspension) as described
        in Sections 8.4 and 9.

     *  Protect trust anchors, issuer keys, and agent private keys against
        compromise (Section 7.3), including use of hardware-backed key
        protection where available.

     *  Tamper-evident, auditable evidence MUST be generated for all
        security-relevant events (Section 10).

     Specific security risks include:

     *  Compromised gateways or intermediaries, which can become high-
        value targets and policy bypass points.




  King, et al.            Expires 16 September 2026              [Page 32]


  Internet-Draft         agent-trust-auth-framework             March 2026


     *  Incomplete revocation propagation or stale status caches, which
        can allow temporary acceptance of invalid credentials.

     *  Unauthenticated endpoint or capability bindings create a surface
        for discovery or registry poisoning (Section 6.4).

     *  Weak trust-domain onboarding or misconfigured inter-domain trust,
        which can permit token substitution or unauthorised token
        exchange.

     No single control is sufficient.  Deployments should combine
     identity, cryptographic, policy, and lifecycle controls.

     An example external risk taxonomy is provided in Appendix B for
     additional context.

  14.  IANA Considerations

     This document has no IANA actions.

  15.  References

  15.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/info/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/info/rfc8174>.

     [RFC8693]  Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
                and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
                DOI 10.17487/RFC8693, January 2020,
                <https://www.rfc-editor.org/info/rfc8693>.

  15.2.  Informative References

     [I-D.ietf-oauth-identity-assertion-authz-grant]
                Campbell, B., "Using OpenID Connect Identity Assertions as
                Authorization Grants", October 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
                identity-assertion-authz-grant-01>.






  King, et al.            Expires 16 September 2026              [Page 33]


  Internet-Draft         agent-trust-auth-framework             March 2026


     [I-D.ietf-oauth-identity-chaining]
                Schwenkschuster, O. and P. Czapiewski, "OAuth 2.0 Identity
                Chaining across Trust Domains", September 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
                identity-chaining-08>.

     [I-D.ietf-oauth-transaction-tokens]
                Hardt, D. and O. Schwenkschuster, "Transaction Tokens",
                October 2025, <https://datatracker.ietf.org/doc/html/
                draft-ietf-oauth-transaction-tokens-07>.

     [I-D.liu-oauth-a2a-profile]
                Liu, D., "OAuth 2.0 Profile for Agent-to-Agent (A2A)
                Communications", September 2025,
                <https://datatracker.ietf.org/doc/html/draft-liu-oauth-
                a2a-profile-00>.

     [I-D.ni-wimse-ai-agent-identity]
                Ni, T., "AI Agent Identity", October 2025,
                <https://datatracker.ietf.org/doc/html/draft-ni-wimse-ai-
                agent-identity-01>.

     [I-D.rrk-object-based-media-usecase]
                Ramdhany, R., Race, N., and D. King, "Use Case and
                Challenges for the Deployment of Object-Based Media across
                the Internet", March 2026,
                <https://datatracker.ietf.org/doc/html/draft-rrk-object-
                based-media-usecase>.

     [OWASP-ASI2026]
                OWASP Gen AI Security Project - Agentic Security
                Initiative, "OWASP Top 10 for Agentic Applications for
                2026, Version 2026", December 2025,
                <https://genai.owasp.org/resource/owasp-top-10-for-
                agentic-applications-for-2026/>.

     [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
                Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
                2015, <https://www.rfc-editor.org/info/rfc7515>.

     [RFC7542]  DeKok, A., "The Network Access Identifier", RFC 7542,
                DOI 10.17487/RFC7542, May 2015,
                <https://www.rfc-editor.org/info/rfc7542>.

     [RFC7643]  Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C.
                Mortimore, "System for Cross-domain Identity Management:
                Core Schema", RFC 7643, DOI 10.17487/RFC7643, September
                2015, <https://www.rfc-editor.org/info/rfc7643>.



  King, et al.            Expires 16 September 2026              [Page 34]


  Internet-Draft         agent-trust-auth-framework             March 2026


     [RFC7644]  Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E.,
                and C. Mortimore, "System for Cross-domain Identity
                Management: Protocol", RFC 7644, DOI 10.17487/RFC7644,
                September 2015, <https://www.rfc-editor.org/info/rfc7644>.

     [RFC9052]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
                Structures and Process", STD 96, RFC 9052,
                DOI 10.17487/RFC9052, August 2022,
                <https://www.rfc-editor.org/info/rfc9052>.

     [RFC9421]  Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
                Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
                February 2024, <https://www.rfc-editor.org/info/rfc9421>.

     [RFC9449]  Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
                Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
                Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
                September 2023, <https://www.rfc-editor.org/info/rfc9449>.

     [W3C.VC]   Sporny, M., Longley, D., and D. Chadwick, "Verifiable
                Credentials Data Model v2.0", November 2024,
                <https://www.w3.org/TR/vc-data-model-2.0/>.

  Appendix A.  Example Flows (Informative)

     This appendix provides non-normative examples illustrating how the
     framework can be applied in common deployment patterns.

  A.1.  Same-Protocol, Cross-Domain Invocation with Token Exchange

     1.  Agent A in Domain A receives a user task and obtains a local
         access token scoped to that task.

     2.  Agent A presents its token to Domain A's Security Token Service,
         which performs OAuth 2.0 Token Exchange [RFC8693] for Domain B.

     3.  Domain B issues a short-lived token constrained to resource,
         purpose, and delegation depth.

     4.  Agent A calls Agent B using mutual authentication; Agent B
         validates token, call-chain context, and policy before execution.

     5.  Both domains emit audit records tied to the same workflow
         context.







  King, et al.            Expires 16 September 2026              [Page 35]


  Internet-Draft         agent-trust-auth-framework             March 2026


  A.2.  Cross-Protocol Invocation Through a Gateway

     1.  Agent X (Protocol X) sends a delegated request to a gateway at
         the Domain boundary.

     2.  The gateway authenticates Agent X, validates delegation
         constraints, and enforces inbound policy.

     3.  The gateway translates protocol semantics for Protocol Y while
         preserving delegation and workflow context in signed form.

     4.  The gateway authenticates to Agent Y (Protocol Y side) and
         submits a policy-constrained request.

     5.  The gateway records translation, policy decision, and outbound
         request evidence for auditability.

  Appendix B.  Current Agentic Risk Landscape (Informative)

     This appendix provides a non-normative, time-stamped snapshot of a
     current agentic risk taxonomy to support threat modelling and control
     prioritisation.  Taxonomies evolve quickly; implementers SHOULD
     consult current source publications.

     One recent external publication, the OWASP Top 10 for Agentic
     Applications for 2026 [OWASP-ASI2026], identifies the following risk
     categories:

     *  ASI01: Agent Goal Hijack

     *  ASI02: Tool Misuse and Exploitation

     *  ASI03: Identity and Privilege Abuse

     *  ASI04: Agentic Supply Chain Vulnerabilities

     *  ASI05: Unexpected Code Execution (RCE)

     *  ASI06: Memory and Context Poisoning

     *  ASI07: Insecure Inter-Agent Communication

     *  ASI08: Cascading Failures

     *  ASI09: Human-Agent Trust Exploitation

     *  ASI10: Rogue Agents




  King, et al.            Expires 16 September 2026              [Page 36]


  Internet-Draft         agent-trust-auth-framework             March 2026


     The following high-level mapping provides one illustrative view of
     how this framework's controls may relate to the categories above:

     *  Identity and privilege controls (Section 7, Section 8.3,
        Section 8.4) are particularly relevant to ASI01, ASI02, ASI03, and
        ASI09.

     *  Token exchange, delegation-chain integrity, and task-context
        binding (Section 8.2, Section 8.4, Section 8.5) are relevant to
        ASI01, ASI02, ASI03, ASI07, and ASI09.

     *  Lifecycle controls (Section 9) are relevant to ASI03, ASI07, and
        ASI10, including rapid response to compromise and credential
        misuse.

     *  Auditability and transparency controls (Section 10) are relevant
        to ASI01, ASI05, ASI08, ASI09, and ASI10 for detection,
        investigation, and accountability.

     This appendix is informative only and reflects one external risk
     taxonomy at a point in time.  Normative requirements remain in the
     main body of this document.  The treatment of external taxonomies is
     to be discussed in more detail in a later version of this document.

  Authors' Addresses

     D. King
     Lancaster University
     Email: d.king@lancaster.ac.uk


     R. Ramdhany
     BBC
     Email: rajiv.ramdhany@bbc.co.uk


     Chunchi Peter Liu
     Huawei Technologies
     Email: liuchunchi@huawei.com












  King, et al.            Expires 16 September 2026              [Page 37]


