SCIM Agent Governance Extension

Internet-Draft	SCIM Agent Governance	July 2026
Kushwaha	Expires 27 January 2027	[Page]

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 27 January 2027.¶

Copyright Notice

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

1. Introduction

The SCIM protocol [RFC7644] and core schema [RFC7643] are widely implemented for provisioning user records into services. [I-D.wzdk-scim-agent-resource] extends this model with a first-class Agent resource type, deliberately minimal so that the base schema remains stable while the agentic ecosystem evolves.¶

Discussion on the SCIM WG mailing list following the publication of [I-D.wzdk-scim-agent-resource] identified a set of governance concerns that arise once agents move from a simple identity record into operational use in an enterprise: distinguishing reversible suspension from terminal decommissioning, freezing an agent during a security investigation while preserving evidence, recording the degree of human oversight an agent operates under, bounding the period during which an agent is intended to operate, and locating the agent's credential binding information.¶

This document defines an optional extension schema, "urn:ietf:params:scim:schemas:extension:agent:2.0:Governance", carrying this metadata. The design follows three principles that emerged from the WG discussion:¶

Provisioning-layer only. Every attribute in this extension is a fact about the agent established at or after provisioning time that remains true regardless of which protocol the agent later uses to authenticate or act. Attributes that function as authorization decision inputs, credential artifacts, or real-time risk signals are excluded (see Section 5).¶
Normatively grounded value sets. The lifecycle state values are derived from the identity information lifecycle of [ISO24760-1], following the approach demonstrated in [OPCommands], rather than inventing a parallel vocabulary. One agent-specific state is added with explicit justification (Section 3.1.3).¶
Cross-protocol legibility. The semantics of the value sets defined here (autonomy levels, lifecycle states) are intended to be referenceable by other protocols -- for example as OAuth claim values or workload attestation attributes -- and are therefore defined independently of SCIM transport details. A future registry could relocate these value sets outside SCIM entirely; this document defines the SCIM carrier attributes.¶

Because this is an extension schema, support is inherently optional and discoverable: a SCIM service provider advertises support via its "/Schemas" endpoint and the "schemaExtensions" element of the Agent ResourceType, per Section 6 of [RFC7643].¶

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

The terms "agent", "Agent resource", and "agentic identity" are used as defined in [I-D.wzdk-scim-agent-resource]. "Service provider" and "provisioning client" are used as defined in [RFC7643].¶

3. Agent Governance Extension Schema

The extension schema is identified by the URI "urn:ietf:params:scim:schemas:extension:agent:2.0:Governance". It MAY be applied to resources of type Agent as defined in [I-D.wzdk-scim-agent-resource]. A service provider that advertises this extension MUST recognize all attributes defined by this schema. If the extension is present on an Agent resource, "lifecycleState" MUST be present. Unless stated otherwise, all other attributes are OPTIONAL.¶

3.1. lifecycleState

A complex attribute describing the operational lifecycle state of the agentic identity, with the following sub-attributes.¶

state: A string whose value is one of the canonical values below. REQUIRED within "lifecycleState". Mutability is "readWrite"; transitions are subject to the rules in Section 3.1.5.¶
reason: A string carrying a machine-readable reason code for the current state, e.g. "securityInvestigation", "authorityRevoked", "endOfLife", "parentDecommissioned", "pendingReview". OPTIONAL; mutability is "readWrite". Reason codes are not standardized by this document; deployments SHOULD document their vocabulary.¶
transitionedAt: A dateTime ([RFC3339]) recording when the current state was entered. Mutability is "readOnly"; assigned by the service provider.¶
transitionedBy: A SCIM reference to the User or Agent resource that initiated the transition. Mutability is "readOnly"; assigned by the service provider.¶

3.1.1. Initial State on Resource Creation

On resource creation, "lifecycleState.state" SHOULD default to "established" unless service provider policy permits immediate activation. A create request that sets "lifecycleState.state" to "active" MUST be accepted only if the same request, or service provider policy, satisfies the provider's activation requirements. A create request that sets "lifecycleState.state" to "quarantined" or "archived" SHOULD be rejected unless local administrative policy explicitly permits pre-quarantine or immediate archival.¶

