RFC 7643

Everything in SCIM is an attribute on a resource, and Section 2 defines what an attribute is allowed to be. Attribute names follow one grammar, ATTRNAME = ALPHA *(nameChar) withnameChar = "$" / "-" / "_" / DIGIT / ALPHA, and names are case-insensitive (Section 2.1). Seven characteristics annotate each attribute (Section 2.2); each carries a default, which matters twice: schema JSON may omit a characteristic, and the protocol's processing rules read the defaults in.

Section 2.3 fixes eight data types: string, boolean, decimal, integer, dateTime, binary, reference, and complex. Two rules do most of the work in code review. A dateTime value MUST be a validxsd:DateTime; providers that emit a bare date or a locale format are out of spec. A complex attribute MUST NOT contain nested complex sub-attributes and MUST NOT carry a uniqueness characteristic; published schema JSON violated both, and the errata below repair the JSON rather than the rule.

Multi-valued attributes share a common sub-attribute set (Section 2.4): type,value, display, $ref, and primary, the last true for at most one entry in the list. Section 2.5 closes the model with the equivalence rule: unassigned, null, and empty array mean the same thing for most attributes, which is why a PATCH that clears a value may use either form.

Section 3.1 assigns authorship of the two identifiers, and the assignment is absolute. id is the server's: case-exact, read-only, always returned, MUST NOT be specified by the client, with thebulkId prefix reserved for the protocol's temporary identifiers. externalId is the client's: optional, case-exact, read-write, and the server MUST treat it as scoped to the provisioning domain. The meta complex is the server's bookkeeping: resourceType,created, lastModified, location (which MUST equal the Content-Location header), and version (which MUST equal the ETag); clients provide values, and the server ignores them.

New resource types are defined in Section 3.2 and extensions in Section 3.3: an extension's attributes live in a JSON container keyed by the extension's URN, there is no inheritance, and the model is additive in the way LDAP auxiliary classes are. The schemas attribute on every resource MUST be a non-empty array of unique URIs matching the resource type's declared schema and schema extensions; the errata table below includes three example resources that shipped without it.

Section 4.1 defines the User. The load-bearing rules: userName is REQUIRED and unique per account; password is writeOnly and returned never, with persistence handled so the clear value is not recoverable, and erratum 8450 settled the phrasing as "hashed or encrypted";groups is read-only and its $ref values point at Group resources only. Section 4.1.2 carries the multi-valued set (emails, phoneNumbers, addresses, entitlements, roles, and the rest), with country codes constrained to ISO 3166-1 alpha-2.

Section 4.2 defines the Group around one REQUIRED attribute, displayName, plusmembers, whose type distinguishes User from Group membership and whose non-membership semantics differ accordingly. Section 4.3 defines the Enterprise User extension (employeeNumber, costCenter, organization, division,department, manager) in its URN-keyed container.

The published examples contradicted the narrative in several of these places, which is why the errata table in Section 05 of this page sits next to the resource text: the Group schema JSON markeddisplayName "required": false under a REQUIRED description (erratum 5368); the User's groups schema listed "referenceTypes": ["User","Group"] where only"Group" is possible (erratum 8471); both the full User and the Enterprise User examples used country "USA" against the alpha-2 rule (errata 5990 and 5991); and the Enterprise manager value carried "caseExact": false while the id it references is case-exact (erratum 8472).

Two schema documents in Sections 5 and 6 turn a static schema into a self-describing service. TheServiceProviderConfig (Section 5) declares capabilities: whether PATCH, bulk (withmaxOperations), filtering (with maxResults), changePassword, sort, and ETags are supported, plus documentationUri and the authenticationSchemes list with itsprimary flag. The ResourceType schema (Section 6) binds a resource name to an endpoint and a schema URI, with schemaExtensions carrying a required flag per extension. Clients read ResourceTypes to discover endpoints rather than assuming a pluralization rule; the protocol side of that contract is on the RFC 7644 page.

Both documents needed errata repair: ResourceType name and endpoint gained uniqueness "server" and case-exact matching (erratum 8475), the Section 3.1 endpoint names were normalized to /ServiceProviderConfig and /ResourceTypes with leading slashes (erratum 8361), and three of the Section 8.7.2 example documents were missing the REQUIREDschemas attribute and meta (erratum 8417). Later RFCs extend the ServiceProviderConfig in place: RFC 9865 adds a pagination complex and RFC 9967 addssecurityEvents; both are optional, and absence means the capability is unsupported.

Section 8 teaches the schema by example, and the examples shipped defective: sixteen errata are verified against this RFC as of 2026-11-01, ten of them altering the Section 8.7 schema JSON directly. Most share one verified date, 2025-10-28, a coordinated clearing of the decks that immediately preceded the working group's revision work; the two country-code fixes were verified in February 2020, and one editorial fix in Section 7 was verified by the RFC Editor in June 2025. The corrected JSON is the reading implementations should converge on; the published JSON is what a decade of libraries copied. Both readings matter, so this site's schema explorer defaults to the corrected schema and keeps the as-published text one toggle away, with per-erratum deltas matching the table below.

The errata pages also carry reported and held entries that change over time; this page pins the sixteen verified fixes with their own dates from the RFC Editor (retrieved 2026-11-01).