Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFs   Ti+SearchTech-invite World Map Symbol

RFC 7643


System for Cross-domain Identity Management: Core Schema

Part 4 of 4, p. 92 to 104
Prev RFC Part


prevText      Top      Up      ToC       Page 92 
9.  Security Considerations

9.1.  Protocol

   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 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.,
      hashing); and

   o  Where possible, avoid passwords as the sole form of
      authentication, and consider using credentials that are based on
      asymmetric cryptography.

9.3.  Privacy

   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).

Top      Up      ToC       Page 93 
   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.

Top      Up      ToC       Page 94 
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.2

10.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

Top      Up      ToC       Page 95 
10.2.1.  Specification Template

   Namespace ID:

      The Namespace ID "scim" has been assigned.

   Registration Information:

      Version: 1

      Date: 2015-06-22

   Declared registrant of the namespace:

      Registering organization
         The Internet Engineering Task Force

      Designated contact
         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.

Top      Up      ToC       Page 96 
   Relevant Ancillary Documentation:


   Identifier Uniqueness Considerations:

      The designated contact shall be responsible for reviewing and
      enforcing uniqueness.

   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,
      "", 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.

Top      Up      ToC       Page 97 
   Conformance with URN Syntax:

      No special considerations.

   Validation Mechanism:

      None specified.



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,, 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 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 and  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.

Top      Up      ToC       Page 98 
   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.,
      "Generic Device").

   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
      intended use.

   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.

Top      Up      ToC       Page 99 
10.4.  Initial SCIM Schema Registry

   The IANA has populated the "System for Cross-domain Identity
   Management (SCIM) Schema URIs" registry with the following registries
   for SCIM schema URIs, with pointers to appropriate reference
   documents.  Note: The schema URIs listed below are broken into two
   lines for readability.

   | Schema URI                        | Name            | Reference   |
   | urn:ietf:params:scim:schemas:     | User Resource   | See Section |
   | core:2.0:User                     |                 | 4.1         |
   |                                   |                 |             |
   | urn:ietf:params:scim:schemas:     | Enterprise User | See Section |
   | extension:enterprise:2.0:User     | Extension       | 4.3         |
   |                                   |                 |             |
   | urn:ietf:params:scim:schemas:     | Group Resource  | See Section |
   | core:2.0:Group                    |                 | 4.2         |

                    SCIM Schema URIs for Data Resources

   | Schema URI                        | Name              | Reference |
   | urn:ietf:params:scim:schemas:     | Service Provider  | See       |
   | core:2.0:ServiceProviderConfig    | Configuration     | Section 5 |
   |                                   | Schema            |           |
   |                                   |                   |           |
   | urn:ietf:params:scim:schemas:     | Resource Type     | See       |
   | core:2.0:ResourceType             | Configuration     | Section 6 |
   |                                   |                   |           |
   | urn:ietf:params:scim:schemas:     | Schema            | See       |
   | core:2.0:Schema                   | Definitions       | Section 7 |
   |                                   | Schema            |           |

                      SCIM Server-Related Schema URIs

Top      Up      ToC       Page 100 
11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC2141]  Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141,
              May 1997, <>.

   [RFC3553]  Mealling, M., Masinter, L., Hardie, T., and G. Klyne,
              "An IETF URN Sub-namespace for Registered Protocol
              Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553,
              June 2003, <>.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of
              ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629,
              November 2003, <>.

   [RFC3966]  Schulzrinne, H., "The tel URI for Telephone Numbers",
              RFC 3966, DOI 10.17487/RFC3966, December 2004,

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,

   [RFC4647]  Phillips, A. and M. Davis, "Matching of Language Tags",
              BCP 47, RFC 4647, DOI 10.17487/RFC4647, September 2006,

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,

   [RFC5234]  Crocker, D., Ed., and P. Overell, "Augmented BNF for
              Syntax Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/ RFC5234, January 2008,

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,

Top      Up      ToC       Page 101 
   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              DOI 10.17487/RFC5321, October 2008,

   [RFC5646]  Phillips, A., Ed., and M. Davis, Ed., "Tags for
              Identifying Languages", BCP 47, RFC 5646,
              DOI 10.17487/RFC5646, September 2009,

   [RFC6557]  Lear, E. and P. Eggert, "Procedures for Maintaining the
              Time Zone Database", BCP 175, RFC 6557,
              DOI 10.17487/RFC6557, February 2012,

   [RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, DOI 10.17487/RFC7159,
              March 2014, <>.

   [RFC7231]  Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
              Transfer Protocol (HTTP/1.1): Semantics and Content",
              RFC 7231, DOI 10.17487/RFC7231, June 2014,

   [RFC7232]  Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
              Transfer Protocol (HTTP/1.1): Conditional Requests",
              RFC 7232, DOI 10.17487/RFC7232, June 2014,

   [RFC7644]  Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E.,
              and C. Mortimore, "System for Cross-domain Identity
              Management: Protocol", RFC 7644, DOI 10.17487/RFC7644,
              September 2015, <>.

11.2.  Informative References

   [ISO3166]  International Organization for Standardization, "Codes for
              the representation of names of countries and their
              subdivisions - Part 1: Country codes", ISO 3166-1:2013,
              November 2013, <>.

   [Olson-TZ] Internet Assigned Numbers Authority, "IANA Time Zone
              Database", <>.

              Smarr, J., "Portable Contacts 1.0 Draft C - Schema Only",
              August 2008,

Top      Up      ToC       Page 102 
   [RFC2277]  Alvestrand, H., "IETF Policy on Character Sets and
              Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277,
              January 1998, <>.

   [RFC4512]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
              (LDAP): Directory Information Models", RFC 4512,
              DOI 10.17487/RFC4512, June 2006,

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,

   [RFC6350]  Perreault, S., "vCard Format Specification", RFC 6350,
              DOI 10.17487/RFC6350, August 2011,

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,

   [RFC6819]  Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
              Threat Model and Security Considerations", RFC 6819,
              DOI 10.17487/RFC6819, January 2013,

              Peterson, D., Gao, S., Malhotra, A., Sperberg-McQueen, C.,
              and H. Thompson, "XML Schema Definition Language (XSD) 1.1
              Part 2: Datatypes", April 2012,

Top      Up      ToC       Page 103 

   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 (

      Sidharth Choudhury (

      Samuel Erdtman (

      Kelly Grizzle (

      Chris Phillips (

      Erik Wahlstroem (

      Phil Hunt (

   Special thanks to Joseph Smarr, whose excellent work on the Portable
   Contacts Specification [PortableContacts] provided a basis for the
   SCIM schema structure and text.

Top      Up      ToC       Page 104 
Authors' Addresses

   Phil Hunt (editor)
   Oracle Corporation


   Kelly Grizzle


   Erik Wahlstroem
   Nexus Technology


   Chuck Mortimore