3.1.2. Canonical State Values and ISO/IEC 24760-1 Mapping

[ISO24760-1] defines an identity information lifecycle, in Section 7.2 of that standard, comprising the stages "unknown", "established", "active", "suspended", and "archived". The canonical values of "state" adopt this lifecycle directly, omitting "unknown" (a SCIM resource that exists is by definition at least established) and adding a single agent-specific value, "quarantined".¶

Table 1: Lifecycle state values and ISO/IEC 24760-1 mapping
state	ISO/IEC 24760-1 stage	Semantics for agents
established	established	Provisioned but not yet activated. The agent cannot authenticate.
active	active	Fully operational.
suspended	suspended	Temporarily disabled by administrative action; reversible. Outstanding tokens SHOULD be revoked or suspended.
quarantined	(no equivalent; see Section 3.1.3)	Frozen pending security investigation; reversible only by explicit administrative review. All access MUST be blocked; the record and associated evidence MUST be preserved unchanged.
archived	archived	Terminal. The identity's authority is permanently withdrawn. The record is retained for audit; see Section 6.

Distinctions that some deployments model as separate terminal states -- for example "revoked" (authority withdrawn for cause) versus "decommissioned" (planned end of life) -- are carried in the "reason" sub-attribute of the transition into "archived" rather than as additional state values. This keeps the value set aligned with [ISO24760-1] while preserving the audit distinction.¶

Note that [ISO24760-1] permits restoration of identity information from the archived stage, and [OPCommands] accordingly defines a restore command among its lifecycle commands. This profile deliberately diverges: for agents, "archived" is terminal (Section 3.1.4). Restoring a previously archived agent identity would allow authority withdrawn for cause to be silently re-established, and would break the association between a continuous agent identity and its audit history. Where an archived agent's function is still required, a new Agent resource SHOULD be provisioned, preserving the archived record and its audit trail intact.¶

3.1.3. Justification for the "quarantined" State

[ISO24760-1] addresses the lifecycle of identity information for principals in general and does not define a state for an identity frozen during an active security investigation. For human identities, "suspended" has historically absorbed this case.¶

Agents differ in two ways that justify a distinct state. First, a compromised agent can continue to act autonomously at machine speed between the detection of an indicator and administrative response; the semantics of "quarantined" therefore require that all access be blocked immediately and unconditionally, whereas "suspended" is an administrative convenience whose enforcement details are deployment-defined. Second, investigation of agent compromise depends on preserving the agent record, its credential references, and its relationship graph (owners, hosted application, children) exactly as they were at detection time; "quarantined" therefore additionally prohibits modification of the resource other than the lifecycle transition itself.¶

To the author's knowledge no ISO/IEC 24760-1 equivalent for agent identities exists at the time of writing. Should ISO/IEC JTC 1/SC 42 or another body publish an agent-identity lifecycle taxonomy, a future revision of this document should reference it.¶

3.1.4. Permitted State Transitions

A service provider implementing this extension MUST enforce the transition graph below and MUST reject a modification request whose resulting transition is not listed, with HTTP status 400 and SCIM error type "invalidValue". On every permitted transition the service provider MUST update "transitionedAt" and "transitionedBy".¶

Table 2: Permitted lifecycle state transitions
From	To	Typical trigger
established	active	Activation after provisioning checks complete
active	suspended	Administrative pause; reversible
suspended	active	Reinstatement
active, suspended	quarantined	Security indicator or investigation opened
quarantined	suspended	Investigation closed; agent remains disabled pending reinstatement
quarantined	active	Investigation cleared and local policy permits immediate reinstatement; restricted administrative principals only
established, active, suspended, quarantined	archived	Planned decommission, revocation for cause, or abandonment before activation; the distinction is carried in "reason"
archived	(none)	Terminal

established -> active <-> suspended
      |          |           |
      +----------+-----------+--> archived
                 |           |
                 v           v
              quarantined --> suspended
                  |   |
                  |   +--> active  (policy-restricted)
                  +------> archived

archived is terminal.

Figure 1: Lifecycle state transition graph (transitions to archived are permitted from every non-terminal state)

