SCIM Agents and Agentic Applications Extension

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 6 March 2026.¶

Copyright Notice

Copyright (c) 2025 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

The SCIM protocol was originally developed to address an abundance of complex standards for describing and exchanging user information.¶

As stated in the introduction of RFC7643#Section-1.1¶

• While there are existing standards for describing and exchanging user information, many of these standards can be difficult to implement and/or use...¶

• This increases both the cost and complexity associated with organizations adopting products and services from multiple cloud providers, as they must perform redundant integration development...SCIM seeks to simplify this problem through an easily implemented specification suite...¶

With the rise of AI, agents, and agentic applications, we see another abundance of protocols emerging, with varying levels of industry adoption, as well as implementation complexity as many brilliant and enthusiastic early adopters rush to define new standards for identity interopability.¶

This includes but is not limited to:¶

• ACP¶

• A2A¶

• ANS¶

• AGNTCY¶

The intent of this SCIM extension is to offer a viable path for the industry to re-leverage the well known core SCIM specifications, as well as existing implementations of SCIM clients and SCIM servers, to solve for agent cross domain management.¶

In doing so, we can free the emerging standards in the agentic AI space to focus on truly novel concerns, instead of addressing the problems already solved by SCIM for user and groups.¶

For example, in the A2A protocol, instead of describing a very high level concept of Curated registries we could offer more concrete guidance by stating Agent Cards may be discovered by a SCIM client accessing any SCIM server that implements this extension.¶

2. Conventions

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. Definitions

Agent: A workload with its own identifier, metadata and privileges which are independent of a particular runtime environment or containing application. An agent is distinct from a traditional software workloads (lambdas, services, etc...) due to varying degrees of unpredictable behavior caused by delegation of control flow to artificial intelligence models.¶

Agentic application: An application exposing one or more agents to its users. An agentic application is similar to a traditional native or web application, in that there are pre-defined ways authenticate and interact with the application; however, as soon as the application exposes agents, there are additional considerations for managing access to that application.¶

4. Core Schema Extensions

  agentExtension
     A complex type that specifies Agent Extension configuration options.

     supported Boolean value specifying whether any aspect of the extension is supported.

     agentsSupported Boolean value specifying whether the agent resource type
                     is supported

     agenticApplicationsSupported Boolean value specifying whether the agent
                                  resource type is supported

5. Additional ResourceTypes and Schemas

This SCIM Agent extension defines additional ResourceTypes and Schemas that MAY be implemented by the service provider. If implemented, these ResourceTypes SHOULD support all SCIM operations [RFC7644]. All attributes defined in the schemas are optional unless explicitly marked as REQUIRED.¶

  {
     "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"],
     "id": "Agent",
     "name": "Agent",
     "endpoint": "/Agents",
     "description": "Agent identities",
     "schema": "urn:ietf:params:scim:schemas:core:2.0:agent",
  }

  GET /scim/v2/Agents?filter=name eq 'Helpdesk bot'

  GET /scim/v2/Agents?filter=externalId eq '8ccc535b-716d-4d32-b3e9-57c8be449c82'

  name  The name of the Agent.  REQUIRED

  displayName
     The display name of the Agent.  If displayName is unassigned,
     the name MAY be used as the display name.

  description
     The description of the Agent.

  type
     The type of agent. There are no canonical values defined
     for type, but service providers MAY choose to define the valid
     types.

  active
     A Boolean value indicating the agent's administrative status.  The
     definitive meaning of this attribute is determined by the service
     provider.  As a typical example, a value of true implies that the
     agent is running, while a value of false implies that the
     agent has been suspended.

  entitlements
     An optional complex object that indicates entitlements the agent has.
     Its form is precisely the same as that defined in Section 4.1.2 of
     {{RFC7643}}.

  roles:
     An optional complex object that indicates roles the agent assumes.
     Its form is precisely the same as that defined in Section 4.1.2 of
     {{RFC7643}}.

  groups:
     An optional read-only complex object that indicates group
     membership.  Its form is precisely the same as that defined in
     Section 4.1.2 of {{RFC7643}}.

  applications
     A complex multi-valued attribute referencing applications this agent
     shares a trust boundary with. See "Agentic Application" section of
     this document.

  <!-- TODO subject be in an extension instead of core? -->
  subject An optional attribute that clients may specify when
          provisioning an agent so that
          service providers implementing inbound token federation
          may correlate the agent with the `sub` claim in
          an inbound token from an OpenID connect provider.

  <!-- TODO should protocols be in an extension instead of core? -->
  protocols
     A complex attribute that informs service providers of the
     various communication protocols an agent may support.
     This information can help service providers automatically
     support agent to agent or human to agent communication scenarios.
     An agent that supports no protocols is understood to the service provider
     to not be directly accessible. For example, when an agent can only
     be accessed via its containing agentic application.

     The following sub-attributes are defined.

        type The type of the protocol. A number of canonical values
             are provided based on known agent protocols. They are:
             A2A, OpenAPI, MCP-Client, MCP-Server

        <!-- TODO  example values per spec type -->
        specificationUrl The URL the service provider may retrieve the
                         specification document describing the agent's specific
                         information for that protocol.


  <!-- TODO should owners be in an extension instead of core? -->
  parent
     A complex attribute that defines the parent Agent of this
     Agent if the service provider supports hierarchies of
     agents.  The following sub-attributes are defined.

     value  The ID of the agent that is the parent of this
        Agent in the hierarchy.

     $ref  A URI reference to the Agent that is the parent of this
        Agent in the hierarchy.

     display  The display name of the Agent that is the parent of
        this Agent in the hierarchy.

  <!-- TODO should owners be in an extension instead of core? -->
  owners
     A complex multi-valued attribute that defines the User or Group objects
     that are owners of this Agent.  OPTIONAL.  The following sub-attributes are
     defined for each value object.

     value  The ID of the User that owns this Agent.

     $ref  A URI reference to the User that owns this Agent.

     display  The display name of the user that owns this Agent.

6. Schema JSON Representations

7. Security Considerations

• fill out¶

8. IANA Considerations

This document has no IANA actions.¶

9. Change Log

-00¶

• Initial draft extension.¶

10. References

Appendix A. Acknowledgments

We would like to thanks the authors of the SCIM Extension for Privileged Access Management and Device Schema Extensions to the SCIM model which served as excellent guidance on how to document proposed extension to the SCIM protocol.¶

Additionaly, we would like to thank all the contributors the emerging agent standards which inspired this extension, including:¶

• Agent communication protocol¶

• Agent 2 Agent¶

• Agent name service¶

• AGNTCY directory¶

Author's Address