]> Oracle Corporation

Pleasanton CA United States of America saurabh.kushwaha@oracle.com

Security Internet Engineering Task Force SCIM DID Verifiable Credential decentralized identity This document defines an extension to the System for Cross-domain Identity Management (SCIM) for binding SCIM User resources to decentralized identity artifacts, including Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs). The extension introduces a read-only SCIM schema extension for User resources that exposes binding state for discovery, a new SCIM resource type named IdentityBinding that records auditable linkage between a SCIM user and one or more DIDs and credential references, and an optional SCIM schema extension for ServiceProviderConfig that advertises server capabilities for DID and VC binding. This specification intentionally does not define DID resolution, credential issuance, credential transport, or authentication flows. Instead, it defines how a SCIM service provider represents, discovers, queries, and manages binding state derived from those systems. This specification defines binding lifecycle semantics including classification of SCIM attribute changes as material to credential claims, partial revocation when only a subset of credential claims is affected by a SCIM change, three supported lifecycle interleavings between SCIM resources and externally issued credentials, and propagation of binding state changes via SCIM Events .

Introduction SCIM provides a standard protocol and schema model for provisioning and managing identities across administrative domains . SCIM supports new resource types and schema extensions, publishes schema metadata through Schema resources, publishes resource metadata through ResourceType resources, and provides service capability discovery through ServiceProviderConfig . DID Core defines DID documents, verification methods, and proof-purpose relationships, while the Verifiable Credentials Data Model defines issuer, holder, verifier, status, schema, and validation concepts for verifiable credentials . In many deployments, SCIM is the system of record for account lifecycle, while DID and VC systems are the system of record for decentralized identifiers and cryptographic trust. Today that linkage is usually proprietary: implementers invent local attributes, cannot query consistently, and cannot express lifecycle events such as DID deactivation, key rotation, or VC revocation in an interoperable SCIM form. This specification fills that gap by standardizing binding state, not by embedding full DID documents or full VC payloads.

Requirements Language The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. SCIM resource representations in this document are encoded in JSON as required by .

Scope This specification applies to SCIM User resources only. This specification defines schema and resource representations, discovery behavior, filtering, pagination, and PATCH expectations for binding resources, and lifecycle and privacy semantics for DID and VC bindings. This specification does not define DID method semantics, DID resolution protocols, VC issuance or presentation protocols, proof formats, wallet protocols, or authentication and federation replacement.

Problem Statement A provisioning client frequently needs to answer questions such as:

• Which SCIM user is bound to this DID?
• Which users have an active workforce or employment credential from a trusted issuer?
• What is the effect of credential revocation on the provisioned account?
• Can the service provider support pairwise DIDs, credential status checking, and external verifier delegation?

Base SCIM does not answer those questions in an interoperable way.

Design Goals This specification has four goals:

1. preserve SCIM as the provisioning and lifecycle layer;
2. preserve DID and VC systems as the cryptographic trust layer;
3. minimize correlation and over-disclosure; and
4. define a small interoperable subset that clients and servers can implement consistently.

Architecture Overview This specification uses a dual-layer model:

• A read-only User extension provides lightweight discoverability.
• A mutable IdentityBinding resource carries binding state, DID references, credential references, and lifecycle state.

A SCIM service provider MAY validate DID and VC evidence itself or MAY delegate validation to an external verification service. If validation is delegated, the wire protocol between the SCIM service provider and the verifier is out of scope. The SCIM service provider remains responsible for exposing standards-conformant SCIM resources and state transitions. A service provider conforming to this specification MUST NOT persist full DID documents in SCIM resources and MUST NOT persist full VC payloads in SCIM resources. A service provider SHOULD store only references, identifiers, validation timestamps, and normalized outcomes.

Data Model This specification defines three distinct status vocabularies: per-DID status reflects DID document state (such as whether a DID has been verified or deactivated), per-credential status reflects verifiable credential lifecycle state (such as validity-period or revocation outcomes), and binding-level status reflects the composite lifecycle of the IdentityBinding resource itself. These vocabularies are intentionally not unified. The aggregate User.bindingState additionally defines the value none to indicate a user with no bindings (see ), which does not appear in any resource-level status.

User Extension Schema The schema URI for the User extension defined by this specification is urn:ietf:params:scim:schemas:extension:didvc:2.0:User. This extension is a derived, read-only projection of the user's decentralized identity binding state. Clients do not create bindings by writing this extension; they create or modify IdentityBinding resources. User Extension Attributes

Attribute	Type	MV	Req	Mutability	Values	Description
primaryDid	string	no	no	readOnly	-	The verified primary DID currently associated with the user, if any. Derived from the active primary IdentityBinding per the algorithm in .
bindingState	string	no	yes	readOnly	none, pending, active, suspended, revoked, rejected	Aggregate state derived from active bindings for the user. The value none indicates the user has no associated IdentityBinding resources and does not appear in binding-level status vocabularies.
bindingRefs	complex	yes	no	readOnly	-	References to IdentityBinding resources associated with the user.

bindingRefs Sub-Attributes

Sub-Attribute	Type	Req	Mutability	Values	Description
value	string	yes	readOnly	-	The SCIM id of the IdentityBinding resource.
$ref	reference	yes	readOnly	-	URI of the IdentityBinding resource.
display	string	no	readOnly	-	Human-readable label for the binding.
primary	boolean	no	readOnly	-	Indicates whether this binding is the source of primaryDid.
status	string	yes	readOnly	pending, active, suspended, revoked, rejected	Current lifecycle state of the referenced binding.

A conforming server MUST derive primaryDid, bindingState, and bindingRefs from IdentityBinding resources, MUST NOT allow clients to directly mutate this extension, MUST omit primaryDid when no verified primary DID exists, and MUST ensure that at most one bindingRefs entry has primary=true.