3.1.5. Interaction with the "active" Attribute

The Agent core schema [I-D.wzdk-scim-agent-resource] defines a REQUIRED boolean "active". For resources on which this extension is present, "active" is a projection of "lifecycleState.state". The value of "active" MUST be true when "lifecycleState.state" is "active" and MUST be false when "lifecycleState.state" is "established", "suspended", "quarantined", or "archived".¶

A service provider implementing this extension MUST derive "active" from "lifecycleState.state". If a request modifies both "active" and "lifecycleState.state" and the resulting values are inconsistent, the service provider MUST reject the request with HTTP status 400 and SCIM error type "invalidValue". A modification that sets "active" to false on a resource whose state is "active" SHOULD be interpreted as a transition to "suspended".¶

Transitions into "archived" are terminal: a service provider MUST reject any request that would transition a resource out of the "archived" state. Transitions out of "quarantined" SHOULD be restricted by local policy to explicitly authorized administrative principals. A direct transition from "quarantined" to "active" MAY be permitted only after investigation closure and explicit administrative approval; otherwise, implementations SHOULD transition from "quarantined" to "suspended" before reinstatement.¶

3.1.6. Relationship to Event-Based Signaling

The lifecycle state defined here is the durable, queryable state of record for the agent. A state transition, by contrast, is a security-relevant point-in-time event, and SCIM's polling-scale change propagation is not suitable for conveying it to relying parties in real time.¶

Deployments that participate in an event-signaling framework such as the Shared Signals Framework [SSF] SHOULD emit an event when an agent transitions into or out of "quarantined" or into "archived", with the event identifying the SCIM resource. Relying parties that require timely reaction to lifecycle changes SHOULD subscribe to such events rather than poll the SCIM resource. This division of responsibility -- state of record in the provisioning layer, change notification in the signaling layer -- is deliberate and follows the design guidance that shaped this extension (Section 5.1).¶

3.1.7. Use in Access Reviews

Because "lifecycleState" is an ordinary SCIM attribute, it participates in SCIM filtering (Section 3.4.2.2 of [RFC7644]). For example, an access-review process can enumerate all agents frozen pending investigation with:¶

GET /Agents?filter=urn:ietf:params:scim:schemas:extension:agent:
    2.0:Governance:lifecycleState.state eq "quarantined"

Figure 2: Filtering for quarantined agents

or all agents whose validity window has lapsed but whose state has not been reconciled:¶

GET /Agents?filter=urn:ietf:params:scim:schemas:extension:agent:
    2.0:Governance:validTo lt "2026-07-01T00:00:00Z" and
    urn:ietf:params:scim:schemas:extension:agent:
    2.0:Governance:lifecycleState.state eq "active"

Figure 3: Filtering for agents past their validity window

Line breaks within the filter values above are for display purposes only.¶

Service providers implementing this extension SHOULD support filtering on "lifecycleState.state", "validFrom", and "validTo".¶

3.2. autonomyLevel

A string classifying the degree of human oversight under which the agent operates. Canonical values:¶

autonomous: The agent initiates and completes actions without a human in the loop.¶
semiAutonomous: The agent acts independently within a bounded task but requires human initiation or checkpoint approval.¶
supervised: A human reviews or approves the agent's individual actions.¶

This attribute is informational classification metadata recorded at provisioning time. It is NOT an authorization control, MUST NOT be treated as authoritative unless validated by local policy or another trusted governance process, and MUST NOT be used as the sole input to an access decision; see Section 6. The value set is intentionally protocol-neutral so that the same classification can be conveyed in other contexts (for example as a claim value or workload attestation attribute). Regulatory frameworks that classify AI systems partly by degree of human oversight, such as the EU AI Act, are an anticipated consumer of this classification.¶

Mutability is "readWrite". Changes to "autonomyLevel" SHOULD be audited.¶

3.3. validFrom and validTo

Two dateTime ([RFC3339]) attributes bounding the period during which the agentic identity is intended to operate, analogous to the notBefore and notAfter fields of an X.509 certificate.¶

validFrom: The instant from which the agent may be activated. OPTIONAL.¶
validTo: The instant after which the agent's identity is no longer valid. OPTIONAL.¶

