9. Security Considerations
SCIM data is intended to be exchanged using the SCIM protocol. It is
important when handling data to implement the security considerations
outlined in Section 7 of [RFC7644].
9.2. Passwords and Other Sensitive Security Data
Passwords and other attributes related to security credentials are of
an extremely sensitive nature and require special handling when
transmitted or stored. While the SCIM protocol uses cleartext
passwords for value assignment and equality-testing purposes,
password values MUST NOT be stored in cleartext form.
Administrators should undertake industry best practices to protect
the storage of credentials and in particular SHOULD follow
recommendations outlined in Section 22.214.171.124 of [RFC6819]. These
requirements include, but are not limited to, the following:
o Provide injection attack countermeasures (e.g., by validating all
inputs and parameters);
o Credentials should not be stored in cleartext form;
o Store credentials using an encrypted protection mechanism (e.g.,
o Where possible, avoid passwords as the sole form of
authentication, and consider using credentials that are based on
The SCIM core schema defines attributes that are sensitive and may be
considered personally identifying information (PII). These privacy
considerations should be considered for extensions as well as the
schema defined in this specification.
For the purposes of this specification, PII is defined as any
attribute that may be used as a unique key to identify a person
(e.g., "User"). Since other information may be used in combination
to identify an individual, all attributes in SCIM are considered
"sensitive" personal information. Consult regional jurisdictions to
see if there are special considerations for the handling of personal
information (e.g., PII).
Information should be shared on an as-needed basis. A SCIM client
should limit information to what it believes a service provider
requires, and a SCIM service provider should only accept information
it needs. Clients and service providers should take into
consideration that personal information is being conveyed across
technical (e.g., protocol and applications), administrative (e.g.,
organizational, corporate), and jurisdictional boundaries. In
particular, information security and privacy must be considered.
Security service level agreements for the handling of these
attributes are beyond the scope of this document but are to be
carefully considered by implementers and deploying organizations.
Please see the Privacy Considerations section of [RFC7644] for more
protocol-specific considerations regarding the handling of SCIM
SCIM defines attributes such as "id", "externalId", and SCIM resource
URIs, which cause new PII to be generated; this information is
important to the way that the SCIM protocol identifies and locates
resources. Where possible, it is suggested that service providers
take the following remediations:
o Where possible, assign and bind identifiers to specific tenants
and/or clients. When multiple tenants are able to reference the
same resource, they should do so via separate identifiers (id or
externalId). This ensures that separate domains linked to the
same information cannot perform identifier correlation.
o In the case of "externalId", if multiple values are supported, use
access control to restrict access to the client domain that
assigned the "externalId" value.
o Ensure that access to data is appropriately restricted to
authorized parties with a "need to know".
o When persisted, ensure that the appropriate protection mechanisms
are in place to restrict access by unauthorized parties, including
administrators or parties with access to backup data.
10. IANA Considerations
10.1. Registration of SCIM URN Sub-namespace and SCIM Registry
IANA has added an entry to the "IETF URN Sub-namespace for Registered
Protocol Parameter Identifiers" registry and created a sub-namespace
for the Registered Parameter Identifier as per [RFC3553]:
To manage this sub-namespace, IANA has created the "System for
Cross-domain Identity Management (SCIM) Schema URIs" registry, which
is used to manage entries within the "urn:ietf:params:scim"
namespace. The registry description is as follows:
o Registry name: SCIM
o Specification: this document (RFC 7643)
o Repository: See Section 10.2
o Index value: See Section 10.210.2. URN Sub-namespace for SCIM
SCIM schemas and SCIM messages utilize URIs to identify the schema in
use or other relevant context. This section creates and registers an
IETF URN Sub-namespace for use in the SCIM specifications and future
10.2.1. Specification Template
The Namespace ID "scim" has been assigned.
Declared registrant of the namespace:
The Internet Engineering Task Force
A designated expert will monitor the SCIM public mailing list,
Declaration of Syntactic Structure:
The Namespace Specific String (NSS) of all URNs that use the
"scim" Namespace ID shall have the following structure:
The keywords have the following meaning:
The entity type, which is either "schemas" or "api".
A required US-ASCII string that conforms to the URN syntax
requirements (see [RFC2141]) and defines a major namespace of a
schema used within SCIM (e.g., "core", which is reserved for
SCIM specifications). The value MAY also be an industry name
or organization name.
Any US-ASCII string that conforms to the URN syntax
requirements (see [RFC2141]) and defines the sub-namespace
(which MAY be further broken down in namespaces delimited by
colons) as needed to uniquely identify a schema.
Relevant Ancillary Documentation:
Identifier Uniqueness Considerations:
The designated contact shall be responsible for reviewing and
Identifier Persistence Considerations:
Once a name has been allocated, it MUST NOT be reallocated for a
different purpose. The rules provided for assignments of values
within a sub-namespace MUST be constructed so that the meanings of
values cannot change. This registration mechanism is not
appropriate for naming values whose meanings may change over time.
As the SCIM specifications are updated and the SCIM protocol
version is adjusted, a new registration will be made when
significant changes are made -- for example,
"urn:ietf:params:scim:schemas:core:1.0 (externally defined, not
previously registered)" and
Process of Identifier Assignment:
Identifiers with namespace type "schema" (e.g.,
"urn:ietf:params:scim:schemas") are assigned after the review of
the assigned contact via the SCIM public mailing list,
"firstname.lastname@example.org", as documented in Section 10.3.
Namespaces with type "api" (e.g., "urn:ietf:params:scim:api") and
"param" (e.g., "urn:ietf:params:scim:param") are reserved for
IETF-approved SCIM specifications.
Process of Identifier Resolution:
The namespace is not currently listed with a Resolution Discovery
System (RDS), but nothing about the namespace prohibits the future
definition of appropriate resolution methods or listing with an
Rules for Lexical Equivalence:
No special considerations; the rules for lexical equivalence
specified in [RFC2141] apply.
Conformance with URN Syntax:
No special considerations.
10.3. Registering SCIM Schemas
This section defines the process for registering new SCIM schemas
with IANA in the "System for Cross-domain Identity Management (SCIM)
Schema URIs" registry (see Section 10.1). A schema URI is used as a
value in the "schemas" attribute (Section 3) for the purpose of
distinguishing extensions used in a SCIM resource.
10.3.1. Registration Procedure
The IETF has created a mailing list, email@example.com, which can be used
for public discussion of SCIM schema proposals prior to registration.
Use of the mailing list is strongly encouraged. The IESG has
appointed a designated expert [RFC5226] who will monitor the
firstname.lastname@example.org mailing list and review registrations.
Registration of new "core" schemas (e.g., in the namespace
"urn:ietf:params:scim:schemas:core") and "API" schemas (e.g., in the
namespace "urn:ietf:params:scim:api") MUST be reviewed by the
designated expert and published in an RFC. An RFC is REQUIRED for
the registration of new value data types that modify existing
properties. An RFC is also REQUIRED for registration of SCIM schema
URIs that modify SCIM schema previously documented in an existing
RFC. URNs within "urn:ietf:params:scim" but outside the above
namespaces MAY be registered with a simple review (e.g., check for
spam) by the designated expert on a first-come-first-served basis.
The registration procedure begins when a completed registration
template, defined in the sections below, is sent to email@example.com and
firstname.lastname@example.org. Within two weeks, the designated expert is expected
to tell IANA and the submitter of the registration whether the
registration is approved, approved with minor changes, or rejected
with cause. When a registration is rejected with cause, it can be
resubmitted if the concerns listed in the cause are addressed.
Decisions made by the designated expert can be appealed to the IESG
Applications Area Director, then to the IESG. They follow the normal
appeals procedure for IESG decisions.
Once the registration procedure concludes successfully, IANA creates
or modifies the corresponding record in the SCIM schema registry.
The completed registration template is discarded.
An RFC specifying one or more new schema URIs MUST include the
completed registration templates, which MAY be expanded with
additional information. These completed templates are intended to go
in the body of the document, not in the IANA Considerations section.
The RFC SHOULD include any attributes defined.
10.3.2. Schema Registration Template
A SCIM schema URI is defined by completing the following template:
Schema URI: A unique URI for the SCIM schema extension.
Schema Name: A descriptive name of the schema extension (e.g.,
Intended or Associated Resource Type: A value defining the resource
type (e.g., "Device").
Purpose: A description of the purpose of the extension and/or its
Single-value Attributes: A list and description of single-valued
attributes defined, including complex attributes.
Multi-valued Attributes: A list and description of multi-valued
attributes defined, including complex attributes.
The editor would like to acknowledge the contribution and work of the
editors of draft versions of this document:
Chuck Mortimore, Salesforce
Patrick Harding, Ping
Paul Madsen, Ping
Trey Drake, UnboundID
The SCIM Community would like to thank the following people for the
work they've done in the research, formulation, drafting, editing,
and support of this specification.
Morteza Ansari (email@example.com)
Sidharth Choudhury (firstname.lastname@example.org)
Samuel Erdtman (email@example.com)
Kelly Grizzle (firstname.lastname@example.org)
Chris Phillips (email@example.com)
Erik Wahlstroem (firstname.lastname@example.org)
Phil Hunt (email@example.com)
Special thanks to Joseph Smarr, whose excellent work on the Portable
Contacts Specification [PortableContacts] provided a basis for the
SCIM schema structure and text.