Derivation of primaryDid A server MUST derive User.primaryDid using the following algorithm:

1. Collect all IdentityBinding resources whose user.value matches the target user and whose binding-level status is active.
2. From that set, select the binding for which bindingRefs.primary=true is set in the User extension projection. At most one such binding is permitted.
3. Within that binding, select the dids entry with primary=true and status=verified.
4. Set User.primaryDid to the value of that DID entry. If no such entry exists, omit User.primaryDid.

A server MUST NOT set User.primaryDid from a binding that is not in active status, and MUST clear User.primaryDid when the binding that sourced it transitions out of active status or is deleted. If multiple active bindings each contain a DID entry with primary=true, the server MUST reject creation or PATCH operations that would produce this ambiguous state with HTTP 400 and a SCIM error type of invalidValue.

IdentityBinding Resource The IdentityBinding resource type uses the endpoint /IdentityBindings and the schema URI urn:ietf:params:scim:schemas:extension:didvc:2.0:IdentityBinding. An IdentityBinding resource represents the auditable linkage between one SCIM User resource and one or more DIDs, together with optional references to credentials whose validation influences the state of the binding. All IdentityBinding resources include the standard SCIM common attributes defined in Section 3.1 of , including id, externalId, and meta. The meta.lastModified timestamp records the time of the most recent update to the resource representation. The lastValidationAttempt attribute defined in this specification is distinct from meta.lastModified: it records when a validation cycle was last run against the DID and credential evidence, which may differ from when the resource itself was last written. IdentityBinding Attributes

Attribute	Type	MV	Req	Mutability	Values	Description
user	complex	no	yes	immutable	-	Reference to the bound SCIM User.
correlationModel	string	no	yes	immutable	pairwise, shared, public	Privacy expectation for DID reuse across relying parties. See for the relationship between this field and per-DID relationship values.
dids	complex	yes	yes	readWrite	-	DIDs associated with the binding.
credentials	complex	yes	no	readWrite	-	Credential references associated with the binding.
status	string	no	yes	readOnly	pending, active, suspended, revoked, rejected	Binding lifecycle state.
lastValidationAttempt	dateTime	no	no	readOnly	-	Timestamp of the most recent validation attempt, regardless of outcome. Updated on both successful and failed validation runs. Distinct from meta.lastModified, which reflects resource write time.
statusReason	string	no	no	readOnly	-	Human-readable explanation for the current status.
materialChangeMask	string	no	no	readOnly	-	Server-computed opaque fingerprint over the User-attribute values that source bound credential claims. Used internally by the server to detect material changes per . Servers MUST NOT expose the algorithm used to compute the fingerprint to clients; the value is intended for comparison only.

user Sub-Attributes

Sub-Attribute	Type	Req	Mutability	Description
value	string	yes	immutable	The SCIM id of the bound User.
$ref	reference	yes	immutable	URI of the bound User.
display	string	no	readOnly	Human-readable display name for the user.

dids Sub-Attributes

Sub-Attribute	Type	Req	Mutability	Values	Description
value	string	yes	readWrite	-	DID URI.
relationship	string	yes	readWrite	primary, pairwise, delegated, recovery	Role of the DID in the binding. See for the distinction between this field and the binding-level correlationModel. The value recovery designates a DID that is authorized to execute key recovery operations for the primary DID of the binding, as defined by the applicable DID method; its presence does not affect binding-level status derivation.
verificationMethod	string	no	readWrite	-	DID URL of the verification method used for proof evaluation.
proofPurpose	string	no	readWrite	authentication, assertionMethod	DID proof purpose expected for verification.
controller	string	no	readWrite	-	DID controller identifier when known.
primary	boolean	no	readWrite	-	Indicates the preferred DID for the binding.
status	string	yes	readOnly	pending, verified, deactivated	Per-DID validation status. The value deactivated aligns with the DID Core specification's terminal state for a DID document .

credentials Sub-Attributes

Sub-Attribute	Type	Req	Mutability	Values	Description
credentialId	string	no	readWrite	-	Identifier of the VC, if present.
types	string	yes	readWrite	-	VC type values relevant to the binding. Multi-valued.
issuer	string	yes	readWrite	-	Issuer identifier, commonly a DID or URI.
holder	string	no	readWrite	-	Holder identifier, if expressed by the ecosystem. Implementers SHOULD omit this field unless explicitly required, as holder DIDs can create correlation risk (see ).
credentialSubjectId	string	no	readWrite	-	Credential subject identifier, if available. Implementers SHOULD omit this field unless explicitly required, as subject DIDs can create correlation risk (see ).
statusRef	reference	no	readWrite	-	Reference to credential status information.
schemaRef	reference	no	readWrite	-	Reference to credential schema information.
validFrom	dateTime	no	readWrite	-	Start of credential validity, if known.
validUntil	dateTime	no	readWrite	-	End of credential validity, if known.
status	string	yes	readOnly	pending, active, revoked, expired, unknown	Server-normalized outcome for the credential reference.
boundClaims	string	no	readWrite	-	Multi-valued. Names of credential claims whose truth depends on the bound SCIM User's attributes. Used together with boundSourceAttributes to determine material change. See .
boundSourceAttributes	string	no	readWrite	-	Multi-valued. SCIM attribute paths (e.g., active, groups.value, urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department) whose current values source the credential's bound claims.
materialChangePolicy	string	no	readWrite	strict, role-sensitive, advisory	Policy that determines server behavior when a material change to a source SCIM attribute is detected for this credential. Defaults to role-sensitive. See .
partialRevocationMode	string	no	readWrite	none, claim-scoped, reissuance, claim-flag	How the credential supports partial revocation when only a subset of bound claims is affected by a material change. Defaults to none (whole-credential revocation only). See .