A service provider SHOULD treat an agent outside its validity window as if its lifecycle state were "suspended", regardless of the stored state value, and SHOULD NOT issue new credentials or tokens for it. The stored "lifecycleState.state" value is not modified by the passage of time; the validity window is evaluated at each authentication or issuance decision.¶

3.4. credentialDiscoveryUri

A SCIM reference of type "external" containing a URI at which an agent-specific discovery document describing the agent's supported credential binding methods can be retrieved.¶

Embedding credential binding metadata (method, certificate thumbprint, issuer) directly in the provisioning record is brittle: an agent may support multiple binding options and these change over time, whereas a provisioning record is comparatively static. A discovery document, analogous in role to OAuth authorization server metadata, allows the binding information to evolve without SCIM modification traffic and to be verified independently of the provisioning channel.¶

The format of the discovery document is out of scope for this document. The URI SHOULD use the "https" scheme, and the document SHOULD be served from an authority associated with the agent's operator. A service provider MUST validate that the value refers to an authority authorized for the agent or its operator before relying on it. Requirements on changes to this attribute are given in Section 6.¶

4. Example

The following is a non-normative example of an Agent resource using this extension, in JSON [RFC8259].¶

{
  "schemas": [
    "urn:ietf:params:scim:schemas:core:2.0:Agent",
    "urn:ietf:params:scim:schemas:extension:agent:2.0:Governance"
  ],
  "id": "95cfaafb-0827-4c60-8236-523ad04b3cba",
  "displayName": "Invoice review agent",
  "agentUserName": "invoice-review-agent",
  "active": true,
  "owners": [
    {
      "value": "2819c223-7f76-453a-919d-413861904646",
      "$ref": "https://example.com/v2/Users/2819c223-...",
      "displayName": "Finance Platform Team"
    }
  ],
  "urn:ietf:params:scim:schemas:extension:agent:2.0:Governance": {
    "lifecycleState": {
      "state": "active",
      "transitionedAt": "2026-07-01T09:00:00Z",
      "transitionedBy": {
        "value": "2819c223-7f76-453a-919d-413861904646",
        "$ref": "https://example.com/v2/Users/2819c223-..."
      }
    },
    "autonomyLevel": "semiAutonomous",
    "validFrom": "2026-07-01T00:00:00Z",
    "validTo": "2026-12-31T23:59:59Z",
    "credentialDiscoveryUri":
      "https://example.com/.well-known/agent/invoice-review-agent"
  },
  "meta": {
    "resourceType": "Agent"
  }
}

5. Out of Scope

The following concerns were considered during the development of this extension and deliberately excluded. They are enumerated here so that implementers do not expect this extension to address them and so that the rationale is preserved.¶

5.1. Trust Posture and Risk Level

An earlier proposal included an "effectiveTrustLevel" attribute with values such as high, medium, and low. It is excluded for two reasons identified in WG discussion. First, risk is relative to each participant in a multi-party ecosystem; a categorical level has no shared meaning across administrative domains without a conformance contract that a schema attribute cannot supply. Second, SCIM is a provisioning protocol with polling-scale latency and is not suited to conveying risk posture, which changes in real time. Changes in an agent's trust or risk posture are better conveyed as security events using the Shared Signals Framework [SSF], to which relying parties can subscribe.¶

5.2. Tenant Scope and Delegation Scope

Attributes describing where an agent may operate ("tenantScope") and under whose delegated authority ("delegationScope") address real enterprise concerns but are not SCIM-local: to be useful they must be legible across provisioning, federation, and authorization protocols. Delegation relationships at token time are already addressed by the "act" and "may_act" claims of OAuth 2.0 Token Exchange [RFC8693]. Cross-system workload identity context is the subject of the IETF WIMSE working group [WIMSECharter]. These concerns should be pursued in those venues; a SCIM binding can follow once cross-protocol semantics exist.¶

5.3. Tool Permissions and Action-Level Authorization

Attributes enumerating permitted or denied actions per tool are authorization policy, not provisioning metadata. They duplicate OAuth scope semantics and the responsibilities of policy engines, and deny-list constructions in particular create false assurance through incomplete enumeration. Fine-grained agent authorization belongs in the authorization layer. The deny-by-default guidance retained from this discussion appears in Section 6.¶

