ndovuai lab / SCIM: Playgrounds, Specs & Guides / SCIM schemas, explained ndovuai lab / SCIM: Playgrounds, Specs & Guides / SCIM schemas, explainedNDOVU · AUDIO EXPLAINER · LISTEN
Keys: space/K play-pause · J/L jump 10s · arrows on the waveform nudge 5s
The full briefing transcript, timed to the audio. Click any line to jump there; the current line lights up while you listen.
HostOpen the core schema RFC, 7643, to its Group schema. The prose says the display name is required. The JSON right next to it says required: false. Both shipped in the same document, and that is not the only defect: sixteen errata are verified against the RFC, and ten of them alter the schema JSON itself.
HostA reader who transcribes the published JSON inherits every defect. A reader who trusts the prose inherits the contradictions. This is the walkthrough of the SCIM schema contract - SCIM, S, C, I, M, pronounced sim: what discovery actually tells you, the characteristics that decide real integration behavior, and why the canonical text needs a corrected reading before you write a line of client code.
HostThe defects are specific. The Group schema declared the display name required in prose while carrying required false in the JSON; one erratum. Complex attributes carried a uniqueness characteristic the model does not define for complex types; another. The reference types on the group reference listed User where only Group applies; a third. Each one sits in a document thousands of teams copied from.
HostThat is why both readings matter. The corrected text is what implementations should converge on. The published text is what older libraries actually copied, which means the published text describes code that is running right now. The practical habit: read the corrected variant as the default, and keep the as-published text one toggle away so you know exactly what changed, and under which erratum, when an old library surprises you.
HostOn a live server you do not read the RFC to learn the schema. You ask the provider, and RFC 7644 Section 4 defines three endpoints that answer three questions in order. First, service provider config: what features? Whether PATCH exists at all, whether filtering is supported and up to how many results, whether sorting and ETags are in. Second, resource types: which resources? Each entry names a resource, its endpoint, and the schema and extension URIs that describe it. Third, schemas: which attributes? Each URI resolves into full attribute definitions, type by type.
HostProviders should support filtering on these read-only endpoints. And the URIs are not free-form strings: they live in an IANA registry, which newer RFCs extend. A client that discovers URIs instead of hard-coding them inherits those additions without a rewrite. The published schema JSON in the RFC is the same shape the schemas endpoint returns, which is why its errata matter twice: once for the book, once for the wire.
HostEvery attribute in a SCIM schema carries seven characteristics: type, whether it is multi-valued, whether it is required, caseExact, mutability, returned, and uniqueness. When the schema does not state one, a default applies, and the defaults are part of the contract: not required, not case-exact, read-write, returned by default, no uniqueness, type string.
HostAn omitted characteristic is a claim too, and integrations are won or lost on the two that matter most. CaseExact decides whether a reference value matches byte-for-byte or folded; the default folds, so a case-sensitive comparison against a default attribute is a bug waiting for the first capital letter. Mutability decides which PATCH operations the provider must reject; write against a read-only or immutable attribute and the 400 is correct behavior. For multi-valued attributes, one more default exists: the unspecified sub-attribute set is the standard five, type, primary, display, value, and the reference link.
HostThree things to carry. First: discover, do not assume. Three endpoints, three questions: features, resources, attributes; write against what the server returns, not a memory of one provider. Second: the defaults are load-bearing. An omitted caseExact folds, an omitted mutability permits writes, and both defaults are claims the server is allowed to hold you to. Third: the canonical text is not pristine. The published schema JSON carries recorded defects, so use the corrected reading by default and know exactly which errata touched the schema you are coding against. The schema explorer on this site keeps both readings side by side, with every erratum dated.