A conforming server MUST require at least one dids entry in every IdentityBinding, MUST permit at most one dids entry with primary=true, MUST require relationship=primary on any DID entry with primary=true, and MUST set status=pending on creation unless the server can validate synchronously before returning the resource. A conforming server MUST NOT set status=active unless at least one DID entry has status=verified. The server MUST update User.primaryDid when the binding becomes active or inactive per the algorithm in , and MUST reject creation of more than one active IdentityBinding containing the same DID value within a single administrative scope (the SCIM service provider, or in multi-tenant deployments, a single tenant) when the binding's correlationModel is pairwise, regardless of which User is referenced.

Relationship Between correlationModel and dids.relationship The correlationModel attribute on an IdentityBinding and the relationship sub-attribute on individual DID entries operate at different levels of abstraction and are not redundant. correlationModel is a binding-level declaration of the privacy expectation for DID reuse across relying parties. A value of pairwise means the DIDs in this binding are intended for use only with this relying party and MUST NOT be reused at other services. A value of shared means the DIDs may be shared across a defined set of relying parties. A value of public means the DIDs are publicly shareable without restriction. dids.relationship describes the functional role of a specific DID within the binding (e.g., primary for the main authentication DID, delegated for a capability-delegation DID, recovery for a key-recovery DID). A binding with correlationModel=pairwise may contain multiple DID entries with different relationship values; the correlation model applies to all of them collectively. The combination correlationModel=shared with relationship=pairwise on an individual DID entry is permitted when one DID in the binding is used only pairwise while others in the same binding are shared.

ServiceProviderConfig Extension The schema URI for the ServiceProviderConfig extension defined by this specification is urn:ietf:params:scim:schemas:extension:didvc:2.0:ServiceProviderConfig. This extension advertises the server's DID and VC binding capabilities without modifying the core ServiceProviderConfig schema. ServiceProviderConfig Extension Attributes

Attribute	Type	MV	Req	Mutability	Values	Description
enabled	boolean	no	yes	readOnly	-	Indicates whether DID/VC binding is currently enabled for new IdentityBinding creation. A server MAY deploy the extension schema while setting this to false to indicate temporary suspension of new binding intake.
verificationDelegation	string	no	yes	readOnly	internal, external, mixed	Whether verification is performed by the SCIM server (internal), an external verifier (external), or both depending on DID method or credential type (mixed). When mixed, clients SHOULD NOT assume a specific verification path for any given DID method or credential type without out-of-band knowledge.
supportedDidMethods	string	yes	no	readOnly	-	DID methods accepted by the service provider.
supportedCredentialChecks	string	yes	no	readOnly	status, schema, validity, holderBinding	VC checks the server is capable of evaluating.
supportedCorrelationModels	string	yes	yes	readOnly	pairwise, shared, public	Correlation models supported by the server.
supportedMaterialChangePolicies	string	yes	no	readOnly	strict, role-sensitive, advisory	Material change policies () the server is capable of enforcing. A server that omits this attribute is assumed to support only role-sensitive. A client MUST NOT declare a materialChangePolicy value on a credential entry that the server does not advertise.
supportedPartialRevocationModes	string	yes	no	readOnly	none, claim-scoped, reissuance, claim-flag	Partial revocation modes () the server supports. A server that omits this attribute is assumed to support only none. A client MUST NOT declare a partialRevocationMode value on a credential entry that the server does not advertise.
propagationIntervalSeconds	integer	no	no	readOnly	-	The maximum interval, in seconds, that the server commits to between a SCIM operation affecting a binding and completion of the propagation procedure of . This value bounds the lifecycle-consistency property of . Servers SHOULD publish this value; clients and downstream relying parties MAY use it for risk assessment.

Processing Model

Creation A client creates a User resource using normal SCIM semantics. A client creates an IdentityBinding by POSTing to /IdentityBindings. The client MUST provide user, correlationModel, and at least one dids entry. The client MAY include credentials. The server MUST verify that user.value references an existing User resource and MUST return HTTP 400 with SCIM error type invalidValue if the reference cannot be resolved. Upon creation, the server MUST create the resource in pending status unless synchronous validation has already completed successfully, MUST record normalized validation results in per-DID and per-credential status fields, and MUST update the derived User extension when binding state changes. The server MUST return HTTP 201 with a Location header pointing to the created resource.

Validation This specification requires that DID control be verified before a binding may become active. How a client presents DID control evidence to the SCIM server (e.g., via a challenge-response protocol, a Verifiable Presentation submitted in a related flow, or a proof in a request header) is out of scope for this specification. Implementations SHOULD consult relevant specifications such as OpenID for Verifiable Presentations or DIF Presentation Exchange for proof transport mechanisms that can be integrated with SCIM deployment. To validate DID control, the server or delegated verifier MUST resolve the DID and verify that the verification method used for proof checking is authorized for the appropriate proof-purpose relationship in the DID document . The server MUST re-resolve DID documents when revalidating a binding, and MUST NOT rely on cached DID resolution results whose age exceeds the server's configured revalidation window. To validate a credential reference, the server or delegated verifier MUST, where applicable, verify cryptographic integrity, evaluate issuer and controller consistency, evaluate validFrom and validUntil, evaluate credential status when status information is available, and evaluate credential schema when schema information is available . This specification does not define proof formats or verifier APIs.

Lifecycle Interleaving An IdentityBinding can be created at different points in the lifecycle of the credentials it references. Three interleaving patterns are supported. The protocol behavior differs at the moment of binding creation; subsequent lifecycle handling is identical across all three.