5.4. Conflict Resolution Policy

A per-resource attribute directing how conflicts between authority sources are resolved would embed policy-engine semantics in an identity record and would depend on attribute sets that this extension does not define. Deterministic conflict handling is addressed as implementation guidance in Section 6; a SCIM-wide profile would be the appropriate vehicle for anything normative.¶

6. Security Considerations

The security considerations of [RFC7644] and [I-D.wzdk-scim-agent-resource] apply. In addition:¶

Client-supplied governance metadata.: A service provider MUST NOT treat client-supplied governance metadata as authoritative for security decisions without validation. In particular, "autonomyLevel" is descriptive classification, MUST NOT be treated as authoritative unless validated by local policy or another trusted governance process, and MUST NOT be used as the sole input to an authorization decision.¶
Trust chain through owners.: The Agent core schema permits "owners.$ref" to reference another Agent, enabling orchestrator-to-subagent relationships. Where comparable authority or trust metadata is available, a child agent SHOULD NOT be provisioned with, or elevated to, broader effective authority than the Agent(s) responsible for it, unless local policy explicitly permits the elevation and the decision is audited. Without this constraint, a lower-authority orchestrator can escalate its own effective authority by provisioning a higher-authority child.¶
Lifecycle transitions and outstanding credentials.: A specification of lifecycle state is incomplete without defining its effect on live access. On transition to "suspended", outstanding tokens and sessions SHOULD be revoked or suspended. On transition to "quarantined" or "archived", outstanding tokens and sessions MUST be revoked, and for "quarantined" the resource MUST NOT be modifiable except by the authorized review process.¶
Terminal state record preservation.: When an agent reaches the "archived" state, the service provider SHOULD retain the resource in a read-only form rather than deleting it, preserving the audit trail linking past actions to the agent identity. Deployments subject to data-minimization obligations should reconcile retention duration with those obligations rather than defaulting to deletion.¶
Credential discovery changes.: Changes to "credentialDiscoveryUri" alter where relying parties learn the agent's credential bindings and are therefore security-sensitive. Such changes after activation MUST require administrative approval, MUST be policy-controlled and audited, and SHOULD trigger revocation of outstanding tokens. Implementations SHOULD prevent changes that would have the effect of silently downgrading the agent from a stronger binding method to a weaker one. Consumers MUST NOT automatically dereference arbitrary "credentialDiscoveryUri" values from privileged network locations without scheme validation, server-side request forgery protections, and local trust policy.¶
Autonomous agents.: Deployments SHOULD apply stricter default controls to agents with "autonomyLevel" of "autonomous" than to supervised agents, for example shorter credential lifetimes, narrower permitted scopes, or additional approval requirements, reflecting the reduced opportunity for human interruption of anomalous behavior.¶
Deny by default.: Where an agent's effective authority is derived from multiple sources (group memberships, lifecycle state, owner status, credential validity) and those sources conflict or cannot be resolved, implementations SHOULD apply the most restrictive interpretation, and the default decision when a conflict cannot be resolved SHOULD be to deny.¶

7. Privacy Considerations

Governance metadata reveals operational structure. The combination of "autonomyLevel", validity windows, and lifecycle history exposes how an organization deploys and supervises its agents; a "quarantined" state in particular signals an ongoing security investigation. Service providers SHOULD apply the same access controls to this extension's attributes as to other sensitive provisioning metadata, and SHOULD consider excluding "lifecycleState.reason" from responses to callers without an administrative need to know.¶

The "credentialDiscoveryUri" value, and the discovery documents it points to, can enumerate an organization's agent fleet if the documents are world-readable at predictable locations. Deployments for which agent inventory is sensitive SHOULD authenticate access to agent discovery documents.¶

Retention of "archived" records (Section 6) preserves audit capability but must be reconciled with applicable data-minimization obligations; where an agent record embeds personal data of its human owners, deployments SHOULD prefer redacting that personal data over deleting the agent record.¶

8. IANA Considerations

