Internet Engineering Task Force S. Kushwaha
Internet-Draft Oracle Corporation
Intended status: Standards Track 24 August 2026
Expires: 25 February 2027
SCIM DID/VC Binding Extension
draft-kushwaha-scim-didvc-binding-01
Abstract
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 [RFC9967].
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/.
Kushwaha Expires 25 February 2027 [Page 1]
Internet-Draft SCIM DID/VC Binding August 2026
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 25 February 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 5
1.4. Design Goals . . . . . . . . . . . . . . . . . . . . . . 5
2. Architecture Overview . . . . . . . . . . . . . . . . . . . . 5
3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. User Extension Schema . . . . . . . . . . . . . . . . . . 6
3.1.1. Derivation of primaryDid . . . . . . . . . . . . . . 8
3.2. IdentityBinding Resource . . . . . . . . . . . . . . . . 9
3.3. Relationship Between correlationModel and
dids.relationship . . . . . . . . . . . . . . . . . . . . 14
3.4. ServiceProviderConfig Extension . . . . . . . . . . . . . 15
4. Processing Model . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Creation . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2. Validation . . . . . . . . . . . . . . . . . . . . . . . 17
4.3. Lifecycle Interleaving . . . . . . . . . . . . . . . . . 18
4.3.1. Resource-First . . . . . . . . . . . . . . . . . . . 18
4.3.2. Credential-First . . . . . . . . . . . . . . . . . . 18
4.3.3. Joint . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4. State Transitions . . . . . . . . . . . . . . . . . . . . 19
4.4.1. Re-evaluation of Rejected Bindings . . . . . . . . . 21
4.5. Material Change Classification . . . . . . . . . . . . . 21
4.5.1. materialChangeMask Computation . . . . . . . . . . . 21
4.5.2. Per-Credential Policies . . . . . . . . . . . . . . . 21
Kushwaha Expires 25 February 2027 [Page 2]
Internet-Draft SCIM DID/VC Binding August 2026
4.5.3. Classification Examples . . . . . . . . . . . . . . . 22
4.6. Partial Revocation . . . . . . . . . . . . . . . . . . . 23
4.6.1. Claim-Scoped Status References . . . . . . . . . . . 23
4.6.2. Reissuance for Claim Subset . . . . . . . . . . . . . 24
4.6.3. Claim-Level Revocation Flag . . . . . . . . . . . . . 24
4.6.4. Default Behavior . . . . . . . . . . . . . . . . . . 24
4.7. Revocation Propagation . . . . . . . . . . . . . . . . . 24
4.7.1. Group Change Cascade . . . . . . . . . . . . . . . . 25
4.8. Deletion . . . . . . . . . . . . . . . . . . . . . . . . 26
5. Query, Filtering, PATCH, and Pagination . . . . . . . . . . . 27
5.1. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2. PATCH . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3. Pagination . . . . . . . . . . . . . . . . . . . . . . . 29
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 29
7. Discovery and Deployment . . . . . . . . . . . . . . . . . . 31
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
8.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 31
8.2. Security Properties . . . . . . . . . . . . . . . . . . . 31
8.2.1. Binding Integrity . . . . . . . . . . . . . . . . . . 31
8.2.2. Revocation Soundness . . . . . . . . . . . . . . . . 32
8.2.3. Lifecycle Consistency . . . . . . . . . . . . . . . . 32
8.2.4. Freshness and Replay Resistance . . . . . . . . . . . 32
8.2.5. Principal-of-Record Consistency . . . . . . . . . . . 32
8.3. Required Mitigations . . . . . . . . . . . . . . . . . . 33
8.4. DID Control Proof Delivery . . . . . . . . . . . . . . . 33
8.5. Replay Attack Mitigation . . . . . . . . . . . . . . . . 33
8.6. Delegated Verifier Trust Scope . . . . . . . . . . . . . 33
8.7. DID Method Considerations . . . . . . . . . . . . . . . . 34
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 35
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
11.1. Normative References . . . . . . . . . . . . . . . . . . 36
11.2. Informative References . . . . . . . . . . . . . . . . . 37
Appendix A. SCIM Schema URI Registration Templates . . . . . . . 37
A.1. User Extension . . . . . . . . . . . . . . . . . . . . . 37
A.2. IdentityBinding . . . . . . . . . . . . . . . . . . . . . 37
A.3. ServiceProviderConfig Extension . . . . . . . . . . . . . 38
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 38
B.1. Example User Representation . . . . . . . . . . . . . . . 38
B.2. Example IdentityBinding Representation . . . . . . . . . 39
B.3. Example ServiceProviderConfig Representation . . . . . . 40
Appendix C. Discovery Examples . . . . . . . . . . . . . . . . . 40
C.1. Example /ResourceTypes Entry for IdentityBinding . . . . 40
C.2. Example /Schemas Entry for the User Extension . . . . . . 41
Relationship to Existing Mechanisms (Informative) . . . . . . . . 42
Document History . . . . . . . . . . . . . . . . . . . . . . . . 43
Changes Since -01 . . . . . . . . . . . . . . . . . . . . . . . 43
Changes Since -00 . . . . . . . . . . . . . . . . . . . . . . . 44
Kushwaha Expires 25 February 2027 [Page 3]
Internet-Draft SCIM DID/VC Binding August 2026
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 45
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction
SCIM provides a standard protocol and schema model for provisioning
and managing identities across administrative domains [RFC7643]
[RFC7644]. 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 [RFC7643].
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 [DID-CORE] [VC-DATA-MODEL-2.0].
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.
1.1. 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 [RFC2119]
[RFC8174] when, and only when, they appear in all capitals, as shown
here.
SCIM resource representations in this document are encoded in JSON
[RFC8259] as required by [RFC7643].
1.2. 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.
Kushwaha Expires 25 February 2027 [Page 4]
Internet-Draft SCIM DID/VC Binding August 2026
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.
1.3. 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.
1.4. 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.
2. 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.
Kushwaha Expires 25 February 2027 [Page 5]
Internet-Draft SCIM DID/VC Binding August 2026
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.
3. 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 Section 3.1), which does not appear in any resource-
level status.
3.1. 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.
Kushwaha Expires 25 February 2027 [Page 6]
Internet-Draft SCIM DID/VC Binding August 2026
+============+=======+===+===+==========+==========+===============+
|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 |
| | | | | | |Section 3.1.1. |
+------------+-------+---+---+----------+----------+---------------+
|bindingState|string |no |yes|readOnly |none, |Aggregate state|
| | | | | |pending, |derived from |
| | | | | |active, |active bindings|
| | | | | |suspended,|for the user. |
| | | | | |revoked, |The value none |
| | | | | |rejected |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. |
+------------+-------+---+---+----------+----------+---------------+
Table 1: User Extension Attributes
Kushwaha Expires 25 February 2027 [Page 7]
Internet-Draft SCIM DID/VC Binding August 2026
+=============+=========+===+==========+==========+=================+
|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, | Current |
| | | | |active, | lifecycle state |
| | | | |suspended,| of the |
| | | | |revoked, | referenced |
| | | | |rejected | binding. |
+-------------+---------+---+----------+----------+-----------------+
Table 2: bindingRefs Sub-Attributes
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.
3.1.1. 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.
Kushwaha Expires 25 February 2027 [Page 8]
Internet-Draft SCIM DID/VC Binding August 2026
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.
3.2. 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 [RFC7643], 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.
+=====================+========+===+===+==========+==========+==================+
|Attribute |Type |MV |Req|Mutability|Values |Description |
+=====================+========+===+===+==========+==========+==================+
|user |complex |no |yes|immutable |- |Reference to the |
| | | | | | |bound SCIM User. |
+---------------------+--------+---+---+----------+----------+------------------+
|correlationModel |string |no |yes|immutable |pairwise, |Privacy |
| | | | | |shared, |expectation for |
| | | | | |public |DID reuse across |
| | | | | | |relying parties. |
| | | | | | |See Section 3.3 |
| | | | | | |for the |
| | | | | | |relationship |
Kushwaha Expires 25 February 2027 [Page 9]
Internet-Draft SCIM DID/VC Binding August 2026
| | | | | | |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, |Binding lifecycle |
| | | | | |active, |state. |
| | | | | |suspended,| |
| | | | | |revoked, | |
| | | | | |rejected | |
+---------------------+--------+---+---+----------+----------+------------------+
|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 |
Kushwaha Expires 25 February 2027 [Page 10]
Internet-Draft SCIM DID/VC Binding August 2026
| | | | | | |changes per |
| | | | | | |Section 4.5. |
| | | | | | |Servers MUST NOT |
| | | | | | |expose the |
| | | | | | |algorithm used to |
| | | | | | |compute the |
| | | | | | |fingerprint to |
| | | | | | |clients; the value|
| | | | | | |is intended for |
| | | | | | |comparison only. |
+---------------------+--------+---+---+----------+----------+------------------+
Table 3: IdentityBinding 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. |
+---------------+-----------+-----+------------+-----------------+
Table 4: user Sub-Attributes
+==================+=======+===+==========+===============+=================+
|Sub-Attribute |Type |Req|Mutability|Values |Description |
+==================+=======+===+==========+===============+=================+
|value |string |yes|readWrite |- |DID URI. |
+------------------+-------+---+----------+---------------+-----------------+
|relationship |string |yes|readWrite |primary, |Role of the DID |
| | | | |pairwise, |in the binding. |
| | | | |delegated, |See Section 3.3 |
| | | | |recovery |for the |
| | | | | |distinction |
| | | | | |between this |
| | | | | |field and the |
| | | | | |binding-level |
| | | | | |correlationModel.|
| | | | | |The value |
| | | | | |recovery |
| | | | | |designates a DID |
| | | | | |that is |
Kushwaha Expires 25 February 2027 [Page 11]
Internet-Draft SCIM DID/VC Binding August 2026
| | | | | |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,|DID proof purpose|
| | | | |assertionMethod|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, |Per-DID |
| | | | |verified, |validation |
| | | | |deactivated |status. The |
| | | | | |value deactivated|
| | | | | |aligns with the |
| | | | | |DID Core |
| | | | | |specification's |
| | | | | |terminal state |
| | | | | |for a DID |
| | | | | |document |
| | | | | |[DID-CORE]. |
+------------------+-------+---+----------+---------------+-----------------+
Table 5: dids Sub-Attributes
Kushwaha Expires 25 February 2027 [Page 12]
Internet-Draft SCIM DID/VC Binding August 2026
+=====================+=========+===+==========+===========+======================================================================+
|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 Section 9). |
+---------------------+---------+---+----------+-----------+----------------------------------------------------------------------+
|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 Section 9). |
+---------------------+---------+---+----------+-----------+----------------------------------------------------------------------+
|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, |Server-normalized outcome for the credential reference. |
| | | | |active, | |
| | | | |revoked, | |
| | | | |expired, | |
| | | | |unknown | |
+---------------------+---------+---+----------+-----------+----------------------------------------------------------------------+
|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 Section 4.5. |
+---------------------+---------+---+----------+-----------+----------------------------------------------------------------------+
|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, |Policy that determines server behavior when a material change to a |
| | | | |role- |source SCIM attribute is detected for this credential. Defaults to |
| | | | |sensitive, |role-sensitive. See Section 4.5. |
| | | | |advisory | |
+---------------------+---------+---+----------+-----------+----------------------------------------------------------------------+
|partialRevocationMode|string |no |readWrite |none, |How the credential supports partial revocation when only a subset of |
| | | | |claim- |bound claims is affected by a material change. Defaults to none |
| | | | |scoped, |(whole-credential revocation only). See Section 4.6. |
| | | | |reissuance,| |
Kushwaha Expires 25 February 2027 [Page 13]
Internet-Draft SCIM DID/VC Binding August 2026
| | | | |claim-flag | |
+---------------------+---------+---+----------+-----------+----------------------------------------------------------------------+
Table 6: credentials Sub-Attributes
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 Section 3.1.1, 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.
3.3. 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.
Kushwaha Expires 25 February 2027 [Page 14]
Internet-Draft SCIM DID/VC Binding August 2026
3.4. 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.
+===============================+=======+===+===+==========+=============+=====================+
|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, |Whether verification |
| | | | | |external, |is performed by the |
| | | | | |mixed |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, |VC checks the server |
| | | | | |schema, |is capable of |
Kushwaha Expires 25 February 2027 [Page 15]
Internet-Draft SCIM DID/VC Binding August 2026
| | | | | |validity, |evaluating. |
| | | | | |holderBinding| |
+-------------------------------+-------+---+---+----------+-------------+---------------------+
|supportedCorrelationModels |string |yes|yes|readOnly |pairwise, |Correlation models |
| | | | | |shared, |supported by the |
| | | | | |public |server. |
+-------------------------------+-------+---+---+----------+-------------+---------------------+
|supportedMaterialChangePolicies|string |yes|no |readOnly |strict, role-|Material change |
| | | | | |sensitive, |policies |
| | | | | |advisory |(Section 4.5.2) 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- |Partial revocation |
| | | | | |scoped, |modes (Section 4.6) |
| | | | | |reissuance, |the server supports. |
| | | | | |claim-flag |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 Section 4.7. This|
| | | | | | |value bounds the |
| | | | | | |lifecycle-consistency|
| | | | | | |property of |
| | | | | | |Section 8.2.3. |
Kushwaha Expires 25 February 2027 [Page 16]
Internet-Draft SCIM DID/VC Binding August 2026
| | | | | | |Servers SHOULD |
| | | | | | |publish this value; |
| | | | | | |clients and |
| | | | | | |downstream relying |
| | | | | | |parties MAY use it |
| | | | | | |for risk assessment. |
+-------------------------------+-------+---+---+----------+-------------+---------------------+
Table 7: ServiceProviderConfig Extension Attributes
4. Processing Model
4.1. 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.
4.2. 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 [DID-CORE]. 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.
Kushwaha Expires 25 February 2027 [Page 17]
Internet-Draft SCIM DID/VC Binding August 2026
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
[VC-DATA-MODEL-2.0].
This specification does not define proof formats or verifier APIs.
4.3. 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.
4.3.1. 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
Section 4.2.
4.3.2. 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 Section 4.2 and MUST compute the
materialChangeMask attribute as defined in Section 4.5 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.
Kushwaha Expires 25 February 2027 [Page 18]
Internet-Draft SCIM DID/VC Binding August 2026
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.
4.3.3. 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.
4.4. State Transitions
The server MUST implement the following binding-state semantics:
Kushwaha Expires 25 February 2027 [Page 19]
Internet-Draft SCIM DID/VC Binding August 2026
+===========+===========+======================================+
| 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 Section 4.4.1). |
+-----------+-----------+--------------------------------------+
Table 8: Binding State Transitions
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.
Kushwaha Expires 25 February 2027 [Page 20]
Internet-Draft SCIM DID/VC Binding August 2026
4.4.1. 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.
4.5. 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.
4.5.1. 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.
4.5.2. 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:
Kushwaha Expires 25 February 2027 [Page 21]
Internet-Draft SCIM DID/VC Binding August 2026
* 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 Section 4.6),
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 Section 4.7) 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.
4.5.3. 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.
Kushwaha Expires 25 February 2027 [Page 22]
Internet-Draft SCIM DID/VC Binding August 2026
+============================+========================+
| Attribute change | Default classification |
+============================+========================+
| active: true to false | Material (terminal) |
+----------------------------+------------------------+
| groups: removal of a group | Material |
| claimed in credential | |
+----------------------------+------------------------+
| Enterprise department: | Material if department |
| change | is in bound claims |
+----------------------------+------------------------+
| Enterprise manager: change | Advisory by default |
+----------------------------+------------------------+
| phoneNumbers: update | Not material |
+----------------------------+------------------------+
| emails: primary address | Advisory by default |
| change | |
+----------------------------+------------------------+
| name.formatted: spelling | Not material |
| correction | |
+----------------------------+------------------------+
| addresses: relocation | Not material |
+----------------------------+------------------------+
Table 9: Example Classification of SCIM Attribute
Changes
4.6. 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.
4.6.1. 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 Section 4.7) 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
Kushwaha Expires 25 February 2027 [Page 23]
Internet-Draft SCIM DID/VC Binding August 2026
specification, the SD-JWT family of specifications, or other
published profiles that define per-claim status semantics for the
credential format in use.
4.6.2. 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 Section 4.7 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.
4.6.3. 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.
4.6.4. 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.
4.7. 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:
Kushwaha Expires 25 February 2027 [Page 24]
Internet-Draft SCIM DID/VC Binding August 2026
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
Section 4.5.1 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 Section 4.6, 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 [RFC9967] 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 (Section 3.4). The
propagation interval bounds the lifecycle-consistency property
defined in Section 8.2.
4.7.1. 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:
Kushwaha Expires 25 February 2027 [Page 25]
Internet-Draft SCIM DID/VC Binding August 2026
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.
4.8. 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.
Kushwaha Expires 25 February 2027 [Page 26]
Internet-Draft SCIM DID/VC Binding August 2026
5. Query, Filtering, PATCH, and Pagination
5.1. Filtering
SCIM filter expressions and fully qualified attribute notation are
defined by [RFC7644]. 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 [RFC7643]
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.
GET /IdentityBindings?filter=dids.value eq "did:example:123"
Figure 1: Example Filter by DID (values shown decoded; apply
percent-encoding in actual requests)
Kushwaha Expires 25 February 2027 [Page 27]
Internet-Draft SCIM DID/VC Binding August 2026
GET /IdentityBindings?filter=status eq "active" and credentials.issuer eq "did:example:issuer:acme"
Figure 2: Example Combined Filter
GET /IdentityBindings?filter=credentials.types co "EmploymentCredential"
Figure 3: Example Filter Using co Operator on Multi-valued types
GET /Users?filter=urn:ietf:params:scim:schemas:extension:didvc:2.0:User:primaryDid eq "did:example:123"
Figure 4: Example User Filter by primaryDid
5.2. PATCH
A service provider implementing IdentityBinding MUST support SCIM
PATCH as defined by [RFC7644]. PATCH request bodies MUST conform to
the PatchOp message format defined in Section 3.5.2 of [RFC7644],
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).
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{
"op": "replace",
"path": "dids[value eq \"did:example:123\"].primary",
"value": true
}
]
}
Figure 5: Example PATCH to Set a Primary DID Flag
Kushwaha Expires 25 February 2027 [Page 28]
Internet-Draft SCIM DID/VC Binding August 2026
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{
"op": "replace",
"path": "credentials[issuer eq \"did:example:issuer:acme\"].schemaRef",
"value": "https://issuer.example/schemas/employment-v1"
}
]
}
Figure 6: Example PATCH to Update a Credential Schema Reference
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{
"op": "replace",
"path": "dids[value eq \"did:example:old\"].verificationMethod",
"value": "did:example:abc123#key-2"
}
]
}
Figure 7: Example PATCH to Correct a DID and Trigger Re-
evaluation of a Rejected Binding
5.3. Pagination
List operations for IdentityBinding resources MUST support SCIM list
pagination as defined by [RFC7644]. A service provider MAY
additionally support cursor-based pagination as defined by [RFC9865].
6. Error Handling
A conforming server MUST return SCIM error responses as defined in
Section 3.12 of [RFC7644] for all error conditions. The following
table enumerates error conditions specific to this specification.
+====================================+========+==============+
| Condition | HTTP | SCIM |
| | Status | scimType |
+====================================+========+==============+
| user.value references a non- | 400 | invalidValue |
| existent User | | |
+------------------------------------+--------+--------------+
| Request includes more than one | 400 | invalidValue |
| dids entry with primary=true | | |
Kushwaha Expires 25 February 2027 [Page 29]
Internet-Draft SCIM DID/VC Binding August 2026
+------------------------------------+--------+--------------+
| A dids entry has primary=true but | 400 | invalidValue |
| relationship is not primary | | |
+------------------------------------+--------+--------------+
| Creation of a pairwise binding | 409 | uniqueness |
| with a DID already used in another | | |
| active pairwise binding within the | | |
| same administrative scope | | |
+------------------------------------+--------+--------------+
| PATCH attempts to modify an | 400 | mutability |
| immutable attribute (user, | | |
| correlationModel) | | |
+------------------------------------+--------+--------------+
| PATCH attempts to modify a | 400 | mutability |
| readOnly attribute (status, | | |
| lastValidationAttempt) | | |
+------------------------------------+--------+--------------+
| Multiple active bindings with | 400 | invalidValue |
| primary=true would result from the | | |
| operation | | |
+------------------------------------+--------+--------------+
| DELETE attempted on an active | 409 | - |
| binding when the server requires | | |
| non-active status first | | |
+------------------------------------+--------+--------------+
| A credentials entry declares a | 400 | invalidPath |
| boundSourceAttributes path that is | | |
| not a valid SCIM attribute path on | | |
| the bound User's schemas | | |
+------------------------------------+--------+--------------+
| A credentials entry declares a | 400 | invalidValue |
| materialChangePolicy value not | | |
| advertised in the server's | | |
| supportedMaterialChangePolicies | | |
+------------------------------------+--------+--------------+
| A credentials entry declares a | 400 | invalidValue |
| partialRevocationMode value not | | |
| advertised in the server's | | |
| supportedPartialRevocationModes | | |
+------------------------------------+--------+--------------+
Table 10: Binding-Specific Error Conditions
Kushwaha Expires 25 February 2027 [Page 30]
Internet-Draft SCIM DID/VC Binding August 2026
7. 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 Appendix C.
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.
8. Security Considerations
8.1. 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.
8.2. 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.
8.2.1. 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.
Kushwaha Expires 25 February 2027 [Page 31]
Internet-Draft SCIM DID/VC Binding August 2026
8.2.2. Revocation Soundness
After the propagation procedure of Section 4.7 completes for a
binding that has transitioned to revoked, no verifier following the
credential-status verification procedure of [VC-DATA-MODEL-2.0]
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.
8.2.3. 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 Section 4.7).
8.2.4. 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 Section 8.4) and on credential validation
results that bind to a specific validation timestamp (see
Section 8.5).
8.2.5. 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 Section 3.2.
Kushwaha Expires 25 February 2027 [Page 32]
Internet-Draft SCIM DID/VC Binding August 2026
8.3. 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.
8.4. 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.
8.5. 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.
8.6. 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
Kushwaha Expires 25 February 2027 [Page 33]
Internet-Draft SCIM DID/VC Binding August 2026
types), MUST authenticate the verifier at the transport layer, and
SHOULD audit verifier responses for anomalies such as bulk activation
of previously-pending bindings.
8.7. 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 Section 4.4 rather than terminal revocation).
Kushwaha Expires 25 February 2027 [Page 34]
Internet-Draft SCIM DID/VC Binding August 2026
9. 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
[DID-CORE] [VC-DATA-MODEL-2.0].
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).
10. IANA Considerations
This document requests registration of the following URIs in the
"System for Cross-domain Identity Management (SCIM) Schema URIs"
registry defined by [RFC7643]:
Kushwaha Expires 25 February 2027 [Page 35]
Internet-Draft SCIM DID/VC Binding August 2026
* 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 Appendix A.
11. References
11.1. Normative References
[DID-CORE] World Wide Web Consortium, "Decentralized Identifiers
(DIDs) v1.0", W3C Recommendation did-1.0, 19 July 2022,
.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
.
[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, September
2015, .
[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,
September 2015, .
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, .
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
.
[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, May 2026,
.
Kushwaha Expires 25 February 2027 [Page 36]
Internet-Draft SCIM DID/VC Binding August 2026
[VC-DATA-MODEL-2.0]
World Wide Web Consortium, "Verifiable Credentials Data
Model v2.0", W3C Recommendation vc-data-model-2.0, 15 May
2025, .
11.2. Informative References
[RFC9865] Peterson, M., Ed., Zollner, D., and A. Sehgal, "Cursor-
Based Pagination of System of Cross-domain Identity
Management (SCIM) Resources", RFC 9865,
DOI 10.17487/RFC9865, October 2025,
.
Appendix A. SCIM Schema URI Registration Templates
A.1. 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.
A.2. 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.
Kushwaha Expires 25 February 2027 [Page 37]
Internet-Draft SCIM DID/VC Binding August 2026
A.3. 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.
Appendix B. Examples
B.1. Example User Representation
{
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:User",
"urn:ietf:params:scim:schemas:extension:didvc:2.0:User"
],
"id": "2819c223-7f76-453a-919d-413861904646",
"userName": "alice@example.com",
"name": {
"givenName": "Alice",
"familyName": "Ng"
},
"urn:ietf:params:scim:schemas:extension:didvc:2.0:User": {
"primaryDid": "did:example:abc123",
"bindingState": "active",
"bindingRefs": [
{
"value": "c3a801b0-0b28-4c9c-a7fb-9964a6d916c1",
"$ref": "/IdentityBindings/c3a801b0-0b28-4c9c-a7fb-9964a6d916c1",
"display": "Primary workforce binding",
"primary": true,
"status": "active"
}
]
}
}
Figure 8
Kushwaha Expires 25 February 2027 [Page 38]
Internet-Draft SCIM DID/VC Binding August 2026
B.2. Example IdentityBinding Representation
{
"schemas": [
"urn:ietf:params:scim:schemas:extension:didvc:2.0:IdentityBinding"
],
"id": "c3a801b0-0b28-4c9c-a7fb-9964a6d916c1",
"meta": {
"resourceType": "IdentityBinding",
"created": "2026-04-20T09:00:00Z",
"lastModified": "2026-04-21T14:37:00Z",
"location": "/IdentityBindings/c3a801b0-0b28-4c9c-a7fb-9964a6d916c1",
"version": "W/\"3694e05afa83191e\""
},
"user": {
"value": "2819c223-7f76-453a-919d-413861904646",
"$ref": "/Users/2819c223-7f76-453a-919d-413861904646",
"display": "Alice Ng"
},
"correlationModel": "pairwise",
"dids": [
{
"value": "did:example:abc123",
"relationship": "primary",
"verificationMethod": "did:example:abc123#key-1",
"proofPurpose": "authentication",
"controller": "did:example:abc123",
"primary": true,
"status": "verified"
}
],
"credentials": [
{
"credentialId": "urn:uuid:4dd2dc49-9c0f-43f8-b96e-4f4d1f578a2d",
"types": ["VerifiableCredential", "EmploymentCredential"],
"issuer": "did:example:issuer:acme",
"statusRef": "https://issuer.example/status/94567",
"schemaRef": "https://issuer.example/schema/employment-v1",
"validFrom": "2026-04-01T00:00:00Z",
"validUntil": "2027-04-01T00:00:00Z",
"status": "active",
"boundClaims": ["employed", "role", "department"],
"boundSourceAttributes": [
"active",
"groups.value",
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department"
],
"materialChangePolicy": "role-sensitive",
Kushwaha Expires 25 February 2027 [Page 39]
Internet-Draft SCIM DID/VC Binding August 2026
"partialRevocationMode": "claim-scoped"
}
],
"status": "active",
"lastValidationAttempt": "2026-04-21T14:37:00Z",
"statusReason": "DID control and required credential checks succeeded",
"materialChangeMask": "sha256:9c8b4a..."
}
Figure 9
B.3. Example ServiceProviderConfig Representation
{
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig",
"urn:ietf:params:scim:schemas:extension:didvc:2.0:ServiceProviderConfig"
],
"patch": { "supported": true },
"filter": { "supported": true, "maxResults": 200 },
"sort": { "supported": false },
"etag": { "supported": true },
"urn:ietf:params:scim:schemas:extension:didvc:2.0:ServiceProviderConfig": {
"enabled": true,
"verificationDelegation": "mixed",
"supportedDidMethods": ["did:web", "did:key", "did:example"],
"supportedCredentialChecks": ["status", "schema", "validity", "holderBinding"],
"supportedCorrelationModels": ["pairwise", "shared", "public"],
"supportedMaterialChangePolicies": ["strict", "role-sensitive", "advisory"],
"supportedPartialRevocationModes": ["none", "claim-scoped", "reissuance"],
"propagationIntervalSeconds": 300
}
}
Figure 10
Appendix C. Discovery Examples
C.1. Example /ResourceTypes Entry for IdentityBinding
The following illustrates the ResourceType entry a conforming server
MUST publish at /ResourceTypes for the IdentityBinding resource.
Kushwaha Expires 25 February 2027 [Page 40]
Internet-Draft SCIM DID/VC Binding August 2026
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"],
"id": "IdentityBinding",
"name": "IdentityBinding",
"endpoint": "/IdentityBindings",
"description": "Auditable linkage between a SCIM User and one or more DIDs and credential references.",
"schema": "urn:ietf:params:scim:schemas:extension:didvc:2.0:IdentityBinding",
"meta": {
"resourceType": "ResourceType",
"location": "/ResourceTypes/IdentityBinding"
}
}
Figure 11
C.2. 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.
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:Schema"],
"id": "urn:ietf:params:scim:schemas:extension:didvc:2.0:User",
"name": "DID and VC User Extension",
"description": "Read-only discovery of DID and VC binding state for a SCIM user.",
"attributes": [
{
"name": "primaryDid",
"type": "string",
"multiValued": false,
"required": false,
"mutability": "readOnly",
"returned": "default"
},
{
"name": "bindingState",
"type": "string",
"multiValued": false,
"required": true,
"canonicalValues": ["none", "pending", "active", "suspended", "revoked", "rejected"],
"mutability": "readOnly",
"returned": "default"
},
{
"name": "bindingRefs",
"type": "complex",
Kushwaha Expires 25 February 2027 [Page 41]
Internet-Draft SCIM DID/VC Binding August 2026
"multiValued": true,
"required": false,
"mutability": "readOnly",
"returned": "default",
"subAttributes": [
{ "name": "value", "type": "string", "required": true, "mutability": "readOnly" },
{ "name": "$ref", "type": "reference", "required": true, "mutability": "readOnly" },
{ "name": "display", "type": "string", "required": false, "mutability": "readOnly" },
{ "name": "primary", "type": "boolean", "required": false, "mutability": "readOnly" },
{
"name": "status",
"type": "string",
"required": true,
"canonicalValues": ["pending", "active", "suspended", "revoked", "rejected"],
"mutability": "readOnly"
}
]
}
],
"meta": {
"resourceType": "Schema",
"location": "/Schemas/urn:ietf:params:scim:schemas:extension:didvc:2.0:User"
}
}
Figure 12
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 Section 4.7 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
Kushwaha Expires 25 February 2027 [Page 42]
Internet-Draft SCIM DID/VC Binding August 2026
specification defines that mapping (material change
classification, Section 4.5) and uses SCIM Events [RFC9967] 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 (Section 3.4), making the
capabilities introduced in -01 discoverable, and updated the
propagation procedure to reference the concrete attribute.
* Added Section 4.7.1 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 Section 8.7 discussing the security and freshness
characteristics of statically derived, web-based, and ledger-based
DID method classes and their effect on re-validation behavior.
Kushwaha Expires 25 February 2027 [Page 43]
Internet-Draft SCIM DID/VC Binding August 2026
* Added Appendix "Relationship to Existing Mechanisms
(Informative)", 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 Section 4.3 defining resource-first, credential-first, and
joint lifecycle interleaving patterns between SCIM resources and
externally issued credentials.
* Added Section 4.5 defining material change classification, the
materialChangeMask fingerprint, the per-credential strict, role-
sensitive, and advisory policies, and an example classification
table.
* Added Section 4.6 defining three partial-revocation mechanisms:
claim-scoped status references, reissuance for claim subset, and
claim-level revocation flag.
* Added Section 4.7 specifying the propagation procedure from SCIM
lifecycle events to credential-level status updates, including
required emission of SCIM Events per [RFC9967] and required out-
of-band issuer notification.
* Added Section 8.2 enumerating five named security properties of
the protocol: binding integrity, revocation soundness, lifecycle
consistency, freshness and replay resistance, and principal-of-
record consistency.
* Promoted [RFC9967] to a normative reference.
* Updated the example IdentityBinding representation in Appendix B.2
to illustrate the new attributes.
Kushwaha Expires 25 February 2027 [Page 44]
Internet-Draft SCIM DID/VC Binding August 2026
Acknowledgments
The author thanks contributors and reviewers whose feedback will be
acknowledged in future revisions of this document.
Author's Address
Saurabh Kushwaha
Oracle Corporation
Pleasanton, CA
United States of America
Email: saurabh.kushwaha@oracle.com
Kushwaha Expires 25 February 2027 [Page 45]