Return-Path: X-Original-To: scim@mail2.ietf.org Delivered-To: scim@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 541A5DCCF6CC for ; Wed, 15 Apr 2026 07:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1776263738; bh=G/LTpcwnVQknbpQZlGk5HTF+GfuDOkDWpaU27RMPIQw=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=IyD5Sc20QqT5N4yVpOJg+JpXiGjo5ptCtDEFp+NCDiKbLMzGI7Et5LvCzm0H3sx6m heIwgsUR82pGan+1ILFHzJ/ZvVskEtZs1GSyf9KbWvyvh8jWVmT96G6Xg6mpNBiSA1 Lv5lB7diaBjD7M17D8gMyR9bQAZ8Lbeg+KDY0RS0= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbNWfvdGFUmw for ; Wed, 15 Apr 2026 07:35:36 -0700 (PDT) Received: from mail-yx1-xb12d.google.com (mail-yx1-xb12d.google.com [IPv6:2607:f8b0:4864:20::b12d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 19196DCCF54F for ; Wed, 15 Apr 2026 07:35:01 -0700 (PDT) Received: by mail-yx1-xb12d.google.com with SMTP id 956f58d0204a3-651c7ddf514so3569484d50.1 for ; Wed, 15 Apr 2026 07:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776263700; x=1776868500; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=ij8ahNgX0Gbfe2NnO6B1WajgopTbbTgXd5fEncUyXew=; b=atOuaWgMtuWpTNuAXuQFNCmgm2Kql4jmlLxUCgl9ERXZ0cte8UUz//2sLfoOC2JvXL Ko+Hk23NVg/jAYwLg6+M7wqOZ1JpIYA9LMtXealIpKWWqV4rMHhjczq7he6RShdUTGBM xNmiO8sZx8sQ9gOkrAFWVqXrRsnlo1r/Y0CcjYVmKSTm/ZRwjVBhhR0ho12yZLY0ZnbU dv5FcqWKWQweHzcmAT0yfbhf6OBBXfBBZgSH2uJLQwM/ggVj6yeFZAqDQa3tOvRxvGAm qeViSNR2UwT5o0l+iSB/cpRt5tYz4LHXICtDu8YHgVLJXZAirHBynzrULwyaJ6QDUxax UaWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776263700; x=1776868500; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ij8ahNgX0Gbfe2NnO6B1WajgopTbbTgXd5fEncUyXew=; b=VtPuQ0Ntdac3FyoJHigZab2Ikd5W9dMGdCeycwhWDfom+21bu1srK8QRfS4ewccQlH eW5kj2cqSyiM6UGnXcHTwXzZYbN4XunPXfehFutf3OBHByx59/JP9me7USqQOqcnHm/k zN5AnajL+B2lVdRozL4VyMXq4h4FGFbDfN1/6UourH9+zMuKti74R/5J2NWlk0/IOswB mSSpnmDnRb45okC64G6jaOA5928AqFpH7fKtJ1b3/PBdcvkaukRSz3graMey5PCfOrgq wPNoAHDRM4TXwdA8vhh0WZw3mh8TX5dv+MQArQS35V75/kY+Y0sqzaH0XES509pCM10i ALbw== X-Forwarded-Encrypted: i=1; AFNElJ9e4eO72XKib0PGpis4F9heosxcOelSYmiyzPyYb/cOx2qatqcHx2tm/KGk4BjkvAOhMBoB@ietf.org X-Gm-Message-State: AOJu0YwOHnclxq8bzGTaaeLZ4xS9ou3Gs3iD4uNJ9F6FBIj3Xqg1jTEF DfR+vahOJIZqXIG7400vAgoVELtWfAM4zJbPCDTY4e9Yma8HBNWOit1GzCQrPA== X-Gm-Gg: AeBDievkLiowP8g6fO7uJ3WK4/kZzZ82FOTnfUGd8v8ZmC9fbKckItqP3z4kAGTkhfl 7Gpn0WAu+gNkVPbihqdFY15PJWCab+UPyL4UmUMLP7A4lpBvBrTks5oKhfZGx+DyIRM4J5eJINJ LPSZQ2GvzfPJFE7A9vi0ZJOUnwP5Is+K1c7L9fGz0EpIwGAUmctlvBmZbw/q4JlfdnBIW7Y7MMa luy8g5v2bTSOhpcwkfJ7K1EL3qCytv058atqpd+gcfGCWmyoLdA0XeoE4UlFCl9SN2ysVUdzYyk IftnqSwPEOqeosseccug2eW9rKSA0z34c6Ol10Q+nkfSb64lkBb6DvxZgS4fboZ5/2VPeqQXcAv g0WX+9QpafmPJGzfhcY1X4TZ40zEYhZ312I+hABbyp5KeRMzRd4HjmKmPz9pyI36TU5F8j01ktK T0HKCaDDSiwkKuQtG4eH7A0XuQUfqZntoecmPTCUnDRWphCpLy3g== X-Received: by 2002:a05:690e:4853:b0:650:88fa:f5d0 with SMTP id 956f58d0204a3-65198c00a4fmr14453454d50.65.1776263700372; Wed, 15 Apr 2026 07:35:00 -0700 (PDT) Received: from smtpclient.apple ([2600:8807:c980:3d:b4fb:a5b3:1587:c6e1]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-652e479d403sm802611d50.16.2026.04.15.07.34.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Apr 2026 07:34:59 -0700 (PDT) From: jim pasquale Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A01CED70-4B63-4B68-A4FA-59175BAF17F9" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.21\)) Date: Wed, 15 Apr 2026 10:34:27 -0400 In-Reply-To: To: Pamela Dingle References: X-Mailer: Apple Mail (2.3731.700.6.1.21) Message-ID-Hash: UFSHSYF5M4K7ICJAPLMIRH3GTLI7UHZX X-Message-ID-Hash: UFSHSYF5M4K7ICJAPLMIRH3GTLI7UHZX X-MailFrom: jimpasquale@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-scim.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Ismael Kazzouzi , "scim@ietf.org" , "danny.zollner@okta.com" , "macy.abbey@okta.com" , Mark Wahl X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bscim=5D_Re=3A_=5BEXTERNAL=5D_SCIM_for_AI_Agents=3A_Use_Cases_fo?= =?utf-8?q?r_Discussion?= List-Id: Simple Cloud Identity Management BOF Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_A01CED70-4B63-4B68-A4FA-59175BAF17F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 Pam, spot on. > On Apr 14, 2026, at 4:26 PM, Pamela Dingle = wrote: >=20 > Hi all, >=20 > My current thoughts (fwiw) on the use cases are as follows: >=20 > We can't not do #1. While many kinds of agents will be counted and = authenticated as workloads, it is highly likely that some agents will be = counted and authenticated as if they were humans. The canonical example = here is the "digital co-worker" construct - human co-workers may wish to = assign work to, authorize, or communicate with a digital co-worker in = all the same ways they collaborate with fellow humans. That means that = the digital co-worker will need to be populated in people pickers, email = autofills, and other historically directory-backed UX elements across = multiple cross-domain resources. Any of those kinds of elements that = are SCIM backed will need to "just work". This puts implementers = between a rock and a hard place right now because the only option that = doesn't break all the interfaces would be to use the User resource type = for agents. We as a working group need to decide how agents can = co-exist in situations where the standing presumption has been that = non-human entities are never part of active collaboration. =20 > Use case #4 should be complimentary with work on agent cards here: = https://github.com/Agent-Card/ai-card/pull/27. It may be that SCIM = aligns with agent card schema for attribute naming. It could be that a = reference to the card becomes a standardized attribute within a SCIM = agent resource. =20 > Use case #7 could be a good option for applying a lightweight = abstraction layer over multiple agent registries. Managing every phase = of available, approved and instantiated agents across multiple = registries is going to look an awful lot like a meta-directory problem. = If there are other standardization efforts here it would be great to = catalog them. >=20 > I am 100% in support of "less is more" - the sooner we make a proposal = the sooner we can get feedback from those who are expecting to represent = agents in existing traditional UX situations. =20 >=20 > Cheers, >=20 > Pam >=20 > From: Ismael Kazzouzi > > Sent: Thursday, April 2, 2026 9:10 AM > To: scim@ietf.org >; danny.zollner@okta.com = >; Pamela Dingle = >; = macy.abbey@okta.com >; Mark Wahl > > Subject: [EXTERNAL] SCIM for AI Agents: Use Cases for Discussion > =20 > You don't often get email from ismael.kazzouzi@gmail.com = . Learn why this is important = =09 > Hi all, >=20 > Following the productive discussion at IETF 125 = , the SCIM Agentic Schema = workstream (Pam Dingle, Macy Abbey, Mark Wahl, Danny Zollner and Ismael = Kazzouzi) is working toward a consolidated draft. Before we bring that = draft forward, several participants rightly emphasized that well-defined = use cases and clear terminology should come first.=20 >=20 > This email is that step: start with the problem, keep the initial = scope narrow, and define what we mean. So below we lay out the use cases = we're considering and invite the group to challenge, refine, or add to = them. >=20 > Feedback reminder from the session: >=20 > "Use cases first, draft second". Multiple participants (Bjorn, Justin, = Grace, Chris) emphasized that well-defined use cases and clear = terminology must come before a specification draft. > "Less is more". Macy (via chat) cautioned against feature creep in the = initial draft. > Durability concern. SCIM has natural latency; whether it fits very = ephemeral agent instantiations is an open question. > Class vs. instance. Is SCIM representing the agent template/class or a = specific running instance? Remains unresolved. >=20 >=20 > Terminology (Working Definitions) >=20 > For the purpose of these use cases, we use "agent" broadly to mean a = non-human software entity that acts autonomously or on behalf of a user, = and that requires identity, lifecycle management, or access governance = beyond what OAuth client registration alone provides. We intentionally = avoid a narrow definition at this stage. The use cases below are meant = to stress-test where the boundaries should be. >=20 > We also distinguish: > Agent class: a template or type of agent that can be instantiated = (e.g., "Acme Travel Assistant v2") > Agent instance: a specific running instantiation of an agent class, = bound to a context (e.g., a particular user's session or a particular = Kubernetes pod) >=20 > Whether SCIM should model one or both is an open question we'd like = input on. >=20 >=20 > Use Cases > UC1: Agents Participating in Existing IAM Systems > Autonomous agents that request privileges and act as primary actors in = enterprise systems should participate in existing SCIM-based identity = and access transactions alongside users but must be distinguishable from = them. >=20 > An enterprise manages access to shared resources (document = repositories, cloud projects, APIs) through groups provisioned via SCIM. = When an agent needs access to one of these resources, an IDP = administrator adds the agent to the same access group that governs human = access. The group now contains both human and agent members. = Administrators list, audit, and manage membership uniformly regardless = of member type. The agent goes through the same approval workflow as a = user. At the same time, compliance teams can filter group membership by = resource type to answer questions like "which agents have access to our = production environment?" or "how many non-human identities hold admin = privileges?" >=20 > Without a standardized agent resource type, organizations represent = agents as pseudo-users, mirroring the legacy Active Directory service = account pattern and therefore losing the ability to distinguish them. = This leads to audit blind spots, policy gaps (e.g., no way to enforce = "agents may not hold break-glass admin roles" at the resource-type = level), lifecycle failures when agent decommissioning doesn't follow the = same workflows as user offboarding, and governance sprawl as separate = systems are built to manage agent access alongside SCIM-managed user = access. >=20 > Why SCIM: Groups already support heterogeneous member types, and the = $ref and group.members.type sub-attributes allow identifying the = resource type of each member. A standardized agent resource type means = agents can be provisioned, added to groups, governed, and audited = through the same SCIM pipeline used for users while remaining = distinguishable at every layer. >=20 > UC2: Enterprise Agent Fleet Provisioning > An enterprise deploys a fleet of AI agents (e.g., an HR assistant, a = sales copilot, an IT support bot). The identity team needs to provision = these agents into target SaaS applications through the same IDP and SCIM = pipeline they already use for users. > This includes creating the agent identity, assigning it to groups that = control resource access, and eventually disabling or removing it. >=20 > SCIM client: Identity Provider (e.g., Entra ID, Okta) > SCIM service provider (server): Target SaaS application (e.g., = Atlassian, Salesforce) >=20 > Why SCIM: Reuses existing provisioning infrastructure. The agent = lifecycle (create, update, disable, delete) mirrors user lifecycle = operations that SCIM already handles. >=20 > UC3: Agent-to-Person Entitlement Relationships > An enterprise wants to control which users a specific agent can act on = behalf of, and with what level of access. For example: 25 people are = entitled to use GitHub Copilot within a GitHub EMU organization. Of = those 25, only 10 should have Copilot act on their behalf when accessing = data in Atlassian. And within those 10, the entitlements may differ per = user: user 1 gets readWrite to Confluence, user 2 gets readOnly to Jira. >=20 > This raises the question of how these relationships are represented. = Is this tracked on the agent resource, on the user resource, or on some = other resource type? Is this an entitlement model where the agent has = entitlements to operate on users' behalf, or where users have = entitlements to interface with agents? These are open questions we'd = like input on. >=20 > When a user leaves the organization, any agents entitled to act on = their behalf must be discoverable and the relationship must be = decommissioned as part of offboarding. >=20 > SCIM client: Identity Provider or Identity Governance system > SCIM service provider: Application that hosts the agent or the = resource being accessed >=20 > Why SCIM: SCIM already models relationships between resources. = Extending this to agent-user entitlement relationships enables = governance over who an agent can act for and with what scope. >=20 > UC4: Agent Protocol Discoverability > An enterprise has provisioned several agents from different vendors. A = consuming system or another agent needs to discover what protocols a = given agent supports (e.g., A2A, MCP, SPIFFE, OAuth) and how to reach = it. The agent's SCIM record could include or reference metadata such as = an agent card URL, supported protocol identifiers, or endpoint URIs. > SCIM client: Identity Provider provisioning agent metadata > SCIM service provider: Agent registry, application directory, or = agent runtime platform >=20 > Why SCIM: SCIM is already the system of record for identity metadata. = Adding discoverable protocol capabilities avoids building a parallel = discovery mechanism for agents that are already provisioned via SCIM. >=20 > UC5: SPIFFE-Based Workload Identity Provisioning > Consider an organization uses SPIFFE for workload attestation; when = the administrator approves a new AI agent for deployment, the agent's = SPIFFE registration entry (SPIFFE ID, attestation selectors such as k8s = labels, cloud metadata, image hashes) needs to be provisioned into the = SPIFFE server (e.g., a SPIRE server or a Workload Identity Provider). > The enterprise wants to manage this through the same SCIM pipeline = used for users and OAuth clients, rather than maintaining a separate = provisioning system. This is explicitly a human/admin-controlled = process. It applies in scenarios where template-based or = federation-based approaches are not desirable. For instance, when an = organization needs fine-grained administrative control over which agent = identities are registered, based on real-world customer requirements for = compliance or policy enforcement. > The provisioning can occur within a single trust domain (admin = provisions an agent identity into their own SPIFFE server) or across = trust domains (admin provisions an agent identity from an external = partner into a federated SPIFFE trust domain). It is important to = distinguish between provisioning a registration entry (the right to an = identity, including its attestation selectors) and provisioning a = template (a reusable pattern from which multiple registration entries = can be created). Both may be valid use cases, and we'd like input on = whether SCIM should support one or both. > SCIM client: Identity Provider or Identity Governance platform (the = admin-facing system) > SCIM service provider: SPIFFE server / SPIRE server / Workload = Identity Provider (WIDP) > Why SCIM: SCIM provisions the right to an identity (the registration = entry), not the credential itself. SPIFFE issues credentials at runtime = after attestation. This cleanly separates provisioning from credential = issuance and tests the extensibility of the agent schema to non-OAuth = identity models. SCIM doesn't replace SPIRE's registration API -- it = sits in front of it. >=20 > UC6: Fleet-Wide SPIFFE Selector Update on Infrastructure Change > An organization has 200 agents registered as SPIFFE workloads, each = with attestation selectors tied to their deployment environment (e.g., = Kubernetes namespace labels, cloud instance metadata, container image = hashes). An infrastructure change occurs: the team migrates from one = Kubernetes cluster to another, or rotates to a new set of signed = container images. The SPIFFE identities remain the same, but the = attestation selectors that prove "this workload is who it claims to be" = must be updated across the entire fleet. Without this update, agents = will fail attestation at runtime and lose their credentials. > SCIM client: Identity Provider or infrastructure automation platform > SCIM service provider: SPIFFE server / SPIRE server / Workload = Identity Provide. > Why SCIM: This is a bulk update operation on provisioned identity = metadata; exactly the kind of operation SCIM is built for. An IDP can = issue a SCIM PATCH across the affected agent entries to update selectors = without touching the SPIFFE IDs or disrupting the agents' logical = identities. Doing this through a unified SCIM pipeline avoids the need = for operators to script directly against SPIFFE server APIs or maintain = a separate bulk-management tool for workload identity. > UC7: Agent Governance and Status Tracking > Before an agent is activated in an enterprise, it must go through an = approval workflow. The enterprise needs to track agents that are pending = approval, approved but not yet instantiated, active, suspended, or = disallowed by policy. This goes beyond the binary active/inactive model = used for users. > SCIM client: Identity Governance platform > SCIM service provider: Agent registry or application directory > Why SCIM: Governance and status tracking are lifecycle operations. = Rather than building a separate governance system for agents, extending = SCIM's existing model keeps agent management unified with user = management. >=20 > We welcome all feedback on the mailing list. If you'd like to join the = workstream meetings, reach out to any of us directly. >=20 > Best, > Pam, Danny, Macy, Mark, Ismael >=20 > _______________________________________________ > scim mailing list -- scim@ietf.org > To unsubscribe send an email to scim-leave@ietf.org --Apple-Mail=_A01CED70-4B63-4B68-A4FA-59175BAF17F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii +1 Pam, spot = on.

On Apr 14, 2026, at 4:26 = PM, Pamela Dingle <Pamela.Dingle=3D40microsoft.com@dmarc.ietf.org> = wrote:

Hi all,

My current thoughts (fwiw) on the use cases are as = follows:

  1. We can't not do #1.  While many kinds of = agents will be counted and authenticated as workloads, it is highly likely that = some agents will be counted and authenticated as if they were = humans.  The canonical example here is the "digital co-worker" = construct - human co-workers may wish to assign work to, authorize, or = communicate with a digital co-worker in all the same ways they = collaborate with fellow humans.  That means that the digital = co-worker will need to be populated in people pickers, email autofills, = and other historically directory-backed UX elements across multiple = cross-domain resources.  Any of those kinds of elements that are = SCIM backed will need to "just work".  This puts implementers = between a rock and a hard place right now because the only option that = doesn't break all the interfaces would be to use the User resource type = for agents.  We as a working group need to decide how agents can = co-exist in situations where the standing presumption has been that = non-human entities are never part of active = collaboration.  
  2. Use = case #4 should be complimentary with work = on agent cards here:  https://github.com/= Agent-Card/ai-card/pull/27.  It may be that SCIM aligns with = agent card schema for attribute naming.  It could be that a = reference to the card becomes a standardized attribute within a = SCIM agent resource.  
  3. Use case #7 could be a good option for applying = a lightweight = abstraction layer over multiple agent registries.  Managing = every phase of available, approved and instantiated agents across = multiple registries is going to look an awful lot like a meta-directory = problem.  If there are other standardization efforts here it would = be great to catalog them.

I = am 100% in support of "less is more" - the sooner we make a proposal the = sooner we can get feedback from those who are expecting to represent = agents in existing traditional UX situations.  

Cheers,

Pam

From: Ismael Kazzouzi = <ismael.kazzouzi@gmail.com>= ;
Sent: Thursday, April 2, 2026 9:10 = AM
To: scim@ietf.org <scim@ietf.org>; danny.zollner@okta.com <danny.zollner@okta.com>; = Pamela Dingle <Pamela.Dingle@microsoft.com>; macy.abbey@okta.com <macy.abbey@okta.com>; Mark = Wahl <Mark.Wahl@microsoft.com>Subject: [EXTERNAL] SCIM for AI Agents: Use Cases for = Discussion
 
You don't often = get email from ismael.kazzouzi@gmail.com. Learn why this is = important
Hi all,

Following the = productive discussion at IETF 125, the SCIM Agentic Schema = workstream (Pam Dingle, Macy Abbey, Mark Wahl, Danny Zollner and Ismael = Kazzouzi) is working toward a consolidated draft. Before we bring that = draft forward, several participants rightly emphasized that well-defined = use cases and clear terminology should come = first. 

This email is = that step: start with the problem, keep the initial scope narrow, and = define what we mean. So below we lay out the use cases we're considering = and invite the group to challenge, refine, or add to = them.

Feedback reminder = from the session:

  • "Use cases first, = draft second". Multiple participants (Bjorn, Justin, Grace, Chris) = emphasized that well-defined use cases and clear terminology must come = before a specification draft.
  • "Less is more". Macy (via chat) cautioned = against feature creep in the initial draft.
  • Durability = concern. SCIM has natural latency; whether it fits very ephemeral agent = instantiations is an open question.
  • Class vs. instance. Is SCIM representing the = agent template/class or a specific running instance? Remains = unresolved.


Terminology (Working = Definitions)

For the purpose of these use cases, we use = "agent" broadly to mean a non-human software entity that acts = autonomously or on behalf of a user, and that requires identity, = lifecycle management, or access governance beyond what OAuth client = registration alone provides. We intentionally avoid a narrow definition = at this stage. The use cases below are meant to stress-test where the = boundaries should be.

We also distinguish:
  • Agent class: a = template or type of agent that can be instantiated (e.g., "Acme Travel = Assistant v2")
  • Agent instance: a specific running instantiation of = an agent class, bound to a context (e.g., a particular user's session or = a particular Kubernetes pod)

Whether SCIM = should model one or both is an open question we'd like input = on.


Use = Cases
UC1: Agents Participating in = Existing IAM Systems
Autonomous agents that request = privileges and act as primary actors in enterprise systems should = participate in existing SCIM-based identity and access transactions = alongside users but must be distinguishable from = them.

An enterprise manages access to shared resources = (document repositories, cloud projects, APIs) through groups provisioned = via SCIM. When an agent needs access to one of these resources, an IDP = administrator adds the agent to the same access group that governs human = access. The group now contains both human and agent members. = Administrators list, audit, and manage membership uniformly regardless = of member type. The agent goes through the same approval workflow as a = user. At the same time, compliance teams can filter group membership by = resource type to answer questions like "which agents have access to our = production environment?" or "how many non-human identities hold admin = privileges?"

Without a = standardized agent resource type, organizations represent agents as = pseudo-users,  mirroring the legacy Active Directory service = account pattern and therefore losing the ability to distinguish them. = This leads to audit blind spots, policy gaps (e.g.,  no way to = enforce "agents may not hold break-glass admin roles" at the = resource-type level), lifecycle failures when agent decommissioning = doesn't follow the same workflows as user offboarding, and governance = sprawl as separate systems are built to  manage agent access = alongside SCIM-managed user access.

Why SCIM: = Groups already support heterogeneous member types, and the $ref and = group.members.type sub-attributes allow identifying the resource type of = each member. A standardized agent resource type means agents can be = provisioned, added to groups, governed, and audited through the same = SCIM pipeline used for users while remaining distinguishable at every = layer.

UC2: = Enterprise Agent Fleet Provisioning
An enterprise deploys a fleet = of AI agents (e.g., an HR assistant, a sales copilot, an IT support = bot). The identity team needs to provision these agents into target SaaS = applications through the same IDP and SCIM pipeline they already use for = users.
This includes creating the agent identity, assigning = it to groups that control resource access, and eventually disabling or = removing it.

  • SCIM client: = Identity Provider (e.g., Entra ID, Okta)
  • SCIM service = provider (server): Target SaaS application (e.g., Atlassian, = Salesforce)

Why SCIM: Reuses existing provisioning = infrastructure. The agent lifecycle (create, update, disable, delete) = mirrors user lifecycle operations that SCIM already = handles.

UC3: Agent-to-Person Entitlement = Relationships
An enterprise wants to control = which users a specific agent can act on behalf of, and with what level = of access. For example: 25 people are entitled to use GitHub Copilot = within a GitHub EMU organization. Of those 25, only 10 should have = Copilot act on their behalf when accessing data in Atlassian. And within = those 10, the entitlements may differ per user: user 1 gets readWrite to = Confluence, user 2 gets readOnly to Jira.

This raises the question of how = these relationships are represented. Is this tracked on the agent = resource, on the user resource, or on some other resource type? Is this = an entitlement model where the agent has entitlements to operate on = users' behalf, or where users have entitlements to interface with = agents? These are open questions we'd like input on.

When a user leaves the = organization, any agents entitled to act on their behalf must be = discoverable and the relationship must be decommissioned as part of = offboarding.

  • SCIM client: = Identity Provider or Identity Governance system
  • SCIM service = provider: Application that hosts the agent or the resource being = accessed

Why SCIM: = SCIM already models relationships between resources. Extending this to = agent-user entitlement relationships enables governance over who an = agent can act for and with what scope.

UC4: Agent Protocol = Discoverability
An enterprise has provisioned several = agents from different vendors. A consuming system or another agent needs = to discover what protocols a given agent supports (e.g., A2A, MCP, = SPIFFE, OAuth) and how to reach it. The agent's SCIM record could = include or reference metadata such as an agent card URL, supported = protocol identifiers, or endpoint URIs.
  •  SCIM = client: Identity Provider provisioning agent metadata
  •  SCIM = service provider: Agent registry, application directory, or agent = runtime platform

Why SCIM: = SCIM is already the system of record for identity metadata. Adding = discoverable protocol capabilities avoids building a parallel discovery = mechanism for agents that are already provisioned via = SCIM.

UC5: SPIFFE-Based Workload = Identity Provisioning

Consider an organization uses = SPIFFE for workload attestation; when the administrator approves a new = AI agent for deployment, the agent's SPIFFE registration entry (SPIFFE = ID, attestation selectors such as k8s labels, cloud metadata, image = hashes) needs to be provisioned into the SPIFFE server (e.g., a SPIRE = server or a Workload Identity Provider).
The enterprise wants to = manage this through the same SCIM pipeline used for users and OAuth = clients, rather than maintaining a separate provisioning system. This is = explicitly a human/admin-controlled process. It applies in scenarios = where template-based or federation-based approaches are not desirable. = For instance, when an organization needs fine-grained administrative = control over which agent  identities are registered, based on = real-world customer requirements for compliance or policy = enforcement.

The provisioning can occur within a single trust = domain (admin provisions an agent identity into their own SPIFFE server) = or across trust domains (admin provisions an agent identity from an = external partner into a federated SPIFFE trust domain). It is important = to distinguish between provisioning a registration entry (the right to = an identity, including its attestation selectors) and provisioning a = template (a reusable pattern from which multiple registration entries = can be created). Both may be valid use cases, and we'd like input on = whether SCIM should support one or both.

  • SCIM = client: Identity Provider or Identity Governance platform (the = admin-facing system)

  • SCIM service provider: SPIFFE server / SPIRE = server / Workload Identity Provider (WIDP)

Why SCIM: = SCIM provisions the right to an identity (the registration entry), not = the credential itself. SPIFFE issues credentials at runtime after = attestation. This cleanly separates provisioning from credential = issuance and tests the extensibility  of the agent schema to = non-OAuth identity models. SCIM doesn't replace SPIRE's registration API = -- it sits in front of it.


UC6: Fleet-Wide SPIFFE Selector Update on Infrastructure = Change
An organization has 200 agents registered as = SPIFFE workloads, each with attestation selectors tied to their = deployment environment (e.g., Kubernetes namespace labels, cloud = instance metadata, container image hashes). An infrastructure change = occurs: the team migrates from one Kubernetes cluster to another, or = rotates to a new set of signed container images. The SPIFFE identities = remain the same, but the attestation selectors that prove "this workload = is who it claims to be" must be updated across the entire fleet. Without = this update, agents will fail attestation at runtime and lose their = credentials.

  • SCIM client: Identity Provider or infrastructure = automation platform

  • SCIM service provider: SPIFFE server / SPIRE server / = Workload Identity Provide.

Why SCIM: This is a bulk update = operation on provisioned identity metadata; exactly the kind of = operation SCIM is built for. An IDP can issue a SCIM PATCH across the = affected agent entries to update selectors without touching the SPIFFE = IDs or disrupting the agents' logical identities. Doing this through a = unified SCIM pipeline avoids the need for operators to script directly = against SPIFFE server APIs or maintain a separate bulk-management tool = for workload identity.

UC7: Agent = Governance and Status Tracking
Before an agent is activated in = an enterprise, it must go through an approval workflow. The enterprise = needs to track agents that are pending approval, approved but not yet = instantiated, active, suspended, or disallowed by policy. This goes = beyond the binary active/inactive model used for users.

  • SCIM = client: Identity Governance platform

  • SCIM service provider: Agent registry or = application directory

Why SCIM: Governance and status = tracking are lifecycle operations. Rather than building a separate = governance system for agents, extending SCIM's existing model keeps = agent management unified with user management.

We welcome all = feedback on the mailing list. If you'd like to join the workstream = meetings, reach out to any of us directly.

Best,
Pam, Danny, = Macy, Mark, Ismael


_______________________________________________
scim mailing list -- = scim@ietf.org
To unsubscribe send an = email to = scim-leave@ietf.org

= --Apple-Mail=_A01CED70-4B63-4B68-A4FA-59175BAF17F9--