When published as an RFC, IANA is requested to add the following entry to the "SCIM Schema URIs for Data Resources" registry established by [RFC7643]:¶

URN:: urn:ietf:params:scim:schemas:extension:agent:2.0:Governance¶
Name:: Agent Governance¶
Reference:: This memo, Section 3 ¶

Appendix A. Full Schema Representation

The following is a non-normative representation of the extension schema as returned from the "/Schemas" endpoint.¶

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Schema"],
  "id":
   "urn:ietf:params:scim:schemas:extension:agent:2.0:Governance",
  "name": "AgentGovernance",
  "description": "Governance metadata for Agent resources.",
  "attributes": [
    {
      "name": "lifecycleState",
      "type": "complex",
      "multiValued": false,
      "description": "Operational lifecycle state of the agent.",
      "required": true,
      "mutability": "readWrite",
      "returned": "default",
      "subAttributes": [
        {
          "name": "state",
          "type": "string",
          "multiValued": false,
          "required": true,
          "caseExact": true,
          "canonicalValues": ["established", "active",
            "suspended", "quarantined", "archived"],
          "mutability": "readWrite",
          "returned": "default",
          "uniqueness": "none"
        },
        {
          "name": "reason",
          "type": "string",
          "multiValued": false,
          "required": false,
          "caseExact": false,
          "mutability": "readWrite",
          "returned": "default",
          "uniqueness": "none"
        },
        {
          "name": "transitionedAt",
          "type": "dateTime",
          "multiValued": false,
          "required": false,
          "mutability": "readOnly",
          "returned": "default",
          "uniqueness": "none"
        },
        {
          "name": "transitionedBy",
          "type": "complex",
          "multiValued": false,
          "required": false,
          "mutability": "readOnly",
          "returned": "default",
          "uniqueness": "none",
          "subAttributes": [
            {
              "name": "value",
              "type": "string",
              "multiValued": false,
              "required": true,
              "caseExact": false,
              "mutability": "readOnly",
              "returned": "default",
              "uniqueness": "none"
            },
            {
              "name": "$ref",
              "type": "reference",
              "referenceTypes": ["User", "Agent"],
              "multiValued": false,
              "required": false,
              "caseExact": true,
              "mutability": "readOnly",
              "returned": "default",
              "uniqueness": "none"
            }
          ]
        }
      ]
    },
    {
      "name": "autonomyLevel",
      "type": "string",
      "multiValued": false,
      "description": "Degree of human oversight.",
      "required": false,
      "caseExact": true,
      "canonicalValues": ["autonomous", "semiAutonomous",
        "supervised"],
      "mutability": "readWrite",
      "returned": "default",
      "uniqueness": "none"
    },
    {
      "name": "validFrom",
      "type": "dateTime",
      "multiValued": false,
      "description": "Start of the operational validity window.",
      "required": false,
      "mutability": "readWrite",
      "returned": "default",
      "uniqueness": "none"
    },
    {
      "name": "validTo",
      "type": "dateTime",
      "multiValued": false,
      "description": "End of the operational validity window.",
      "required": false,
      "mutability": "readWrite",
      "returned": "default",
      "uniqueness": "none"
    },
    {
      "name": "credentialDiscoveryUri",
      "type": "reference",
      "referenceTypes": ["external"],
      "multiValued": false,
      "description": "Agent credential discovery document URI.",
      "required": false,
      "caseExact": true,
      "mutability": "readWrite",
      "returned": "default",
      "uniqueness": "none"
    }
  ],
  "meta": {
    "resourceType": "Schema"
  }
}

Appendix B. Changes From Earlier Versions

This is the initial version of this draft.¶

Acknowledgments

This document grew out of review discussion of [I-D.wzdk-scim-agent-resource] on the SCIM WG mailing list. The author thanks Danny Zollner and Pamela Dingle for detailed responses that shaped the scope of this extension, in particular the requirement to ground the lifecycle value set in ISO/IEC 24760-1, the credential discovery document approach, and the identification of concerns better addressed via the Shared Signals Framework and the WIMSE working group.¶

Author's Address

Saurabh Kushwaha

Oracle Corporation

Email: saurabhkushwaha123@gmail.com