Resource-First The SCIM User resource exists, an IdentityBinding is created, and a credential is subsequently issued by the credential issuer under the coordination of the binding. At the moment of binding creation, the credentials array MAY be empty or MAY contain credential references with status=pending. The server MUST permit creation of an active binding (i.e., transition to active) once at least one dids entry is verified, even when no credentials are yet referenced. Credentials added later via PATCH undergo per-credential validation as defined in .

Credential-First The holder already possesses one or more credentials issued at some prior time, and an IdentityBinding is created retrospectively to bring those credentials under SCIM-managed governance. At the moment of binding creation, the credentials array contains references to existing credentials. For credential-first bindings, the server MUST validate each referenced credential as defined in and MUST compute the materialChangeMask attribute as defined in based on the current state of the bound User's attributes. If any referenced credential is found to have status revoked or expired, the server MUST record that per-credential status and MUST NOT treat it as active. The binding itself MAY still transition to active if other DID and credential checks succeed. A credential-first binding does not retroactively alter the prior state of the credential; it begins governance at the time the binding is created. The server MUST document this temporal boundary in deployment guidance, as activity prior to the binding may not produce audit records on the SCIM side.

Joint The binding and the credential are created as part of a single coordinated issuance flow. The client submits a binding creation request together with (or immediately followed by) credential issuance at the credential issuer, with the binding acting as the governance record from the start. The server's per-credential validation occurs against the newly issued credential and the materialChangeMask is computed from the User attributes present at the time of issuance. The protocol does not define the wire-level coordination between the SCIM service provider and the credential issuer for joint issuance; that coordination is out of scope and is expected to use existing issuance protocols such as OpenID for Verifiable Credential Issuance.

State Transitions The server MUST implement the following binding-state semantics: Binding State Transitions

From	To	Condition
pending	active	Required DID proof and all required credential checks succeed.
pending	suspended	Validation attempt is temporarily inconclusive before the binding has ever been active (e.g., DID resolver unavailable at creation time).
pending	rejected	Validation fails conclusively before the binding has ever been active.
active	suspended	Revalidation is temporarily inconclusive, such as unavailable resolver or unknown credential status.
active	revoked	DID deactivation, credential revocation, or policy failure is confirmed.
suspended	active	Revalidation succeeds.
suspended	revoked	Negative status is later confirmed.
rejected	pending	Client corrects DID evidence via PATCH and requests re-evaluation (see ).

Once a binding has transitioned to active, subsequent conclusive validation failure results in transition to revoked, not rejected. The rejected state applies only to bindings that never achieved active status. The revoked state is terminal. To re-establish trust after a binding reaches the revoked state, a client MUST create a new IdentityBinding resource; a server MUST NOT transition a revoked binding back to pending, active, or suspended. A server MUST NOT treat unknown or missing validation results as equivalent to active.

Re-evaluation of Rejected Bindings A client MAY request re-evaluation of a binding in the rejected state by submitting a SCIM PATCH request that replaces or updates one or more dids entries (for example, correcting an invalid verificationMethod, replacing an unresolvable DID value, or adding a new DID entry). Upon receiving such a PATCH, the server MUST transition the binding to pending status and MUST initiate a new validation cycle. The server MUST NOT require the client to delete and recreate the resource solely to trigger re-evaluation after a correctable rejection.

Material Change Classification A material change to a SCIM User is a change to one or more of the User's attributes whose values source the bound claims of a credential in an associated IdentityBinding. Material changes invalidate, in whole or in part, the truth of those bound claims. The protocol defines how a service provider classifies SCIM operations as material with respect to each credential it governs and how the classification drives the binding lifecycle.

materialChangeMask Computation At binding creation, and at every operation that modifies the bound User, the server MUST compute, for each credential c in the binding, a fingerprint over the values of the SCIM attributes listed in c.boundSourceAttributes. The aggregated fingerprint across all bound credentials in the binding is stored in materialChangeMask. A change to materialChangeMask between successive validation cycles indicates that at least one bound source attribute has changed value. The fingerprint algorithm is server-internal. A server SHOULD use a cryptographic hash over the canonical JSON representation of the source attribute values, ordered by attribute path. The server MUST NOT expose the fingerprint construction in a way that reveals individual attribute values to clients that do not otherwise have authorization to read them.

Per-Credential Policies The behavior of a service provider on detection of a material change is determined by the materialChangePolicy sub-attribute of the affected credential entry. The protocol defines three policies:

• strict: any change to any attribute listed in boundSourceAttributes for this credential triggers transition of the binding's status with respect to this credential to revoked. If the credential supports partial revocation (see ), only the affected claims are revoked.
• role-sensitive: only changes to attributes mapped to claims about role, group membership, employment status, or entitlement trigger revocation. Changes to attributes such as contact information, postal address, or display name do not. A server implementing this policy MUST document which SCIM attribute paths are treated as role-related for the purpose of this classification, either in deployment documentation or through the ServiceProviderConfig extension. This is the default policy.
• advisory: the change is recorded in statusReason and surfaced via SCIM Events (see ) but no automatic revocation is performed. Operators or downstream automation are expected to act on the advisory signal.

A server MUST apply the policy declared on each credential entry independently. Different credentials in the same binding MAY declare different policies.

Classification Examples The following table illustrates the default (role-sensitive) classification of common SCIM attribute changes. The classification of any specific attribute is deployment-dependent and is determined by the boundSourceAttributes declared on each credential entry. Example Classification of SCIM Attribute Changes

Attribute change	Default classification
active: true to false	Material (terminal)
groups: removal of a group claimed in credential	Material
Enterprise department: change	Material if department is in bound claims
Enterprise manager: change	Advisory by default
phoneNumbers: update	Not material
emails: primary address change	Advisory by default
name.formatted: spelling correction	Not material
addresses: relocation	Not material

