Internet-Draft Agent Principal Lifecycle November 2026
McGuinness Expires 15 May 2027 [Page]
Workgroup:
System for Cross-domain Identity Management
Internet-Draft:
draft-mcguinness-oauth-governed-agent-lifecycle-latest
Published:
Intended Status:
Standards Track
Expires:
Author:
K. McGuinness
Independent

Agent Principal Lifecycle Profile for SCIM and OAuth

Abstract

This document profiles SCIM for provisioning issuer-qualified, enterprise-governed Agent Principals into a resource domain and applying administrative disablement to OAuth authorization. Existing SCIM Events can accelerate reconciliation; existing session-revocation events can invalidate identified authorization sessions independently of principal state.

The profile defines identity correlation, receiver actions, and the limits of propagation and resource enforcement. It defines no new SCIM schema, event type, eligibility lease, or authorization timestamp. Current administrative state does not establish a history of revocation.

About This Document

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

The latest revision of this draft can be found at https://mcguinness.github.io/agent-principal-profiles/draft-mcguinness-oauth-governed-agent-lifecycle.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-mcguinness-oauth-governed-agent-lifecycle/.

Discussion of this document takes place on the System for Cross-domain Identity Management Working Group mailing list (mailto:scim@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/scim/. Subscribe at https://www.ietf.org/mailman/listinfo/scim/.

Source for this draft and an issue tracker can be found at https://github.com/mcguinness/agent-principal-profiles.

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 15 May 2027.

▲

Table of Contents

1. Introduction

Agent Principal Federation [FEDERATION] separates agent identity, client authority, user delegation, and resource authorization. It identifies an Agent Principal by the pair (IdP issuer, agent identifier), independently of the client or workload credential used to resolve it.

For delegated access, the Identity Assertion JWT Authorization Grant (ID-JAG) [ID-JAG] carries that principal as the actor. The resource domain correlates the actor with its local agent record.

Across the family, [AGENT-MANAGEMENT] establishes the relationships at the IdP, [FEDERATION] exercises them to obtain authorization, and this document carries the principal's administrative state into the resource domain and revokes what depends on it.

This companion defines how a resource domain provisions that principal and applies changes to its administrative status. The responsibilities are:

Table 1
Mechanism Responsibility
SCIM Agent [SCIM-AGENT] Provision and update the local representation, including active
SCIM Events [RFC9967] Notify the receiver that authoritative provisioning state changed
Session revocation Invalidate identified authorization sessions without changing the principal's administrative status
OAuth enforcement Apply local eligibility and revocation at issuance, refresh, introspection, and API access 
 Enterprise IdP / connector                  Resource domain
 +------------------------+                 +----------------------+
 | Agent Principal        | ---- SCIM ---->  | Local agent principal|
 | Administrative state   |                  | Correlation + active |
 +------------------------+                 +-----------+----------+
       |                                                |
       +---- change notice --> reconciliation           v
                                             RAS issuance / refresh
       +---- session revocation ------------> session invalidation
                                                        |
                                                        v
                                            API token enforcement
Figure 1: Administrative state and authorization revocation

SCIM is the provisioning baseline. Shared Signals is an optional addition, profiled in Appendix A using existing event types. A deployment can use direct SCIM updates, event-driven reconciliation, or both, provided that they apply the same authoritative administrative decisions. Events trigger retrieval of current state rather than carrying it: a late notice resolves to the current decision, whereas a late activation applied as an instruction would revive a principal that was since disabled. That asymmetry is the design's safety property. Current state alone would lose a disablement that a reactivation has since superseded, so the IdP delivers that disablement first, by a SCIM write, and it invalidates the authorization issued before it (Section 3.1).

Disabling a principal and revoking a session are separate actions. Once applied, disablement prevents new authorization and invalidates existing RAS authorization for that principal. Re-enablement permits new decisions; it does not restore revoked sessions. Neither an event acknowledgment nor a SCIM response proves that every API has stopped accepting issued tokens.

Disablement is one of several revocation boundaries. Disabling the principal, disabling an Identity Binding, withdrawing a Client Association or a delegation, revoking a workload credential, and revoking one grant each reach different authorization (Section 8). The resource domain also keeps its own authority: a Local Suspension denies the agent there regardless of upstream state, and upstream activation cannot clear it.

1.1. Scope

This profile covers IdP-to-resource-domain provisioning for delegated Federation, and a platform applying the IdP's administrative state to agents it hosts (Section 9). It does not define:

  • Platform enrollment or administration of Identity Bindings and Client Associations; [AGENT-MANAGEMENT] defines that separate interface.

  • A new lifecycle state machine, signed eligibility lease, authorization cutoff, or distributed ordering protocol.

  • Automatic translation of binding or delegation withdrawal into all affected grants, or a WAG wire profile. A known ID-JAG can be revoked selectively under Appendix A.4.

  • A guarantee that a disable-and-reenable cycle invalidates a grant issued before the disablement and first redeemed after the reactivation (Section 11.3).

  • Runtime containment: stopping executions, tool calls, or network access, or rejecting offline tokens before they expire. Administrative disablement stops new authorization and revokes RAS sessions; immediate containment needs complementary runtime enforcement (Section 7.1).

Section 6, Section 7, and Section 11.3 state the recovery and enforcement limits.

2. Conventions and 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 [BCP14] (RFC2119) (RFC8174) when, and only when, they appear in all capitals, as shown here.

Agent Principal, Governance Tenant, Target Tenant, and resource authorization server (RAS) follow [FEDERATION]. SCIM terms follow [RFC7643] and [RFC7644].

Governing IdP:

The IdP governing the Agent Principal. An authorized connector can provision its decisions into the resource domain.

Receiver:

The resource-domain SCIM service provider and the components applying accepted changes at the RAS, or, for a platform-hosted agent, in the platform's own authorization (Section 9). They form one administrative deployment; they need not run in one process. It is the resource-domain counterpart of the IdP Service Provider in [AGENT-MANAGEMENT].

Provisioning Domain:

Trusted configuration identifying one governing IdP issuer, its tenant where the issuer is multi-tenant ("Canonical Identity and Tenant Boundaries" in [FEDERATION]), and one receiving Target Tenant, together with the connectors authorized to manage their correlation and administrative state. This is the resource-domain counterpart of the IdP-side Provisioning Domain.

Authorization Session:

RAS state retaining the identity and authority derived from a grant, including any associated refresh authorization and access tokens. This is a processing concept, not a new token or wire identifier.

Local Suspension:

A resource-domain restriction independent of the Governing IdP's administrative state. Upstream activation cannot clear it.

3. Conformance and Configuration

Conformance requires the SCIM provisioning and OAuth receiver behavior in this document. Events are optional; a deployment using them MUST apply Appendix A. Support for events alone is not conformance to this lifecycle profile. A platform applying state to agents it hosts conforms through Section 9 instead of the OAuth receiver behavior.

Before provisioning, the parties MUST establish:

A connector authorized for one context MUST NOT modify another context's principal or correlation. Multiple writers MAY represent the same Governing IdP, but MUST reconcile against its current decisions rather than replay queued activation writes after newer disablement, and deliver a pending invalidation first (Section 3.1). SCIM conditional updates protect receiver resource versions; they do not order independent source decisions.

The IdP continues to enforce current eligibility when issuing grants under [FEDERATION]. This profile adds resource-domain application of that state; it does not make SCIM availability or event delivery part of client authentication.

The Governing IdP, directly or through its connector, MUST apply each change to a provisioned Agent Principal's administrative status to every resource domain it has provisioned for that principal, by a SCIM write or by a subscribed event that triggers reconciliation, as Section 3.1 requires, and SHOULD do so promptly after the decision. Where grant-derived revocation under Appendix A.4 is enabled, the IdP MUST retain the identifiers of the ID-JAGs it issued under each delegation, Identity Binding, and Client Association, so that withdrawing any of them can be propagated to the authorization derived from those grants.

3.1. Delivering Administrative Status

Where a Receiver permits just-in-time correlation, an agent can hold authorization in its domain before the Governing IdP has provisioned it there. Once the IdP has issued a grant for an Agent Principal, as the act agent of an ID-JAG or the subject of a WAG, for a resource in the Target Tenant of a Provisioning Domain whose Receiver permits just-in-time correlation, the IdP MUST provision that principal in the domain (Section 4.1). It MUST do so even if it fails between issuing the grant and starting to provision. Recording the obligation durably before issuing the grant meets this; an obligation recorded for a grant that was never issued only provisions the agent early.

A disablement that a later reactivation supersedes still has to take effect at the Receiver, because it invalidates the authorization issued before it (Section 5.2); delivering only the current status would lose it. For an Agent Principal and a Receiver, a pending invalidation exists from a decision to disable the principal, made once the IdP has provisioned the principal in that domain or owes provisioning there, until the Receiver returns success for a disablement that the IdP delivered after the decision.

When it delivers a principal's administrative status to a Receiver, the IdP:

  1. MUST first deliver any pending invalidation as an applied disablement: a SCIM write that sets active to false or, when it provisions the principal, a create with active false.

  2. MUST NOT deliver an activation that a later decision superseded.

  3. MUST serialize delivery for the principal and the Receiver, and MUST NOT lose a pending invalidation when one writer replaces another. A single writer per principal is one way to meet this.

An event that only triggers reconciliation does not discharge a pending invalidation: the Receiver retrieves current state, in which the principal can be active again. After the applied disablement, the IdP delivers the current status by either means.

A disablement and a reactivation that both occur while delivery is down therefore reach the Receiver as active false and then active true: the disablement invalidates the earlier authorization, and the reactivation permits new decisions only. A disablement, a reactivation, and a second disablement reach it as one disablement, with no activation.

A retried disablement can cost availability. If the success response to a disablement write is lost, the IdP still holds the pending invalidation and retries the write. When the Receiver's own reconciliation has meanwhile found the principal active, the retry invalidates the authorization issued in between. It restores no revoked authority, and once it succeeds the IdP delivers the current status, so new decisions follow.

4. Identity and Local Correlation

The federation identity remains the exact pair (IdP issuer, Agent Principal identifier). A Target Tenant scopes local policy and correlation; it is not an additional component of that identity.

For this provisioning interface:

Thus, externalId alone is not a globally qualified identity. A deployment with multiple IdPs MUST retain the context with each resource; it cannot merge records on equal externalId values across issuers. This use of externalId is specific to the IdP-to-resource interface; Section 10.1 maps it from the IdP-side interface of [AGENT-MANAGEMENT].

For delegated access, the RAS MUST resolve the validated ID-JAG's act.iss and act.sub to this pair within the authorized Target Tenant. It MUST NOT use the user subject, OAuth client, display name, or token issuer as a substitute. Comparisons are exact, without case folding or URI rewriting.

The Receiver MUST correlate the pair with at most one local agent principal in the Target Tenant. An existing service principal MAY supply that local representation, but attaching it requires explicit local authorization. The SCIM Agent is then a management view of that same principal, not a second authorization identity.

Federation requires no provisioning protocol. This profile adds a requirement: the RAS MUST have the authorized local correlation before accepting a grant involving the agent. A missing or ambiguous correlation fails under Federation's identity-resolution error rules. [FEDERATION] lets resource policy establish that correlation just in time from a validated grant; Section 4.1 states what a conforming Receiver adds.

4.1. Just-in-Time Correlation

[FEDERATION] defines just-in-time correlation: the resource-policy gate per governing issuer, or issuer and tenant at a multi-tenant issuer, and Target Tenant; exact keying by the pair; and the local restrictions and retained revocation state applied before issuance. A Receiver that correlates agents that way without supporting this interface uses those rules alone and does not conform to this profile.

A conforming Receiver that permits just-in-time correlation MUST NOT expose a record it created that way through SCIM before the Governing IdP provisions its pair (Section 3.1). Until then the record has no SCIM active. Its eligibility, which local policy sets, is one of the local restrictions that Federation requires the RAS to apply, as is Local Suspension.

An otherwise valid and authorized create of an Agent whose externalId is that pair's agent identifier, in the Provisioning Domain of the triggering grant's issuer and, at a multi-tenant issuer, its tenant, MUST NOT fail solely because the record exists. The Receiver MUST bind the new resource to the record's local principal, creating no second one, and MUST keep that principal's local restrictions and retained revocation state. Ordinary SCIM validation still applies, including required attributes and agentUserName uniqueness. The create's active value is an administrative status change to that principal (Section 5.2), so an inactive create invalidates the authorization issued before it.

Once the record is adopted this way, the Agent is provisioned like any other. A later create for the same pair fails with uniqueness, and the connector finds the resource with the externalId query in Section 5. Of concurrent creates for the pair, one binds the record and the others fail the same way (Section 4). A record not yet adopted has never been reconciled, so a stale-state interval claimed under Section 6 runs from its creation. A grant does not carry the IdP's administrative status, so just-in-time correlation does not replace provisioning for disablement.

5. SCIM Provisioning

The interface uses /Agents and the attributes of [SCIM-AGENT], including required agentUserName, plus the common attributes of [RFC7643]. It defines no extension schema. The agentUserName uniqueness that [SCIM-AGENT] requires applies within the Provisioning Domain: this interface reads its server uniqueness that way, because access controls, not only a base URI, can select the context (Section 3). Receivers MUST support creation, retrieval, filtering by externalId, PUT, PATCH, and deletion using [RFC7644]. The Receiver MUST advertise filtering, PATCH, and ETag support in /ServiceProviderConfig.

5.1. Creation and Updates

Creation and PUT requests MUST contain externalId and an explicit boolean active; PATCH removal of either is invalid. Only active: true permits authorization evaluation. Missing required values use invalidValue; conflicting correlation values use uniqueness, following SCIM's error model.

Within the authenticated Provisioning Domain, a connector can reconcile using:

GET /scim/v2/Agents?filter=externalId%20eq%20%22agent-42%22

The Receiver MUST restrict the result to that context. Names, owners, groups, and other descriptive attributes do not select the governed identity or grant delegation.

Versions, ETags, If-Match, the conditional requirement for activating an inactive resource, and incremental reads on meta.lastModified follow the common provisioning conventions of [OAUTH-CLIENT]. In this interface, meta.version is not a lifecycle counter and meta.lastModified is not a source decision time or a grant-revocation boundary; a descriptive edit can change both without affecting authorization. SCIM modification times, SET issuance times, and event timestamps MUST NOT be treated as interchangeable grant-issuance cutoffs under this profile.

5.2. Applying Administrative State

The Receiver MUST authorize changes to active separately from permission to edit descriptive attributes. It MUST preserve Local Suspension and resource permissions independently of upstream administrative updates.

Table 2
Applied action New RAS authorization Existing RAS authorization
Create or set active: true Evaluate correlation, local status, and all Federation checks Does not restore previously revoked sessions
Set active: false Deny grant redemption and refresh involving this principal Revoke associated authorization sessions
Delete the local Agent Deny because the authorized correlation is absent Revoke associated authorization sessions
Change display name, owner, or other descriptive data No implicit change to eligibility or delegation No implicit revocation or grant of authority

The durable restriction rule of [OAUTH-CLIENT] applies to disablement and deletion with the RAS decision point as the decision point; an inactive record or a separate deny marker can provide that state. If session invalidation is asynchronous, a local restriction MUST deny use of the affected sessions until invalidation completes. API observation of revocation follows Section 7.

Reactivation MUST NOT cancel pending invalidation or restore revoked sessions. Recreating a deleted representation likewise does not restore revoked authorization. Receivers MUST retain revocation state for as long as affected tokens or refresh authorizations could otherwise be accepted. This does not require retaining the deleted SCIM resource.

Deleting a local representation does not prove that the IdP retired the Agent Principal globally. Permanent retirement and non-reassignment remain authority responsibilities under [FEDERATION].

5.3. Effective Eligibility

The SCIM active value reports administrative state received through this interface. Effective eligibility also requires an authorized correlation, no Local Suspension, and applicable resource policy. Local Suspension need not be exposed through this SCIM interface.

Owners provide accountability; they are not automatically user delegators. Group membership has only the meaning assigned by local policy. Neither provisioning nor a successful administrative write opens the actor gate.

6. Signals and Reconciliation

SCIM events trigger authoritative reconciliation; CAEP events revoke identified authorization. Appendix A defines their optional composition. Neither event delivery nor current SCIM state supplies a complete history.

For event-driven reconciliation, the parties MUST configure the source SCIM service, retrieval authorization, and mapping from its resource identifier to the qualified agent and Target Tenant. The source and receiver SCIM id values need not match. A GET of the receiver's own replica does not establish the governing IdP's current state.

Direct SCIM connectors and event-driven workers MUST coordinate local writes through the same correlation and conditional-update rules (Section 10.2).

Deployments SHOULD periodically reconcile managed principals even when an event stream appears operational. They MUST document how source outages and incomplete reconciliation affect continued reliance on local state. A deployment claiming a maximum stale-state interval needs an authoritative revalidation mechanism and a policy that denies new authorization and refresh when that interval expires. Receiving traffic or reading the Receiver's replica alone does not satisfy such a revalidation policy.

Transport failure, access denial, and partial list results MUST NOT be interpreted as authoritative deletion. They leave reconciliation incomplete. An authoritative absence for a previously mapped resource requires disablement or deletion of its local representation; the Receiver MUST distinguish that absence from a visibility or authorization failure.

A stream verification event proves neither an individual agent's status nor completion of resource enforcement. A delivery acknowledgment confirms acceptance under the transport, not API denial.

7. OAuth Enforcement

The RAS requirements that apply administrative state to authorization are specified in [FEDERATION]: checking current locally applied eligibility at redemption and refresh, retaining the association needed to invalidate authorization by qualified agent and Target Tenant, and not letting refresh bypass a restriction or restore revoked authorization. Authorization invalidated under those rules is not active for token introspection [RFC7662]. This document supplies the provisioning and signals that feed those decisions and adds no grant issuance-time claim or timestamp comparison. The optional capability in Appendix A.4 additionally retains the ID-JAG issuer and jti. Once reactivated, the principal may establish new authorization under ordinary Federation processing, subject to Section 11.3. Existing tokens whose agent correlation cannot be established MUST NOT be represented as covered by this profile.

7.1. Resource Enforcement and Delay

The API applies Federation's token validation, actor gate, tenant, and sender-constraint rules. The following are deployment choices, not new conformance levels:

Table 3
Resource processing When an applied RAS revocation becomes visible
Introspection on each request On the next successful authorization check; a failed or timed-out check cannot authorize the request
Cached introspection After any permitted active-response cache entry expires or is invalidated
Offline JWT validation At token expiration, unless an independent local restriction takes effect earlier

Caching follows Federation and Section 4 of [RFC7662]. In particular, cached active responses cannot outlive token expiration or the configured freshness limit. Offline validation does not consult principal lifecycle state by itself. The RAS and API MUST configure token lifetimes, expiry leeway, and caching consistently with their accepted revocation delay.

Deployments SHOULD document their expected and maximum disablement delays, including propagation, reconciliation, local application, token lifetime, and caching. A SCIM acknowledgment is not the starting point of an end-to-end guarantee from the governing IdP's original decision. Without a bound on propagation and enforcement, this profile claims no finite end-to-end denial bound. A local stale-state restriction can limit new issuance; it does not by itself revoke already-issued tokens.

8. Revocation Boundaries

Table 4
Change Boundary
Disable the Agent Principal Stop new grants through every binding and client; once applied at the Receiver, deny redemption and refresh and revoke its sessions (Section 5.2)
Disable an Identity Binding Stop new grants through that binding; other bindings remain independent
Withdraw a Client Association Stop that client use; do not infer agent-wide disablement
Revoke a user's delegation Affect that delegation, not unrelated users or self-acting authority
Revoke a workload credential Apply credential validation and IdP policy; do not automatically retire the Agent Principal
Revoke a known ID-JAG Invalidate its derived sessions; do not change principal eligibility
Apply Local Suspension Deny the agent in this resource domain regardless of upstream state; upstream activation cannot clear it

[FEDERATION] defines the binding, association, and delegation relationships. Grant-derived revocation under Appendix A.4 can target known ID-JAGs. Determining all grants affected by withdrawal of a binding or delegation remains an IdP responsibility; the agent identity alone cannot identify that set. OAuth token revocation [RFC7009] can revoke a known token at its issuing server but is not a principal-provisioning or cross-domain notification protocol.

[WISE] can inform the IdP about workloads and credentials. The IdP evaluates those changes against its Identity Bindings before deciding on agent-wide action. Sharing a credential source does not merge principals; losing one credential does not necessarily disable a principal with other valid bindings.

8.1. Self-Acting Access

The self-acting WAG realization in [FEDERATION] correlates the same Agent Principal with the same local principal. Delegated access preserves the qualified actor in act; self-acting access represents the correlated agent as a local subject. Their authority remains distinct. This document defines no [WAG] wire composition or additional WAG claim.

9. Platform-Hosted Agents

A platform that hosts agents and authorizes them for its own resources can register them with the IdP for governance ([AGENT-MANAGEMENT]). The platform is then also the Receiver for those agents, and its own resources form the resource domain. The IdP issues those agents no grants, so Section 7 does not apply; the platform applies the same outcomes in its own authorization.

For a registered agent:

The IdP is not part of the platform's runtime path. The platform authorizes its agents from locally applied state, and an unreachable IdP neither disables nor re-enables them; transport failures follow Section 6. A deployment that needs to bound how long the platform relies on unrefreshed state uses the revalidation policy of Section 6, which then denies new authorization when that bound expires.

Audit records and telemetry about a registered agent's actions SHOULD carry the qualified Agent Principal identifier alongside the platform's own identifier for the agent, so that the IdP and other consumers can correlate them. This document defines no log or telemetry format.

10. Implementation Considerations

These considerations add no requirements. They describe how a connector and a Receiver meet the requirements of the sections cited.

10.1. Connector

When the source uses [AGENT-MANAGEMENT], the connector maps the interfaces as follows; it does not copy the source Agent unchanged:

Table 5: Mapping from the IdP-side Agent
IdP-side source Resource-domain use
Configured governing issuer Issuer established by the authenticated Provisioning Domain
AgentFederation.subject Exact value of the destination Agent's externalId
Agent active Upstream administrative state; local restrictions remain independent
Agent displayName The same descriptive value; it selects nothing (Section 5)
Agent agentUserName A value unique in the destination Provisioning Domain: the source value, or one the connector assigns; it selects nothing (Section 5)
Agent id Source-resource correlation, not the destination SCIM id
Platform-assigned externalId Platform correlation only; not the federated principal identifier

This mapping applies equally to direct provisioning and event-driven reconciliation. It introduces no destination attributes beyond those of [SCIM-AGENT]. A platform's externalId at the IdP remains its own provisioning correlation value. The mutability differs for the same reason: at the platform-to-IdP interface of [AGENT-MANAGEMENT] it is the connector's record key and stays readWrite; here it carries the principal identifier and is immutable once established (Section 4).

Names follow the destination's uniqueness, not the source's. At the IdP, agentUserName is unique within a Provisioning Domain scoped to one Provisioning Client ([AGENT-MANAGEMENT]), so Agents of two such domains can share a name and still reach one destination Provisioning Domain, where it must be unique (Section 5). A uniqueness error on a create whose externalId query finds no Agent is such a collision. The connector then assigns a destination-unique agentUserName, and reuses the value it assigned when it retries. displayName is copied unchanged, and correlation stays on externalId.

Connectors for /Agents are purpose-built for this resource; User and Group support alone is insufficient.

10.2. Receiver

A reconciliation worker reads the Receiver's ETag before retrieving source state, then uses that ETag for its conditional write. After a conflict, it retrieves both again. This prevents an in-flight fetch from overwriting a later local restriction; it does not create a cross-domain transaction or establish that a remote source replica is current (Section 6).

11. Security Considerations

11.1. Provisioning Writers

Provisioning writers can enable principals and change eligibility. Their authority MUST remain scoped to the configured issuer, its tenant at a multi-tenant issuer, and Target Tenant. An event signature, matching display name, or equal externalId outside that context does not establish permission to correlate a principal.

Conditional writes prevent stale updates to a known receiver version; they do not prove that a connector consulted current source state. Compromised or stale connectors can re-enable principals if their write permission remains valid. Administrative authorization, reconciliation, and local suspension therefore remain separate controls.

11.2. Events

Event trust, provisioning permission, and session-revocation authority remain separate. Receivers MUST constrain source retrieval and credential forwarding to authorized endpoints. A signed subject does not authorize arbitrary URL retrieval or cross-tenant revocation.

Event loss and reordering can delay enforcement. Receivers SHOULD retry reconciliation and monitor failures. Revocation state is retained, including across restarts, as Section 5.2 requires. Recovery from lost revocation state MUST NOT silently restore sessions represented as revoked. The explicit limit in Section 11.3 is particularly relevant to unattended refresh.

11.3. Missed Transitions and Reactivation

Current state does not establish transition history. If disablement and reactivation both occur between successful observations, a later active resource does not reveal the missed revocation. A different ETag can also result from an ordinary descriptive edit; it does not identify that history. Section 3.1 therefore does not rely on observation: the Governing IdP delivers each disablement it decided as an applied one, even after it has reactivated the principal, so the Receiver invalidates the authorization issued before it.

Two limits remain. Until the disablement is delivered, authorization issued before it stays usable, within the delays of Section 7.1. And a grant issued before the disablement and first redeemed after the reactivation has no derived authorization for the disablement to invalidate: grant-derived revocation (Appendix A.4) can reach such an ID-JAG, and nothing in this profile reaches such a WAG. Grant validation, replay prevention, and expiration still apply. Sessions actually revoked by the RAS remain revoked.

Deployments requiring rejection of such grants need grant-derived revocation, retained revocation history, an authoritative authorization check, or a separately specified authorization-generation mechanism.

11.4. Offline Tokens

A disabled principal may still have tokens accepted by an offline API. Token expiry and cached responses MUST be included in operational claims; stopping issuance alone does not terminate ongoing work or retract operations already performed.

12. Privacy Considerations

The qualified identity permits correlation across users and resources. Provisioning and event access SHOULD be limited to the receiving domains that need it. Logs SHOULD retain administrative actions and affected identities without copying reusable grants, access tokens, or credentials.

13. IANA Considerations

This document requests no IANA actions.

14. References

14.1. Normative References

[CAEP]
OpenID Foundation, "OpenID Continuous Access Evaluation Profile 1.0", , <https://openid.net/specs/openid-caep-1_0-final.html>.
[SSF]
OpenID Foundation, "OpenID Shared Signals Framework Specification 1.0", , <https://openid.net/specs/openid-sharedsignals-framework-1_0-final.html>.
[WISE]
Lombardo, J., Sneeggen, D., and S. O'Dell, "OpenID WISE Profile Specification 1.0, draft 03", , <https://openid.github.io/ssf-wise-profile/>.
[RFC8417]
Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari, "Security Event Token (SET)", RFC 8417, DOI 10.17487/RFC8417, , <https://www.rfc-editor.org/rfc/rfc8417>.
[RFC9493]
Backman, A., Ed., Scurtescu, M., and P. Jain, "Subject Identifiers for Security Event Tokens", RFC 9493, DOI 10.17487/RFC9493, , <https://www.rfc-editor.org/rfc/rfc9493>.
[RFC9967]
Hunt, P., Ed., Cam-Winget, N., Kiser, M., and J. Schreiber, "System for Cross-Domain Identity Management (SCIM) Profile for Security Event Tokens (SETs)", RFC 9967, DOI 10.17487/RFC9967, , <https://www.rfc-editor.org/rfc/rfc9967>.
[RFC8935]
Backman, A., Ed., Jones, M., Ed., Scurtescu, M., Ansari, M., and A. Nadalin, "Push-Based Security Event Token (SET) Delivery Using HTTP", RFC 8935, DOI 10.17487/RFC8935, , <https://www.rfc-editor.org/rfc/rfc8935>.
[RFC8936]
Backman, A., Ed., Jones, M., Ed., Scurtescu, M., Ansari, M., and A. Nadalin, "Poll-Based Security Event Token (SET) Delivery Using HTTP", RFC 8936, DOI 10.17487/RFC8936, , <https://www.rfc-editor.org/rfc/rfc8936>.
[ID-JAG]
Parecki, A., McGuinness, K., and B. Campbell, "Identity Assertion JWT Authorization Grant", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-assertion-authz-grant-06, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-assertion-authz-grant-06>.
[FEDERATION]
McGuinness, K., "OAuth 2.0 Profile for Agent Principal Federation", Work in Progress, Internet-Draft, draft-mcguinness-oauth-governed-agent-federation, , <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-governed-agent-federation>.
[SCIM-AGENT]
Wahl, M., Zollner, D., Dingle, P., and I. Kazzouzi, "AI Agent Resource Extension for the System for Cross-domain Identity Management (SCIM)", Work in Progress, Internet-Draft, draft-wzdk-scim-agent-resource-00, , <https://datatracker.ietf.org/doc/html/draft-wzdk-scim-agent-resource-00>.
[OAUTH-CLIENT]
McGuinness, K., "SCIM Profile for OAuth 2.0 Client Management", Work in Progress, Internet-Draft, draft-mcguinness-scim-oauth-client-management, , <https://mcguinness.github.io/agent-principal-profiles/draft-mcguinness-scim-oauth-client-management.html>.
[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, , <https://www.rfc-editor.org/rfc/rfc7643>.
[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, , <https://www.rfc-editor.org/rfc/rfc7644>.
[RFC7662]
Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, , <https://www.rfc-editor.org/rfc/rfc7662>.
[BCP14]
Best Current Practice 14, <https://www.rfc-editor.org/info/bcp14>.
At the time of writing, this BCP comprises the following:
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

14.2. Informative References

[AGENT-MANAGEMENT]
McGuinness, K., "SCIM Profile for Agent Principal Management", Work in Progress, Internet-Draft, draft-mcguinness-scim-agent-federation, , <https://mcguinness.github.io/agent-principal-profiles/draft-mcguinness-scim-agent-federation.html>.
[GUIDE]
McGuinness, K., "Implementer's Guide for Agent Principal Federation", <https://github.com/mcguinness/agent-principal-profiles/blob/main/IMPLEMENTERS-GUIDE.md>.
[RFC7009]
Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, , <https://www.rfc-editor.org/rfc/rfc7009>.
[WAG]
Carleton, P., Steele, N., Parecki, A., Schwenkschuster, A., and B. Campbell, "Workload Authorization Grant", Work in Progress, Internet-Draft, draft-carleton-workload-authz-grant-02, , <https://datatracker.ietf.org/doc/html/draft-carleton-workload-authz-grant-02>.

Appendix A. Optional Shared Signals Profile

This appendix profiles existing SCIM Events [RFC9967] and CAEP session-revocation events [CAEP] over Shared Signals [SSF]. It is normative for deployments that enable either capability and defines no new event type or subject format. SCIM event reconciliation and CAEP revocation are independently optional capabilities. A deployment MAY use either or both; it MUST apply the requirements for each enabled capability. Direct SCIM provisioning with CAEP revocation does not require SCIM event subscription or source-resource retrieval.

A.1. Trust and Delivery

Trusted stream configuration MUST establish:

  • The Transmitter, receiving Target Tenant, and audience.

  • For SCIM event reconciliation, the source SCIM service, retrieval authority, and source-resource correlation under Section 6.

  • For grant-derived revocation, the governing ID-JAG issuer, and its tenant at a multi-tenant issuer, whose grants the Transmitter may revoke, and agreement to apply Appendix A.4.

  • For coarse user-and-tenant revocation, the authorized user namespace and revocation scope defined in Appendix A.4.

The SET issuer can differ from the IdP issuer. Their trust relationship comes from configuration; a subject identifier or matching host name cannot establish it.

The authenticated delivery context selects the stream. SET issuer and audience validation, including audience arrays, follows [SSF] and [RFC8417]. SSF uses secevent+jwt and does not use SET exp. Push delivery follows [RFC8935]; poll delivery follows [RFC8936]. The selected transport defines acknowledgment, duplicate handling, and errors. Neither transport is mandatory here. Acceptance acknowledges delivery, not completed reconciliation or API enforcement.

A.2. SCIM Reconciliation Triggers

Receivers MUST accept every provisioning and feed event defined in Sections 2.3 and 2.4 of [RFC9967] as a reconciliation trigger when subscribed to that event type. SCIM event capability is exposed through securityEvents.eventUris in /ServiceProviderConfig under Section 4 of [RFC9967]. SSF stream configuration uses events_supported, events_requested, and events_delivered to establish event delivery. These lists do not authorize a provisioning action or establishes the grant-revocation composition. This profile adds no discovery field. The table uses suffixes under urn:ietf:params:scim:event:.

Table 6
Event suffix Reconciliation behavior
prov:create:notice, prov:patch:notice, prov:put:notice Retrieve current authoritative state
prov:create:full, prov:patch:full, prov:put:full Retrieve current state; the included snapshot does not override it
prov:activate, prov:deactivate, prov:delete Reconcile current state or authoritative absence
feed:add, feed:remove Reconcile the resource and feed coverage; removal from a feed does not establish deletion or disablement

Transmitters MUST report administrative changes for resources covered by an agreed stream using an appropriate subscribed event. Event payloads retain their base meanings. The top-level sub_id uses the RFC 9967 scim format and resource uri. When present, version is the source ETag, not an ordered counter or the Receiver's ETag.

After validating the event and authority for its subject, the Receiver MUST:

  1. Resolve the source service and resource URI to an authorized correlation or provisioning workflow in the configured Target Tenant.

  2. Retrieve current source state and reconcile under Section 6. Source URI resolution MUST remain within the configured service; it cannot redirect retrieval credentials to a caller-selected endpoint.

  3. Retain failed reconciliation as pending and retry or resolve it administratively. Acknowledgment MUST NOT discard pending work.

An authenticated prov:deactivate or prov:delete MAY cause a provisional Local Suspension pending reconciliation. An activation event MUST NOT activate the principal directly. This asymmetry is deliberate: provisional denial can contain risk; granting access requires current authoritative state and local authorization. Successful reconciliation can clear that provisional restriction under local policy, but not an independent Local Suspension. Feed removal and inaccessible sources follow the incomplete reconciliation rules; they are not deletion instructions.

A Receiver that accepts [WISE] lifecycle events about a provisioned principal from a configured Transmitter applies the same asymmetry. workload-disabled and workload-purged MAY cause a provisional Local Suspension pending reconciliation. workload-enabled and workload-restored trigger retrieval of current state and MUST NOT activate the principal directly.

A.3. Platform Signals to the IdP

A platform hosting registered agents (Section 9) MAY transmit events about them to the IdP. Trusted stream configuration MUST establish the platform as Transmitter for the agents its connector registered, and the IdP MUST reject an event about any other agent.

  • Subject: The aliases format of Section 3.2.8 of [RFC9493], containing the iss_sub identifier (the IdP issuer and the registered Agent Principal identifier) and the uri workload identifier that [WISE] uses, which the platform registered as the Agent's externalId. The IdP MUST correlate both identifiers with the same registered Agent, or reject the event.

  • Credential events: [WISE] credential-issued, credential-rotated, credential-revoked, and credential-compromised for the agent's workload credentials.

  • Posture events: [WISE] workload-compromised, anomalous-behavior-detected, workload-degraded, workload-restored, workload-baseline-changed, posture evaluation results, and workload-vulnerability-status-changed.

  • Sessions: CAEP session-revoked when the platform revokes the agent's sessions ([CAEP]).

  • Effect: An event informs IdP policy and monitoring. It does not change the Agent's administrative state, which changes only through [AGENT-MANAGEMENT].

A platform's own workload-disabled, workload-enabled, or workload-purged reports its local control of the agent. It does not change the IdP's active.

The IdP MAY send CAEP risk-level-change for a registered agent to the platform over a stream in the other direction. CAEP defines no principal value for an agent, so stream configuration MUST establish the value used. The platform applies the event under its own policy; a risk event is not an administrative disablement.

A.4. Grant-Derived Session Revocation

The optional capability uses CAEP's existing event type https://schemas.openid.net/secevent/caep/event-type/session-revoked. CAEP permits session properties to identify affected sessions; here the property is the ID-JAG that established their authorization. This composition additionally requires denial before redemption and rejection of later redemption. Ordinary CAEP support or advertisement of the event URI alone does not establish these receiver semantics.

  • The Transmitter MUST use the jwt_id subject format from Section 3.5.1 of [SSF], with iss and jti equal to the issued ID-JAG's corresponding claims. It MUST name a grant it is authorized to revoke. The SET's own jti identifies the event, not the grant.

  • The Receiver MUST verify that the subject's iss matches the governing ID-JAG issuer authorized in the stream configuration. That configuration supplies the Target Tenant. At a multi-tenant issuer, the Receiver MUST apply the revocation, including a denial retained before redemption, only to a grant whose tenant is the tenant that configuration authorizes. The revocation key is (ID-JAG issuer, ID-JAG jti, Target Tenant); it MUST NOT be matched as a bare RAS session identifier or used outside that tenant.

  • On redemption, a participating RAS MUST retain that key with every derived authorization session, access token, and refresh authorization. The Receiver MUST invalidate all authorization derived from that grant in the tenant, including all redemptions, and reject later redemption of the revoked grant.

  • A valid event received before redemption MUST retain a denial for that grant. The Receiver retains it until neither the grant nor derived authorization can be accepted. For an unknown grant, this requires a configured maximum grant acceptance window, including clock leeway; receipt before redemption MUST NOT be treated as a no-op.

This identifies the same grant at both parties without registration of a RAS-generated session ID. Parties MUST NOT enable this composition unless the RAS retains the required correlation and enforces the grant denial. Existing sessions need trustworthy backfilled correlation or remain outside its coverage.

A deployment MAY additionally configure CAEP's complex subject with user in iss_sub format and tenant in opaque format under [RFC9493] to revoke existing sessions for that user and tenant. The parties MUST agree on the user namespace and map it authoritatively to the RAS user, and the tenant MUST match the stream's Target Tenant. All supplied subject conditions MUST match; an unmappable component MUST NOT broaden the revocation. This coarse mode is distinct from grant-derived revocation and does not revoke future grants or unrelated users' sessions.

Neither mode changes Agent active. Revoked authorization remains revoked after activation. CAEP event_timestamp, initiating_entity, and localized reasons retain their meanings; event time is not a cutoff against grant iat. No new claims are introduced.

A.5. Unit of Revocation

Table 7
Action Affected authorization Principal state
Apply Agent disablement or deletion Every RAS session for the qualified agent in the Target Tenant Inactive or absent
Revoke an ID-JAG by issuer-qualified jti All authorization derived from that grant, plus later redemption of it Unchanged
Configured CAEP user-and-tenant revocation Existing sessions matching that user and tenant Unchanged

None establishes a shorter API enforcement delay than Section 7.1.

Appendix B. Shared Delegated Federation Walkthrough

This non-normative walkthrough uses the dedicated-client exchange in [FEDERATION]. It is a specification walkthrough, not an executed implementation test.

B.1. Correlate and Provision

The authenticated provisioning context binds https://idp.example/ to Target Tenant acme-data. The RAS resource is https://api.example/tenants/acme-data/. The connector creates this Agent:

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Agent"],
  "externalId": "agent-42",
  "agentUserName": "analysis-agent",
  "displayName": "Data analysis agent",
  "active": false
}

The RAS assigns SCIM id local-108 to the management representation of local principal service-principal-42 and correlates the context's (https://idp.example/, agent-42) with that principal. The SCIM id is not the principal identifier. Alice is separately represented as user-108; the client is analysis-api. Neither is the agent's correlation identifier.

B.2. Activate and Exchange

The connector reads the resource and receives ETag W/"a1". At 12:01 UTC on September 17, 2026, it applies:

PATCH /scim/v2/Agents/local-108 HTTP/1.1
Host: ras.example
Authorization: Bearer CONNECTOR_ACCESS_TOKEN
Content-Type: application/scim+json
If-Match: W/"a1"

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [{"op": "replace", "path": "active", "value": true}]
}

The placeholder connector token is not a test credential. The Receiver returns a new ETag. At 12:01:03, the IdP issues ID-JAG grant-1 for Alice with act.iss https://idp.example/ and act.sub agent-42. No lifecycle timestamp is added to the grant or compared with its iat.

At redemption, the RAS correlates that pair in acme-data, checks local eligibility and Federation policy, and issues an access token. This example uses introspection. A policy-permitted refresh retains the same user, agent, client, tenant, resource, and authority constraints.

B.3. Disable and Re-enable

At 12:02, an authorized connector sets active: false using the current ETag. Before returning success, the Receiver blocks new RAS authorization and makes existing sessions unusable at the RAS. Subsequent introspection reports those tokens inactive. An API using a previously cached response can continue to accept it only within its configured cache policy.

Alternatively, a SCIM change notice can trigger an authoritative GET and the same local update. Appendix C shows that notice and a CAEP revocation targeting one ID-JAG; revocation need not disable the principal.

At 12:03, reactivation permits new authorization decisions. It does not restore the sessions revoked at 12:02. Had the Receiver been unreachable from 12:02 to 12:03, the connector would still have delivered the disablement before the activation (Section 3.1), with the same effect. An old unredeemed grant is subject to normal grant validation, not a new lifecycle cutoff.

B.4. Acceptance Checklist

Table 8
Case Expected result
Equal externalId under a different IdP context Distinct qualified identity; no automatic correlation
Create for a pair the RAS correlated just in time Adopted: one principal, keeping its local restrictions and revocation state
Two Agents sharing an agentUserName from different IdP-side Provisioning Domains Both provisioned; the connector assigns one a destination-unique name; each correlates by its own externalId
Stale If-Match HTTP 412; retrieve and reconcile before retrying
Descriptive edit Resource ETag may change; no implicit authorization change
Applied disablement New redemption and refresh denied; existing RAS sessions revoked
Reactivation after applied disablement New decisions allowed; revoked sessions stay revoked
Delayed activation notice Retrieve current source state; do not apply the notice as an activation command
Disable and re-enable while the Receiver is unreachable The disablement is delivered, then the activation; sessions from before stay revoked
Disable, re-enable, and disable while the Receiver is unreachable One disablement is delivered, and no activation
Disablement write retried after a lost success response, once reconciliation has found the principal active The retry invalidates authorization issued in between; new decisions follow the IdP's next delivery
Grant issued before a disablement, first redeemed after reactivation Not invalidated by the disablement; grant-derived revocation can reach an ID-JAG
Grant revocation arrives before redemption Retain the denial; reject later redemption
Grant subject issuer differs from the stream's authorized issuer Reject; no cross-issuer revocation
Direct SCIM provisioning with CAEP revocation only No SCIM event subscription or source GET required
Reactivation without a version ETag, including If-Match: * HTTP 409; retrieve and use the current ETag
Feed removal event Reconcile coverage; do not infer deletion
Source unavailable No activation inferred; local stale-state policy applies
SCIM success or SET acknowledgment Does not establish immediate API denial
Offline JWT May remain usable until expiration unless separately restricted

Appendix C. Signal Examples

These decoded SETs omit signatures. Their protected type is secevent+jwt. Trusted configuration binds the stream to governing issuer https://idp.example/ and Target Tenant acme-data; the Transmitter issuer is separately authorized for that namespace.

C.1. Provisioning Change Notice

The trusted source SCIM service has resource /Agents/source-42. Its configured correlation is (https://idp.example/, agent-42), represented at the RAS by /Agents/local-108. At 12:02 UTC on September 17, 2026, the source changes the principal's active value to false:

{
  "iss": "https://signals.idp.example",
  "aud": ["https://ras.example/signals/acme-data"],
  "iat": 1789646520,
  "jti": "change-42",
  "sub_id": {
    "format": "scim",
    "uri": "/Agents/source-42"
  },
  "events": {
    "urn:ietf:params:scim:event:prov:patch:notice": {
      "version": "W/\"source-b7\"",
      "attributes": ["active"]
    }
  }
}

The Receiver retrieves the source Agent, observes active: false, and applies disablement under Section 5.2. The notice itself contains no boolean state, authorization cutoff, or lease. If delivered after a later change, retrieval obtains current state instead.

C.2. Revoke Authorization Derived from an ID-JAG

Separately, an authorized Transmitter can report revocation of the ID-JAG grant-1 issued in Appendix B while the principal remains active:

{
 "iss": "https://signals.idp.example",
 "aud": [
  "https://ras.example/signals/acme-data"
 ],
 "iat": 1789646520,
 "jti": "revoke-grant-1",
 "sub_id": {
  "format": "jwt_id",
  "iss": "https://idp.example/",
  "jti": "grant-1"
 },
 "events": {
"https://schemas.openid.net/secevent/caep/event-type/session-revoked"
  : {
   "event_timestamp": 1789646520,
   "initiating_entity": "admin",
   "reason_admin": {
    "en": "Grant authorization revoked."
   }
  }
 }
}

No principal-state update is implied. Revocation covers every session derived from grant-1, not another grant's sessions or every session involving the same agent.

Appendix D. Platform-Hosted Agent Example

This non-normative example follows one first-party agent on a data platform through signals, a risk change, disablement, and re-enablement under Section 9. The platform's connector registered the agent with the IdP under [AGENT-MANAGEMENT], which returned the Agent Principal identifier, and streams in both directions are configured as Appendix A.3 describes. This deployment sets no revalidation bound (Section 6), so the platform keeps authorizing on locally applied state while the IdP is unreachable. [GUIDE] shows that setup, and the agent's later federation and retirement. Signatures, credentials, and tokens are omitted or shown as placeholders.

Table 9: Example identifiers
Party Identifier
Enterprise IdP https://idp.example/, SCIM base https://idp.example/scim/acme
Data platform https://dataplatform.example/
Platform's workload identifier for the agent (agt-31) wimse://dataplatform.example/agents/agt-31
IdP SCIM resource for the agent /Agents/a58
Agent Principal (https://idp.example/, agent-58)

D.1. Report a Credential Change

At 14:20 UTC on September 17, 2026, the platform rotates the agent's Workload Identity Certificate and reports it to the IdP in a SET with these claims:

{
  "iss": "https://dataplatform.example/",
  "aud": ["https://idp.example/signals"],
  "iat": 1789654800,
  "jti": "pl-cred-31-7",
  "sub_id": {
    "format": "aliases",
    "identifiers": [
      {
        "format": "iss_sub",
        "iss": "https://idp.example/",
        "sub": "agent-58"
      },
      {
        "format": "uri",
        "uri": "wimse://dataplatform.example/agents/agt-31"
      }
    ]
  }
}

Its events claim has one member, whose value is below. The member's key is the WISE event type URI, the base https://schemas.openid.net/secevent/wise/event-type/ followed by credential-rotated:

{
  "credential_type": "wic",
  "previous_credential_id": "serial:31-0006",
  "new_credential_id": "serial:31-0007",
  "event_timestamp": 1789654800,
  "initiating_entity": "system"
}

The IdP accepts the event because this stream's Transmitter registered agent-58 and both identifiers name that Agent. The event updates the IdP's view of the agent; it does not change active.

D.2. Report Anomalous Behavior

At 14:25, the platform observes the agent reading tables outside its usual pattern and sends WISE anomalous-behavior-detected with severity high and the same subject. The event is advisory.

D.3. Raise the Agent's Risk

At 14:30, the IdP's risk analysis, combining the platform's report with other signals, rates the agent HIGH. It sends CAEP risk-level-change with principal AGENT and current_level HIGH to the platform. Platform policy restricts the agent to read-only operations. The agent remains active; a risk event is not a disablement.

D.4. Disable the Agent

At 14:31, an IdP administrator disables agent-58. The IdP sends the platform a SCIM change notice for /Agents/a58, as in Appendix C. The platform retrieves /Agents/a58 from the IdP, observes active: false, and under Section 9:

  • denies new authorization for agt-31;

  • revokes the agent's existing sessions and tokens in its own authorization; and

  • reports session-revoked for agent-58 to the IdP, so the IdP sees that the platform applied the change.

If the notice is lost or the IdP is unreachable, the platform keeps its last applied state, here active and read-only, until its periodic reconciliation retrieves the Agent. An unreachable IdP neither disables nor re-enables the agent.

D.5. Re-enable

At 15:00, the IdP administrator re-enables the Agent, and the platform retrieves and applies active: true. The agent can obtain new authorization. The sessions revoked at 14:31 stay revoked, and the read-only restriction from the risk event remains until platform policy lifts it.

If the platform had suspended the agent itself, re-enablement at the IdP would not clear that Local Suspension.

Appendix E. Document History

RFC Editor: Remove this section before publication.

Acknowledgments

TBD.

Author's Address

Karl McGuinness
Independent