commerce-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/