Partial Revocation A credential MAY carry multiple claims, only some of which are invalidated by a given material change. Whole-credential revocation in such cases is unnecessarily destructive. The protocol supports partial revocation through three mechanisms, selected per credential entry via the partialRevocationMode sub-attribute.

Claim-Scoped Status References A credential issued under partialRevocationMode=claim-scoped carries one status reference per bound claim, in addition to (or in place of) a whole-credential status reference. When a material change affects a subset of bound claims, the server (or the credential issuer notified via the propagation procedure of ) updates only the per-claim status references corresponding to the affected claims; the whole-credential status remains active. The credential format used to express per-claim status references is out of scope for this specification. Implementations expecting interoperability SHOULD consult the W3C Bitstring Status List specification, the SD-JWT family of specifications, or other published profiles that define per-claim status semantics for the credential format in use.

Reissuance for Claim Subset A credential issued under partialRevocationMode=reissuance is replaced, on detection of an affecting material change, by a newly issued credential containing only the still-true claims; the prior credential is revoked in full. The server MUST notify the credential issuer via the propagation procedure of and MUST record the prior credential's reference as historical (using the relationship=historical indicator if defined by the deployment's credentials sub-attribute extensions) and the newly issued credential's reference as the current entry. Until the credential issuer confirms reissuance, the server MUST set the prior credential entry's status to pending revocation by recording the transitional state in statusReason.

Claim-Level Revocation Flag For credentials that cannot be split or reissued (for example, opaque legacy credentials), a credential entry under partialRevocationMode=claim-flag carries a server-recorded list of revoked claims. The whole-credential status remains active, but the binding's statusReason records that specific claims are revoked. A verifier that consults the binding can observe the claim-level state; a verifier that consults only the credential's primary status reference cannot. This mechanism is the weakest of the three because it depends on the verifier reaching the binding directly, but it provides an audit record where the other mechanisms are unavailable.

Default Behavior A credential entry that does not declare partialRevocationMode, or declares partialRevocationMode=none, is subject to whole-credential revocation on any material change classified as revocation-triggering by the applicable policy.

Revocation Propagation When a SCIM operation on a User causes a transition that affects an associated IdentityBinding (deactivation, suspension, material change beyond the per-credential threshold, or other policy-driven outcome), the server MUST perform the following propagation procedure:

1. Enumerate all IdentityBinding resources whose user.value references the changed User and whose status is active or suspended.
2. For each enumerated binding, recompute the materialChangeMask per and classify the change per the policies declared on each credential entry.
3. For each affected credential entry, apply the per-credential policy (revoke the entry, mark the binding revoked, mark claims-level revocation per , or record an advisory).
4. If the User is deactivated, the binding's overall status MUST transition to revoked within the server's documented propagation interval and the per-credential revocation procedure MUST be triggered for every credential entry in the binding.
5. Emit a SCIM Event per for each affected binding. The event type SHOULD indicate whether the change is a material-attribute change, an explicit revocation, or an advisory signal.
6. For each affected credential entry, notify the credential issuer via an out-of-band mechanism. The notification mechanism is out of scope for this specification, but implementations SHOULD use a SCIM Event subscription, a webhook, or another reliable asynchronous channel. The notification MUST identify the affected credential, the affected claims (if known), and the binding-level outcome.

The propagation procedure MUST be idempotent: a server that re-runs the procedure for the same input MUST produce the same SCIM-side outcome and SHOULD deduplicate notifications to the same credential issuer for the same logical change. A conforming server SHOULD publish its propagation interval (the maximum time between the SCIM operation and the completion of the propagation procedure) via the propagationIntervalSeconds attribute of the ServiceProviderConfig extension (). The propagation interval bounds the lifecycle-consistency property defined in .

Group Change Cascade SCIM Group operations can affect bindings indirectly: a User's bound credentials may claim group membership, and a change to the Group rather than the User is then the material event. A conforming server MUST extend the propagation procedure to Group operations as follows:

1. On removal of a member from a Group (via PATCH on the Group's members attribute or via PUT replacement), the server MUST treat the removal as a change to the affected User's groups attribute and run the propagation procedure for that User. Only bindings whose credential entries list groups or groups.value among boundSourceAttributes are affected.
2. On deletion or deactivation of a Group, the server MUST enumerate the Group's members and run the propagation procedure for each affected User. The server SHOULD process the cascade asynchronously for large groups and MUST complete the cascade within its published propagation interval. If the cascade cannot complete within the published interval (for example, for groups whose membership exceeds an implementation limit), the server MUST emit a SCIM Event indicating a delayed cascade so that subscribers can distinguish an in-progress cascade from a completed one.
3. Nested group membership (groups whose members are groups) MUST be expanded transitively before enumeration, subject to the same completion and signaling requirements.

The cascade is classification-driven, not unconditional: a Group change that no bound credential depends on (per the declared boundSourceAttributes) results in mask recomputation but no revocation. This bounds the blast radius of large Group operations to the bindings that actually claim membership.

Deletion A service provider implementing this specification MUST support DELETE for IdentityBinding resources. Upon successful deletion of an IdentityBinding resource, the server MUST remove the corresponding entry from the associated User's bindingRefs and MUST clear User.primaryDid if the deleted binding was the source of that value. The server MUST recalculate User.bindingState after deletion. A server MAY reject deletion of a binding in active status and require the client to first transition it to a non-active state via PATCH. If such a restriction is imposed, the server MUST document this behavior in its ServiceProviderConfig or deployment documentation. A server MUST return HTTP 204 on successful deletion.

Query, Filtering, PATCH, and Pagination

Filtering SCIM filter expressions and fully qualified attribute notation are defined by . Filter attribute values in request URIs MUST be percent-encoded as required by RFC 3986; the examples in this section show decoded values for readability. A service provider implementing this specification MUST support GET filtering on /IdentityBindings using the eq operator for the following attributes:

• user.value
• dids.value
• dids.relationship
• credentials.issuer
• credentials.types
• status
• externalId (a common attribute defined in Section 3.1 of and inherited by all SCIM resource types)

A service provider implementing this specification MUST additionally support the co (contains) and pr (present) operators for the multi-valued string attributes credentials.types and dids.value. This allows clients to filter by partial VC type values (e.g., credentials.types co "EmploymentCredential") and to find resources that have at least one credential or DID present. A service provider implementing the User extension MUST support eq filtering on urn:ietf:params:scim:schemas:extension:didvc:2.0:User:primaryDid. A service provider implementing this specification MUST support the and logical operator in combination with the attributes above. Support for the or and not operators is OPTIONAL.

Example Filter by DID (values shown decoded; apply percent-encoding in actual requests)

Example Combined Filter

Example Filter Using co Operator on Multi-valued types

Example User Filter by primaryDid

PATCH A service provider implementing IdentityBinding MUST support SCIM PATCH as defined by . PATCH request bodies MUST conform to the PatchOp message format defined in Section 3.5.2 of , which requires the schemas member and an Operations array wrapping all individual operation objects. Clients SHOULD target explicit paths. A server MUST return HTTP 400 with a SCIM error type of mutability when a PATCH attempts to modify an attribute declared as immutable (such as user or correlationModel) or readOnly (such as status or lastValidationAttempt).

Example PATCH to Set a Primary DID Flag

Example PATCH to Update a Credential Schema Reference

Example PATCH to Correct a DID and Trigger Re-evaluation of a Rejected Binding

Pagination List operations for IdentityBinding resources MUST support SCIM list pagination as defined by . A service provider MAY additionally support cursor-based pagination as defined by .

Error Handling A conforming server MUST return SCIM error responses as defined in Section 3.12 of for all error conditions. The following table enumerates error conditions specific to this specification. Binding-Specific Error Conditions

Condition	HTTP Status	SCIM scimType
user.value references a non-existent User	400	invalidValue
Request includes more than one dids entry with primary=true	400	invalidValue
A dids entry has primary=true but relationship is not primary	400	invalidValue
Creation of a pairwise binding with a DID already used in another active pairwise binding within the same administrative scope	409	uniqueness
PATCH attempts to modify an immutable attribute (user, correlationModel)	400	mutability
PATCH attempts to modify a readOnly attribute (status, lastValidationAttempt)	400	mutability
Multiple active bindings with primary=true would result from the operation	400	invalidValue
DELETE attempted on an active binding when the server requires non-active status first	409	-
A credentials entry declares a boundSourceAttributes path that is not a valid SCIM attribute path on the bound User's schemas	400	invalidPath
A credentials entry declares a materialChangePolicy value not advertised in the server's supportedMaterialChangePolicies	400	invalidValue
A credentials entry declares a partialRevocationMode value not advertised in the server's supportedPartialRevocationModes	400	invalidValue

Discovery and Deployment A service provider implementing this specification MUST publish the User extension schema via /Schemas, MUST publish the IdentityBinding schema via /Schemas, MUST publish the IdentityBinding resource type via /ResourceTypes, and SHOULD publish the ServiceProviderConfig extension when supported. Examples of the expected /Schemas and /ResourceTypes entries are provided in . A SCIM client unaware of this specification will continue to interoperate with base User provisioning because unknown schema extensions and unknown resource types are discoverable rather than mandatory for unrelated operations.

Security Considerations

Threat Model Relevant attackers include a client that attempts to bind a DID it does not control, a client that replays stale credentials or proofs, an attacker exploiting DID key rotation or deactivation lag, an attacker inducing false correlation by reusing identifiers across relying parties, a malicious or unexpected issuer, and a compromised or confused delegated verifier.

Security Properties A conforming implementation, together with conforming clients and a trustworthy credential issuer, is expected to provide the following security properties. Each property is stated informally and then precisely; the precise statement is the obligation that the protocol behavior defined elsewhere in this document is required to satisfy.

Binding Integrity No party other than a SCIM client authorized over both the target SCIM User resource and the DID being bound is able to create or modify an IdentityBinding linking the two. Precisely: if at any time an IdentityBinding resource B exists with B.status != revoked, the binding's user reference and at least one verified DID entry, then at some prior time an authenticated SCIM client with administrative authorization over the referenced User and demonstrated control over the DID submitted a creation or modification request that produced B.

Revocation Soundness After the propagation procedure of completes for a binding that has transitioned to revoked, no verifier following the credential-status verification procedure of accepts a credential bound by that IdentityBinding. This property holds only for credentials that publish status references and for verifiers that consult them. The protocol does not constrain verifiers that fail to check status.

Lifecycle Consistency If the principal SCIM User resource referenced by an IdentityBinding is in a deactivated state, no binding linked to that User remains in the active state beyond the server's documented propagation interval. Precisely: for any IdentityBinding B with B.user = u, if u.active = false at time t, then B.status != active at all times t + Delta and later, where Delta is the server's documented propagation interval (see ).

Freshness and Replay Resistance A binding creation or modification request cannot be effected by replaying a previously legitimate request. The protocol relies on DID control proofs that bind to a server-issued challenge (see ) and on credential validation results that bind to a specific validation timestamp (see ).

Principal-of-Record Consistency At most one principal SCIM User resource is authoritatively bound to a given DID under a given correlation model at any one time. Precisely: for every DID value d and every time t, the number of IdentityBinding resources B such that B.dids[i].value = d, B.dids[i].status = verified, B.status = active, and B.correlationModel != pairwise is at most 1. Under correlationModel = pairwise, the property is satisfied trivially by the uniqueness check defined in .

Required Mitigations A conforming implementation MUST evaluate DID proof authorization against the relevant DID verification relationship at verification time, MUST re-resolve DID information when revalidating a binding after key rotation or deactivation events are possible, MUST treat credential status as a verifier-side check when status information is available, MUST integrity-protect communication with any delegated verifier and authenticate that verifier, MUST apply normal SCIM authorization controls to IdentityBinding resources, and MUST NOT treat unverified bindings as equivalent to active verified bindings.

DID Control Proof Delivery This specification requires that a SCIM server verify DID control before activating a binding, but the mechanism by which a client presents DID control evidence is intentionally out of scope. Implementers are responsible for defining or adopting a proof transport mechanism appropriate for their deployment. Relevant existing specifications include OpenID for Verifiable Presentations (OID4VP) and the DIF Presentation Exchange specification. The SCIM service provider MUST document the proof delivery mechanism it accepts as part of its deployment documentation. Regardless of the mechanism chosen, a server MUST NOT accept a DID control proof that was generated for a different relying party, binding resource, or session. Servers SHOULD require proof presentations to include a challenge or nonce issued by the server to prevent replay of previously valid proofs.

Replay Attack Mitigation A server SHOULD issue a fresh, single-use nonce or challenge when initiating a DID control proof exchange and MUST reject proof presentations that do not bind to the current challenge. Similarly, credential validation results MUST be treated as bound to a specific validation timestamp and MUST NOT be replayed from a prior successful validation to satisfy a new validation request.

Delegated Verifier Trust Scope When a SCIM service provider delegates DID or VC validation to an external verifier, the verifier becomes a critical trust anchor for the entire binding model. A compromised or misconfigured delegated verifier that returns status=verified for any DID can activate bindings without genuine cryptographic proof of control. Implementations MUST scope the trust granted to a delegated verifier to the minimum necessary (e.g., specific DID methods or credential types), MUST authenticate the verifier at the transport layer, and SHOULD audit verifier responses for anomalies such as bulk activation of previously-pending bindings.

DID Method Considerations The security and freshness characteristics of a binding depend on the DID methods the server accepts. This specification is method-agnostic, but implementers selecting values for supportedDidMethods should account for the following method-class differences.

• Statically derived methods (e.g., did:key): the DID document is computed from the identifier itself and cannot be rotated or deactivated. Deactivation of the DID is therefore not observable through resolution, and the binding's revocation path runs entirely through SCIM-side state and credential status. Such methods are appropriate where key compromise is handled by binding replacement rather than key rotation.
• Web-based methods (e.g., did:web): resolution inherits the trust properties of TLS, DNS, and the hosting domain. A domain takeover or web-server compromise permits substitution of the DID document, including its verification methods. Servers accepting web-based methods SHOULD cache resolved documents with bounded TTLs and SHOULD treat resolution anomalies (changed keys without corresponding binding updates) as validation failures that suspend rather than silently re-verify the binding.
• Ledger-based methods: resolution freshness depends on the consistency and finality properties of the underlying ledger, which vary by method. Deactivation lag between a controller's deactivation request and its observability through resolution contributes directly to the binding's effective revocation latency and SHOULD be considered part of the server's propagation interval when such methods are accepted.

Because re-validation behavior differs by method class, a server SHOULD document, per supported method, the events that trigger re-validation (TTL expiry, SCIM Events, explicit client request) and the failure semantics applied when resolution is unavailable (transient suspension per rather than terminal revocation).

Privacy Considerations DID Core warns that globally unambiguous identifiers create correlation risk and recommends pairwise DIDs where correlation is not desired. DID Core also warns that even pairwise DIDs can be re-correlated if DID documents reuse identical verification methods or correlating service endpoints. VC Data Model 2.0 separately warns about identifier-based, signature-based, and metadata-based correlation and recommends selective disclosure or unlinkable disclosure when strong anti-correlation properties are needed . Accordingly, an implementation conforming to this specification SHOULD prefer correlationModel=pairwise unless public reuse is intentionally desired, MUST NOT require storage of full VC payloads for routine SCIM provisioning behavior, SHOULD store only references and normalized validation outcomes, SHOULD avoid exposing DID values to clients that do not need them, SHOULD support privacy-preserving credential ecosystems that use selective disclosure or unlinkable disclosure, and SHOULD ensure that pairwise bindings do not accidentally reuse correlating DID material within the same administrative domain. The credentials.holder and credentials.credentialSubjectId sub-attributes, while optional, present a specific privacy risk: both typically contain DID URIs that directly identify the subject, and storing them in a SCIM resource makes the SCIM server itself a correlation point linking subject DIDs to SCIM account identifiers. This partially defeats the anti-correlation goals of pairwise DID usage. Implementations SHOULD omit these fields unless there is a specific operational requirement for them, and SHOULD apply appropriate access controls to limit which clients can read them when they are stored. Even with pairwise DIDs and minimal storage, the SCIM service provider itself becomes a correlation point because it holds the mapping between all of a user's pairwise DIDs and their single SCIM account identifier. Access to IdentityBinding resources MUST be restricted to authorized clients, and implementations SHOULD apply data-minimization principles to SCIM query responses (e.g., using SCIM attribute projection via the attributes or excludedAttributes query parameters).

IANA Considerations This document requests registration of the following URIs in the "System for Cross-domain Identity Management (SCIM) Schema URIs" registry defined by :

• urn:ietf:params:scim:schemas:extension:didvc:2.0:User
• urn:ietf:params:scim:schemas:extension:didvc:2.0:IdentityBinding
• urn:ietf:params:scim:schemas:extension:didvc:2.0:ServiceProviderConfig

The registration templates appear in .

References Normative References World Wide Web Consortium World Wide Web Consortium Informative References

SCIM Schema URI Registration Templates

User Extension Schema URI: urn:ietf:params:scim:schemas:extension:didvc:2.0:User Schema Name: DID and VC User Extension Intended or Associated Resource Type: User Purpose: Read-only discovery of DID and VC binding state for a SCIM user. Single-value Attributes: primaryDid, bindingState. Multi-valued Attributes: bindingRefs.

IdentityBinding Schema URI: urn:ietf:params:scim:schemas:extension:didvc:2.0:IdentityBinding Schema Name: IdentityBinding Intended or Associated Resource Type: IdentityBinding Purpose: Mutable binding resource linking a SCIM User to one or more DIDs and optional credential references. Single-value Attributes: user, correlationModel, status, lastValidationAttempt, statusReason, and materialChangeMask. Multi-valued Attributes: dids and credentials.

ServiceProviderConfig Extension Schema URI: urn:ietf:params:scim:schemas:extension:didvc:2.0:ServiceProviderConfig Schema Name: DID and VC ServiceProviderConfig Extension Intended or Associated Resource Type: ServiceProviderConfig Purpose: Capability discovery for DID and VC binding support. Single-value Attributes: enabled and verificationDelegation. Multi-valued Attributes: supportedDidMethods, supportedCredentialChecks, and supportedCorrelationModels.

Examples

Example User Representation

Example IdentityBinding Representation

Example ServiceProviderConfig Representation

Discovery Examples

Example /ResourceTypes Entry for IdentityBinding The following illustrates the ResourceType entry a conforming server MUST publish at /ResourceTypes for the IdentityBinding resource.

Example /Schemas Entry for the User Extension The following illustrates the Schema entry a conforming server MUST publish at /Schemas for the User extension defined by this specification. The entry for the IdentityBinding schema and the ServiceProviderConfig extension schema follow the same pattern.

Relationship to Existing Mechanisms (Informative) Several deployed mechanisms address adjacent parts of the problem this specification targets. This appendix summarizes why each is complementary to, rather than a substitute for, the binding layer, and how a deployment composes them.

• Credential status mechanisms (W3C Bitstring Status List and similar): provide the publication channel through which a verifier learns a credential's revocation state. They do not specify when the issuer should update the status in response to provisioning events. This specification supplies that trigger: the propagation procedure of drives issuer notification from SCIM lifecycle events, and the status mechanism remains the channel through which the resulting update reaches verifiers.
• Security Event Tokens and shared-signals profiles (CAEP, RISC): propagate session- and account-level signals to subscribed relying parties. They invalidate live sessions but do not affect credentials in a holder's possession, and they leave the mapping from account events to credential-level actions unspecified. This specification defines that mapping (material change classification, ) and uses SCIM Events as one transport for the resulting signals.
• OAuth token introspection and revocation: apply to tokens issued by a specific authorization server and consumed within its trust boundary. A verifier consuming a holder-presented credential has no introspection endpoint to consult. The IdentityBinding resource provides the SCIM-side record from which an equivalent freshness signal can be derived for credentials.
• Identity governance and administration platforms: operate the approval, attestation, and recertification workflows over directory state. They are the natural clients of this specification: an IGA-driven provisioning decision can create or revoke an IdentityBinding via standard SCIM operations, gaining an auditable credential-governance record without bespoke integration to each credential issuer.

In combination: IGA and SCIM clients decide; the IdentityBinding records the decision and its lifecycle; the propagation procedure notifies issuers; status mechanisms publish the outcome; SET-based signals carry the event to subscribers. The binding layer is the governance contract that connects the other mechanisms.

Document History

Changes Since -01

• Added supportedMaterialChangePolicies, supportedPartialRevocationModes, and propagationIntervalSeconds to the ServiceProviderConfig extension (), making the capabilities introduced in -01 discoverable, and updated the propagation procedure to reference the concrete attribute.
• Added specifying propagation cascade behavior for SCIM Group operations: member removal, group deletion and deactivation, transitive expansion of nested groups, and delayed-cascade signaling for large groups.
• Added three error conditions for the attributes introduced in -01: invalid boundSourceAttributes paths, and undeclared materialChangePolicy or partialRevocationMode values.
• Added discussing the security and freshness characteristics of statically derived, web-based, and ledger-based DID method classes and their effect on re-validation behavior.
• Added , an informative appendix positioning this specification relative to credential status mechanisms, shared-signals profiles, token introspection, and IGA platforms.
• Updated the example ServiceProviderConfig representation to illustrate the new discovery attributes.

Changes Since -00 This appendix summarizes substantive changes since the -00 revision of this document.

• Added the materialChangeMask attribute to the IdentityBinding resource.
• Added the boundClaims, boundSourceAttributes, materialChangePolicy, and partialRevocationMode sub-attributes to the credentials sub-attribute of the IdentityBinding resource.
• Added defining resource-first, credential-first, and joint lifecycle interleaving patterns between SCIM resources and externally issued credentials.
• Added defining material change classification, the materialChangeMask fingerprint, the per-credential strict, role-sensitive, and advisory policies, and an example classification table.
• Added defining three partial-revocation mechanisms: claim-scoped status references, reissuance for claim subset, and claim-level revocation flag.
• Added specifying the propagation procedure from SCIM lifecycle events to credential-level status updates, including required emission of SCIM Events per and required out-of-band issuer notification.
• Added enumerating five named security properties of the protocol: binding integrity, revocation soundness, lifecycle consistency, freshness and replay resistance, and principal-of-record consistency.
• Promoted to a normative reference.
• Updated the example IdentityBinding representation in to illustrate the new attributes.

Acknowledgments The author thanks contributors and reviewers whose feedback will be acknowledged in future revisions of this document.