identity-canon/research/identity-provisioning/scim-rfc7643-rfc7644.md

SCIM RFC 7643 and RFC 7644

Source Type

Standard. RFC 7643 defines the SCIM 2.0 core schema; RFC 7644 defines the SCIM 2.0 protocol for provisioning.

Domain

Identity provisioning and directory synchronization.

Why This Source Matters

SCIM 2.0: RFC 7643 schema and RFC 7644 protocol.

SCIM is the dominant platform-neutral provisioning baseline. It defines resource types, attribute schemas, and CRUD/search operations for users and groups without prescribing authentication or authorization semantics.

Key Concepts

• Resource: a provisionable object with a schemas array, id, meta, and typed attributes.
• User resource: a person-oriented identity record with userName, name, emails, phoneNumbers, addresses, groups, roles, and active lifecycle state.
• Group resource: a named collection with displayName, members, and optional type (direct or indirect membership).
• Enterprise User extension (RFC 7643 §4.3): adds employeeNumber, costCenter, organization, division, department, and manager for workforce semantics.
• Service Provider Config: exposes supported features, authentication schemes, and bulk limits.
• Meta block: resourceType, created, lastModified, version, location — lifecycle and versioning metadata on every resource.
• Operations: Create, Read, Update, Delete, Search (POST /Users/.search), and Bulk (RFC 7644 §3.7).
• PatchOp: partial updates via add, remove, replace on paths.
• ExternalId: cross-system correlation identifier supplied by the client.

Relevant Terminology

Term	Source meaning
User	A provisionable identity record; not necessarily a login account in the consuming system.
Group	A named collection of members; may represent authorization, organizational, or mailing-list grouping.
userName	Unique identifier within the service provider's namespace; often used as login handle.
externalId	Client-supplied correlation key for linking to an upstream system of record.
active	Boolean lifecycle flag; inactive users retain the record but should lose access.
member	Reference (value, display, $ref) to a User or Group in a Group's membership list.
organization (extension)	Free-text employer or org name on a user; not a structured org resource.
manager	Reference to another User who manages this user.
roles	Application-specific role strings on the User resource; not RBAC policy.
Service Provider	The system receiving provisioned resources.
Client	The system sending provisioning requests.

Modeling Assumptions

• A User is the primary provisionable identity record; there is no separate Account or Person resource type in core SCIM.
• Groups absorb membership semantics; there is no first-class relationship tuple beyond group membership references.
• Organization structure is flattened into user attributes (department, division, organization) rather than modeled as org entities.
• Lifecycle is binary (active true/false) with soft-disable semantics; deletion is a separate operation.
• Uniqueness is scoped to the service provider; userName must be unique within the SP namespace.
• Authorization is out of scope; roles and group membership are hints that downstream systems may map to policies.
• Multi-tenancy is not defined; tenant isolation is an implementation concern of the service provider.

Identity-Canon Implications

• SCIM User maps to Identity Record (and often Account when the SP uses it for login), not to Natural Person.
• SCIM Group maps to Group collective actor with Membership Relationship edges to member records.
• userName and externalId are Identifiers within the SP Scope.
• active maps to Lifecycle State on the Identity Record.
• Enterprise extension manager suggests a Representation or reporting relationship, but SCIM does not type it beyond a User reference.
• organization, department, division are attribute-level hints, not Organization actors; canon should not treat them as structured org graphs.
• SCIM reinforces P2 (person ≠ account) and P5 (membership explicit) but lacks actor-layer primitives.

Terminology Conflicts

• User: SCIM User is a record, not a human being. Conflicts with application "user" meaning login session holder.
• Group: SCIM Group may mean LDAP security group, mailing list, or org unit depending on deployment; conflicts with social Community.
• Role: SCIM roles are opaque strings; conflicts with Cedar/OpenFGA relationship-based roles and IAM permission bundles.
• Organization: SCIM extension organization is a string attribute; conflicts with Organization collective actor in IAM products.
• Active: boolean disable vs. full lifecycle states (suspended, archived) used in enterprise directories.

Candidate Canonical Mappings

SCIM concept	Candidate canonical concept
User resource	Identity Record (+ Account when login-enabled)
Group resource	Group
member reference	Membership Relationship
userName	Identifier
externalId	Identifier (cross-system correlation)
active	Lifecycle State
manager (extension)	Representation Relationship (weakly typed)
organization/department/division	Affiliation hints; not Organization actors
roles (extension)	Role labels; authorization projection input
meta.created/lastModified	Evidence timestamps for record provenance
Service Provider namespace	Scope

Open Questions

• Should SCIM externalId be modeled as a dedicated Identifier Binding or a generic Identifier with source metadata?
• How should indirect group membership (type: indirect) map to canon membership vs. inherited authorization projection?
• Does the Enterprise User manager reference warrant a canonical Reporting Relationship distinct from Representation?
• Should a SCIM-only deployment without login map User exclusively to Identity Record, skipping Account?

References

• RFC 7643: SCIM 2.0 Core Schema — https://datatracker.ietf.org/doc/html/rfc7643
• RFC 7644: SCIM 2.0 Protocol — https://datatracker.ietf.org/doc/html/rfc7644
• IETF SCIM working group overview — https://datatracker.ietf.org/wg/scim/about/