draft-ietf-scim-core-schema-18.txt   draft-ietf-scim-core-schema-19.txt 
Network Working Group P. Hunt, Ed. Network Working Group P. Hunt, Ed.
Internet-Draft Oracle Internet-Draft Oracle
Intended status: Standards Track K. Grizzle Intended status: Standards Track K. Grizzle
Expires: October 26, 2015 SailPoint Expires: November 12, 2015 SailPoint
E. Wahlstroem E. Wahlstroem
Nexus Technology Nexus Technology
C. Mortimore C. Mortimore
Salesforce Salesforce
April 24, 2015 May 11, 2015
System for Cross-Domain Identity Management: Core Schema System for Cross-Domain Identity Management: Core Schema
draft-ietf-scim-core-schema-18 draft-ietf-scim-core-schema-19
Abstract Abstract
The System for Cross-Domain Identity Management (SCIM) specifications The System for Cross-Domain Identity Management (SCIM) specifications
are designed to make identity management in cloud based applications are designed to make identity management in cloud based applications
and services easier. The specification suite builds upon experience and services easier. The specification suite builds upon experience
with existing schemas and deployments, placing specific emphasis on with existing schemas and deployments, placing specific emphasis on
simplicity of development and integration, while applying existing simplicity of development and integration, while applying existing
authentication, authorization, and privacy models. Its intent is to authentication, authorization, and privacy models. Its intent is to
reduce the cost and complexity of user management operations by reduce the cost and complexity of user management operations by
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 26, 2015. This Internet-Draft will expire on November 12, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation and Conventions . . . . . . . . . . 4 1.1. Requirements Notation and Conventions . . . . . . . . . . 4
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2. SCIM Schema . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. SCIM Schema . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Attributes . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Attributes . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Attribute Data Types . . . . . . . . . . . . . . . . . . 7 2.2. Attribute Characteristics . . . . . . . . . . . . . . . . 7
2.2.1. String . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Attribute Data Types . . . . . . . . . . . . . . . . . . 8
2.2.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.1. String . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.3. Decimal . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.4. Integer . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.3. Decimal . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.5. DateTime . . . . . . . . . . . . . . . . . . . . . . 8 2.3.4. Integer . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.6. Binary . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.5. DateTime . . . . . . . . . . . . . . . . . . . . . . 9
2.2.7. Reference . . . . . . . . . . . . . . . . . . . . . . 8 2.3.6. Binary . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.8. Complex . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.7. Reference . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Attribute Characteristics . . . . . . . . . . . . . . . . 9 2.3.8. Complex . . . . . . . . . . . . . . . . . . . . . . . 10
2.4. Multi-valued Attributes . . . . . . . . . . . . . . . . . 10 2.4. Multi-valued Attributes . . . . . . . . . . . . . . . . . 10
2.5. Unassigned and Null Values . . . . . . . . . . . . . . . 11 2.5. Unassigned and Null Values . . . . . . . . . . . . . . . 11
3. SCIM Resources . . . . . . . . . . . . . . . . . . . . . . . 11 3. SCIM Resources . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Common Attributes . . . . . . . . . . . . . . . . . . . . 14 3.1. Common Attributes . . . . . . . . . . . . . . . . . . . . 15
3.2. Defining New Resource Types . . . . . . . . . . . . . . . 15 3.2. Defining New Resource Types . . . . . . . . . . . . . . . 17
3.3. Attribute Extensions to Resources . . . . . . . . . . . . 16 3.3. Attribute Extensions to Resources . . . . . . . . . . . . 17
4. SCIM Core Resources and Extensions . . . . . . . . . . . . . 16 4. SCIM Core Resources and Extensions . . . . . . . . . . . . . 17
4.1. User Resource Schema . . . . . . . . . . . . . . . . . . 16 4.1. User Resource Schema . . . . . . . . . . . . . . . . . . 17
4.1.1. Singular Attributes . . . . . . . . . . . . . . . . . 16 4.1.1. Singular Attributes . . . . . . . . . . . . . . . . . 18
4.1.2. Multi-valued Attributes . . . . . . . . . . . . . . . 19 4.1.2. Multi-valued Attributes . . . . . . . . . . . . . . . 21
4.2. Group Resource Schema . . . . . . . . . . . . . . . . . . 22 4.2. Group Resource Schema . . . . . . . . . . . . . . . . . . 24
4.3. Enterprise User Schema Extension . . . . . . . . . . . . 22 4.3. Enterprise User Schema Extension . . . . . . . . . . . . 24
5. Service Provider Configuration Schema . . . . . . . . . . . . 23 5. Service Provider Configuration Schema . . . . . . . . . . . . 25
6. ResourceType Schema . . . . . . . . . . . . . . . . . . . . . 25 6. ResourceType Schema . . . . . . . . . . . . . . . . . . . . . 27
7. Schema Definition . . . . . . . . . . . . . . . . . . . . . . 26 7. Schema Definition . . . . . . . . . . . . . . . . . . . . . . 28
8. JSON Representation . . . . . . . . . . . . . . . . . . . . . 30 8. JSON Representation . . . . . . . . . . . . . . . . . . . . . 31
8.1. Minimal User Representation . . . . . . . . . . . . . . . 30 8.1. Minimal User Representation . . . . . . . . . . . . . . . 31
8.2. Full User Representation . . . . . . . . . . . . . . . . 30 8.2. Full User Representation . . . . . . . . . . . . . . . . 32
8.3. Enterprise User Extension Representation . . . . . . . . 33 8.3. Enterprise User Extension Representation . . . . . . . . 35
8.4. Group Representation . . . . . . . . . . . . . . . . . . 36 8.4. Group Representation . . . . . . . . . . . . . . . . . . 38
8.5. Service Provider Configuration Representation . . . . . . 37 8.5. Service Provider Configuration Representation . . . . . . 39
8.6. Resource Type Representation . . . . . . . . . . . . . . 39 8.6. Resource Type Representation . . . . . . . . . . . . . . 41
8.7. Schema Representation . . . . . . . . . . . . . . . . . . 39 8.7. Schema Representation . . . . . . . . . . . . . . . . . . 41
8.7.1. Resource Schema Representation . . . . . . . . . . . 40 8.7.1. Resource Schema Representation . . . . . . . . . . . 42
8.7.2. Service Provider Schema Representation . . . . . . . 62 8.7.2. Service Provider Schema Representation . . . . . . . 64
9. Security Considerations . . . . . . . . . . . . . . . . . . . 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 79
9.1. Protocol . . . . . . . . . . . . . . . . . . . . . . . . 77 9.1. Protocol . . . . . . . . . . . . . . . . . . . . . . . . 79
9.2. Password and Other Sensitive Security Data . . . . . . . 77 9.2. Password and Other Sensitive Security Data . . . . . . . 79
9.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 77 9.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 80
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81
10.1. Registration of SCIM URN Sub-namespace & SCIM Registry . 78 10.1. Registration of SCIM URN Sub-namespace & SCIM Registry . 81
10.2. URN Sub-Namespace for SCIM . . . . . . . . . . . . . . . 79 10.2. URN Sub-Namespace for SCIM . . . . . . . . . . . . . . . 81
10.2.1. Specification Template . . . . . . . . . . . . . . . 79 10.2.1. Specification Template . . . . . . . . . . . . . . . 81
10.3. Registering SCIM Schemas . . . . . . . . . . . . . . . . 81 10.3. Registering SCIM Schemas . . . . . . . . . . . . . . . . 84
10.3.1. Registration Procedure . . . . . . . . . . . . . . . 81 10.3.1. Registration Procedure . . . . . . . . . . . . . . . 84
10.3.2. Schema Registration Template . . . . . . . . . . . . 82 10.3.2. Schema Registration Template . . . . . . . . . . . . 85
10.4. Initial SCIM Schema Registry . . . . . . . . . . . . . . 82 10.4. Initial SCIM Schema Registry . . . . . . . . . . . . . . 85
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 86
11.1. Normative References . . . . . . . . . . . . . . . . . . 83 11.1. Normative References . . . . . . . . . . . . . . . . . . 86
11.2. Informative References . . . . . . . . . . . . . . . . . 84 11.2. Informative References . . . . . . . . . . . . . . . . . 87
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 85 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 88
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 86 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 89
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 93
1. Introduction and Overview 1. Introduction and Overview
While there are existing standards for describing and exchanging user While there are existing standards for describing and exchanging user
information, many of these standards can be difficult to implement information, many of these standards can be difficult to implement
and/or use; e.g., their wire protocols do not easily traverse and/or use; e.g., their wire protocols do not easily traverse
firewalls and/or are not easily layered onto existing web protocols. firewalls and/or are not easily layered onto existing web protocols.
As a result, many cloud providers implement non-standardized As a result, many cloud providers implement non-standardized
protocols for managing users within their services. This increases protocols for managing users within their services. This increases
both the cost and complexity associated with organizations adopting both the cost and complexity associated with organizations adopting
skipping to change at page 4, line 8 skipping to change at page 4, line 8
SCIM seeks to simplify this problem through a simple to implement SCIM seeks to simplify this problem through a simple to implement
specification suite that provides a common user schema and extension specification suite that provides a common user schema and extension
model, as well as a SCIM Protocol document, that defines exchanging model, as well as a SCIM Protocol document, that defines exchanging
this schema via an HTTP based protocol [I-D.ietf-scim-api]. [[RFC this schema via an HTTP based protocol [I-D.ietf-scim-api]. [[RFC
Editor: This document an the companion scim-api document should be Editor: This document an the companion scim-api document should be
published together]] It draws inspiration and best practice, building published together]] It draws inspiration and best practice, building
upon existing user protocols and schemas from a wide variety of upon existing user protocols and schemas from a wide variety of
sources including, but not limited to, existing services exposed by sources including, but not limited to, existing services exposed by
cloud providers, PortableContacts [PortableContacts], vCards cloud providers, PortableContacts [PortableContacts], vCards
[RFC6350], and LDAP directory services [RFC6350]. [RFC6350], and Lightweight Directory Access Protocol (LDAP) directory
services [RFC4512].
SCIM protocol is an application-level protocol for provisioning and
managing identity data specified through SCIM schemas. The protocol
supports creation, modification, retrieval, and discovery of core
identity resources such as Users and Groups, using a subset of the
HTTP methods (GET for retrieval of resources, POST for creation,
searching and bulk modification, PUT for attribute replacement within
resources, PATCH for partial update of attributes, and DELETE for
removing resources).
This document provides a JSON based schema and extension model for This document provides a JSON based schema and extension model for
representing users and groups, as well as Service Provider representing users and groups, as well as service provider
configuration. This schema is intended for exchange and use with configuration. This schema is intended for exchange and use with
cloud service providers and other cross-domain scenarios. cloud service providers and other cross-domain scenarios.
1.1. Requirements Notation and Conventions 1.1. Requirements Notation and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Throughout this document, values are quoted to indicate that they are Throughout this document, values are quoted to indicate that they are
skipping to change at page 4, line 38 skipping to change at page 4, line 48
readability reasons. readability reasons.
1.2. Definitions 1.2. Definitions
Service Provider Service Provider
An HTTP web application that provides identity information via the An HTTP web application that provides identity information via the
SCIM protocol. SCIM protocol.
Client Client
A website or application that uses the SCIM protocol to manage A website or application that uses the SCIM protocol to manage
identity data maintained by the service provider. The Client identity data maintained by the service provider. The client
initiates SCIM HTTP requests to a target service provider. initiates SCIM HTTP requests to a target service provider.
Provisioning Domain Provisioning Domain
A provisioning domain is an administrative domain external to the A provisioning domain is an administrative domain external to the
domain of a Service Provider for legal or technical reasons. For domain of a service provider for legal or technical reasons. For
example, a SCIM Client in an enterprise (provisioning client) example, a SCIM client in an enterprise (provisioning client)
communicates with a SCIM Service Provider that is owned or communicates with a SCIM service provider that is owned or
controlled by a different legal entity. controlled by a different legal entity.
Resource Type Resource Type
A type of a resource that is managed by a service provider. The A type of a resource that is managed by a service provider. The
resource type defines the resource name, endpoint URL, Schemas, resource type defines the resource name, endpoint URL, Schemas,
and other meta-data which indicate where a resource is managed and and other meta-data which indicate where a resource is managed and
how it is composed; e.g., "User" or "Group". how it is composed; e.g., "User" or "Group".
Resource Resource
A Service Provider managed artifact containing one or more A service provider managed artifact containing one or more
attributes. For example a "User" or "Group". attributes. For example a "User" or "Group".
Endpoint Endpoint
An endpoint for a Service Provider is a defined base path relative An endpoint for a service provider is a defined base path relative
to the service providers Base URI (see definitions of to the service providers Base URI (see definitions of
[I-D.ietf-scim-api]) over which SCIM operations MAY be performed [I-D.ietf-scim-api]) over which SCIM operations MAY be performed
against SCIM resources. For example, assuming the Service against SCIM resources. For example, assuming the service
Provider Base URI is "https://example.com/": "User" resources may provider Base URI is "https://example.com/": "User" resources may
be accessed at the "https://example.com/Users", or be accessed at the "https://example.com/Users", or
"https://example.com/v2/Users" (when including protocol version, "https://example.com/v2/Users" (when including protocol version,
see Section 3.13 [I-D.ietf-scim-api]) endpoint. Service provider see Section 3.13 [I-D.ietf-scim-api]) endpoint. Service provider
schemas MAY be returned from the "/Schemas" endpoint. schemas MAY be returned from the "/Schemas" endpoint.
Schema Schema
A collection of attribute definitions that describe the contents A collection of attribute definitions that describe the contents
of an entire or partial resource; e.g., of an entire or partial resource; e.g.,
"urn:ietf:params:scim:schemas:core:2.0:User". The attribute "urn:ietf:params:scim:schemas:core:2.0:User". The attribute
definitions define the name of the attribute, and metadata such as definitions define the name of the attribute, and metadata such as
skipping to change at page 6, line 27 skipping to change at page 6, line 34
an existing resource with a replacement JSON object, evaluates each an existing resource with a replacement JSON object, evaluates each
asserted attribute based on its characteristics as defined in the asserted attribute based on its characteristics as defined in the
relevant schema (e.g., mutability) and decides which attributes may relevant schema (e.g., mutability) and decides which attributes may
be replaced or ignored. be replaced or ignored.
This specification provides a minimal core schema for representing This specification provides a minimal core schema for representing
users and groups (resources), encompassing common attributes found in users and groups (resources), encompassing common attributes found in
many existing deployments and schemas. In addition to the minimal many existing deployments and schemas. In addition to the minimal
core schema, this document also specifies a standardized means by core schema, this document also specifies a standardized means by
which service providers may extend schemas to define new resources which service providers may extend schemas to define new resources
and attributes in both standardized and Service Provider specific and attributes in both standardized and service provider specific
cases. cases.
Resources are categorized into common resource types such as "User" Resources are categorized into common resource types such as "User"
or "Group"). Collections of resources of the same type are usually or "Group"). Collections of resources of the same type are usually
contained within the same "container" ("folder") endpoint. contained within the same "container" ("folder") endpoint.
2.1. Attributes 2.1. Attributes
A resource is a collection of attributes identified by one or more A resource is a collection of attributes identified by one or more
schemas. Minimally, an attribute consists of the attribute name and schemas. Minimally, an attribute consists of the attribute name and
skipping to change at page 7, line 12 skipping to change at page 7, line 23
Figure 1: ABNF for Attribute Names Figure 1: ABNF for Attribute Names
The above rules (and other rules in this specification) use the "Core The above rules (and other rules in this specification) use the "Core
Rules" from ABNF, see Appendix B [RFC5234]. Unless otherwise Rules" from ABNF, see Appendix B [RFC5234]. Unless otherwise
specified in this specification, all ABNF strings are case specified in this specification, all ABNF strings are case
insensitive and the character set for these strings is US-ASCII. For insensitive and the character set for these strings is US-ASCII. For
example, all attribute names defined by the above rule are case example, all attribute names defined by the above rule are case
insensitive. insensitive.
2.2. Attribute Data Types When defining attribute names it should be noted that the hyphen
("-") is not permitted in Javascript (and some other languages)
attribute names. While there are no known issues within HTTP
protocol and JSON notation, attribute names containing hyphens MAY
need to be escaped when declaring corresponding names of Javascript
attributes.
2.2. Attribute Characteristics
If not otherwise stated in Section 7, SCIM attributes have the
following characteristics:
o are OPTIONAL (is not REQUIRED).
o are case insensitive ("caseExact" is "false"),
o are modifiable ("mutability" is "readWrite"),
o are returned in response to queries (returned by default),
o have no canonical values (for example, the "type" sub-attribute in
Section 2.4,
o are not unique ("uniqueness" is "none"), and,
o of type string (Section 2.3.1).
2.3. Attribute Data Types
Attribute data types are derived from JSON [RFC7159]. The JSON Attribute data types are derived from JSON [RFC7159]. The JSON
format defines a limited set of data types, hence, where appropriate, format defines a limited set of data types, hence, where appropriate,
alternate JSON representations derived from XML Schema [XML-Schema] alternate JSON representations derived from XML Schema [XML-Schema]
are defined below. SCIM extensions SHOULD NOT introduce new data are defined below. SCIM extensions SHOULD NOT introduce new data
types. types.
The following is a table that maps the following data types, to SCIM The following is a table that maps the following data types, to SCIM
schema type and the underlying JSON data type: schema type and the underlying JSON data type:
skipping to change at page 7, line 40 skipping to change at page 8, line 33
| Integer | "integer" | Number per Sec. 6 [RFC7159] | | Integer | "integer" | Number per Sec. 6 [RFC7159] |
| DateTime | "dateTime" | String per Sec. 7 [RFC7159] | | DateTime | "dateTime" | String per Sec. 7 [RFC7159] |
| Binary | "binary" | Base64 encoded String per Sec. 7 | | Binary | "binary" | Base64 encoded String per Sec. 7 |
| | | [RFC7159] | | | | [RFC7159] |
| Reference | "reference" | String per Sec. 7 [RFC7159] | | Reference | "reference" | String per Sec. 7 [RFC7159] |
| Complex | "complex" | Object per Sec. 4 [RFC7159] | | Complex | "complex" | Object per Sec. 4 [RFC7159] |
+--------------+-----------------+----------------------------------+ +--------------+-----------------+----------------------------------+
Table 1: SCIM Data Type to JSON Representation Table 1: SCIM Data Type to JSON Representation
2.2.1. String 2.3.1. String
A sequence of zero or more Unicode characters encoded using UTF-8 as A sequence of zero or more Unicode characters encoded using UTF-8 as
per [RFC2277] and [RFC3629]. The JSON format is defined in Section 7 per [RFC2277] and [RFC3629]. The JSON format is defined in Section 7
[RFC7159]. A "String" attribute MAY specify a required data format. [RFC7159]. A "String" attribute MAY specify a required data format.
Additionally, when "canonicalValues" is specified, service providers Additionally, when "canonicalValues" is specified, service providers
MAY restrict accepted values to the specified values. MAY restrict accepted values to the specified values.
2.2.2. Boolean 2.3.2. Boolean
The literal "true" or "false". The JSON format is defined in The literal "true" or "false". The JSON format is defined in
Section 3 [RFC7159]. A boolean has no case sensitivity or Section 3 [RFC7159]. A boolean has no case sensitivity or
uniqueness. uniqueness.
2.2.3. Decimal 2.3.3. Decimal
A real number with at least one digit to the left and right of the A real number with at least one digit to the left and right of the
period. The JSON format is defined in Section 6 [RFC7159]. A period. The JSON format is defined in Section 6 [RFC7159]. A
decimal has no case sensitivity. decimal has no case sensitivity.
2.2.4. Integer 2.3.4. Integer
A decimal number with no fractional digits. The JSON format is A decimal number with no fractional digits. The JSON format is
defined in Section 6 [RFC7159] with the additional constraint that defined in Section 6 [RFC7159] with the additional constraint that
the value MUST NOT contain fractional or exponent parts. An integer the value MUST NOT contain fractional or exponent parts. An integer
has no case sensitivity. has no case sensitivity.
2.2.5. DateTime 2.3.5. DateTime
A DateTime value (e.g., 2008-01-23T04:56:22Z). The attribute value A DateTime value (e.g., 2008-01-23T04:56:22Z). The attribute value
MUST be encoded as a valid xsd:dateTime as specified in Section 3.3.7 MUST be encoded as a valid xsd:dateTime as specified in Section 3.3.7
[XML-Schema]. A date-time has no case-sensitivity or uniqueness. [XML-Schema]. A date-time has no case-sensitivity or uniqueness.
Values represented in JSON MUST conform to the XML constraints above Values represented in JSON MUST conform to the XML constraints above
and are represented as a JSON String per Section 7 [RFC7159]. and are represented as a JSON String per Section 7 [RFC7159].
2.2.6. Binary 2.3.6. Binary
Arbitrary binary data. The attribute value MUST be encoded in base Arbitrary binary data. The attribute value MUST be encoded in base
64 encoding as specified in Section 4 [RFC4648]. In cases where a 64 encoding as specified in Section 4 [RFC4648]. In cases where a
URL-safe encoding is required, the attribute definition MAY specify URL-safe encoding is required, the attribute definition MAY specify
Base 64 URL encoding be used as per Section 5 [RFC4648]. Unless Base 64 URL encoding be used as per Section 5 [RFC4648]. Unless
otherwise specified in the attribute definition, trailing padding otherwise specified in the attribute definition, trailing padding
characters MAY be omitted ("="). characters MAY be omitted ("=").
In JSON representation, the encoded values are represented as a JSON In JSON representation, the encoded values are represented as a JSON
String per Section 7 [RFC7159]. A binary is case-exact and has no String per Section 7 [RFC7159]. A binary is case-exact and has no
uniqueness. uniqueness.
2.2.7. Reference 2.3.7. Reference
The value is a URI for a resource. A resource MAY be a SCIM The value is a URI for a resource. A resource MAY be a SCIM
resource, an external link to a resource (e.g., a photo), or it may resource, an external link to a resource (e.g., a photo), or it may
be an identifier such as a URN. The value MUST be the absolute or be an identifier such as a URN. The value MUST be the absolute or
relative URI of the target resource. Relative URIs should be relative URI of the target resource. Relative URIs should be
resolved as specified in Section 5.2 [RFC3986]. However, the base resolved as specified in Section 5.2 [RFC3986]. However, the base
URI for relative URI resolution MUST include all URI components and URI for relative URI resolution MUST include all URI components and
path segments up to but not including the Endpoint URI (the SCIM path segments up to but not including the Endpoint URI (the SCIM
Service Provider root endpoint); e.g., the base URI for a request to service provider root endpoint); e.g., the base URI for a request to
"https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646" "https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646"
would be "https://example.com/v2/" and the relative URI for this would be "https://example.com/v2/" and the relative URI for this
resource would be "Users/2819c223-7f76-453a-919d-413861904646". resource would be "Users/2819c223-7f76-453a-919d-413861904646".
In JSON representation, the URI value is represented as a JSON String In JSON representation, the URI value is represented as a JSON String
per Section 7 [RFC7159]. A reference is case-exact. A reference has per Section 7 [RFC7159]. A reference is case-exact. A reference has
a "referenceType" that indicates what types of resources may be a "referenceType" that indicates what types of resources may be
linked as per Section 7. linked as per Section 7.
Performing a GET operation on a reference URI MUST return the target Performing a GET operation on a reference URI MUST return the target
resource or an appropriate HTTP response code. The Service Provider resource or an appropriate HTTP response code. The service provider
MAY optionally choose to enforce referential integrity for reference MAY optionally choose to enforce referential integrity for reference
types referring to SCIM resources. types referring to SCIM resources.
By convention, a reference is commonly represented as a "$ref" sub- By convention, a reference is commonly represented as a "$ref" sub-
attribute in complex or multi-valued attributes, however this is attribute in complex or multi-valued attributes, however this is
OPTIONAL. OPTIONAL.
2.2.8. Complex 2.3.8. Complex
A singular or multi-valued attribute whose value is a composition of A singular or multi-valued attribute whose value is a composition of
one or more simple attributes. The JSON format is defined in one or more simple attributes. The JSON format is defined in
Section 4 [RFC7159]. The order of the component attributes is not Section 4 [RFC7159]. The order of the component attributes is not
significant. Servers and clients MUST NOT require or expect significant. Servers and clients MUST NOT require or expect
attributes to be in any specific order when an object is either attributes to be in any specific order when an object is either
generated or analyzed. A complex attribute has no uniqueness or case generated or analyzed. A complex attribute has no uniqueness or case
sensitivity. A complex attribute MUST NOT contain sub-attributes sensitivity. A complex attribute MUST NOT contain sub-attributes
that have sub-attributes (i.e., that are complex). that have sub-attributes (i.e., that are complex).
2.3. Attribute Characteristics
If not otherwise stated in Section 7, SCIM attributes have the
following characteristics:
o are OPTIONAL (is not REQUIRED).
o are case insensitive ("caseExact" is "false"),
o are modifiable ("mutability" is "readWrite"),
o are returned in response to queries (returned by default),
o have no canonical values (for example, the "type" sub-attribute in
Section 2.4,
o are not unique ("uniqueness" is "none"), and,
o of type string (Section 2.2.1).
2.4. Multi-valued Attributes 2.4. Multi-valued Attributes
Multi-valued attributes contain a list of elements using the JSON Multi-valued attributes contain a list of elements using the JSON
array format defined in Section 5 of [RFC7159]. Elements can be array format defined in Section 5 of [RFC7159]. Elements can be
either either
o primitive values, or o primitive values, or
o objects with a set of sub-attributes and values, using the JSON o objects with a set of sub-attributes and values, using the JSON
object format defined in Section 4 of [RFC7159], in which case object format defined in Section 4 of [RFC7159], in which case
they MAY also be considered to be complex attributes. As with they MAY also be considered to be complex attributes. As with
complex attributes, the order of sub-attributes is not complex attributes, the order of sub-attributes is not
significant. The pre-defined sub-attributes listed in this significant. The pre-defined sub-attributes listed in this
section can be used with multi-valued attribute objects but these section can be used with multi-valued attribute objects but these
sub-attributes should only be used with the meanings defined here. sub-attributes MUST be used with the meanings defined here.
The pre-defined set of sub-attributes for a multi-valued attribute The pre-defined set of sub-attributes for a multi-valued attribute
are: are:
type type
A label indicating the attribute's function; e.g., "work" or A label indicating the attribute's function; e.g., "work" or
"home". "home".
primary primary
A Boolean value indicating the 'primary' or preferred attribute A Boolean value indicating the 'primary' or preferred attribute
skipping to change at page 10, line 44 skipping to change at page 11, line 16
display display
A human readable name, primarily used for display purposes and has A human readable name, primarily used for display purposes and has
a mutability of "immutable". a mutability of "immutable".
value value
The attribute's significant value; e.g., the e-mail address, phone The attribute's significant value; e.g., the e-mail address, phone
number, etc. number, etc.
$ref $ref
The reference URI of the target resource, if the attribute is a The reference URI of a target resource, if the attribute is a
reference. reference. URIs are canonicalized per Section 6.2 of [RFC3986].
While the representation of a resource MAY vary in different SCIM
protocol API versions (see section 3.13 of [I-D.ietf-scim-api]),
URI's for SCIM resources with an API version SHALL be considered
comparable to one without a version or different version. For
example, "https://example.com/Users/12345" is equivalent to
"https://example.com/v2/Users/12345".
When returning multi-valued attributes, service providers SHOULD When returning multi-valued attributes, service providers SHOULD
canonicalize the value returned (e.g., by returning a value for the canonicalize the value returned (e.g., by returning a value for the
sub-attribute "type" such as "home" or "work") when appropriate sub-attribute "type" such as "home" or "work") when appropriate
(e.g., for e-mail addresses and URLs). (e.g., for e-mail addresses and URLs).
Service providers MAY return element objects with the same "value" Service providers MAY return element objects with the same "value"
sub-attribute more than once with a different "type" sub-attribute sub-attribute more than once with a different "type" sub-attribute
(e.g., the same e-mail address may used for work and home), but (e.g., the same e-mail address may used for work and home), but
SHOULD NOT return the same (type, value) combination more than once SHOULD NOT return the same (type, value) combination more than once
skipping to change at page 14, line 10 skipping to change at page 15, line 10
} }
} }
Figure 2: Example JSON Resource Structure Figure 2: Example JSON Resource Structure
3.1. Common Attributes 3.1. Common Attributes
Each SCIM resource (Users, Groups, etc.) includes the following Each SCIM resource (Users, Groups, etc.) includes the following
common attributes. With the exception of "ServiceProviderConfig" and common attributes. With the exception of "ServiceProviderConfig" and
"ResourceType" server discovery endpoints and their associated "ResourceType" server discovery endpoints and their associated
resources, these attributes MUST be included in all resources, resources, these attributes MUST be defined for all resources,
including any extended resource types. Common attributes are including any extended resource types. When accepted by a service
considered to be part of every base resource schema and do not use provider (e.g., after a SCIM create), the attributes "id" and "meta"
their own schemas URI and SHALL NOT be considered schema extensions. (and its associated sub-attributes) MUST be assigned values by the
service provider. Common attributes are considered to be part of
every base resource schema and do not use their own schemas URI and
SHALL NOT be considered schema extensions.
For backwards compatibility reasons, some existing schema MAY list For backwards compatibility reasons, some existing schema MAY list
common attributes as part of the schema. The attribute common attributes as part of the schema. The attribute
characteristics listed here SHALL take precedence. characteristics listed here SHALL take precedence.
id id
A unique identifier for a SCIM resource as defined by the service A unique identifier for a SCIM resource as defined by the service
provider. Each representation of the resource MUST include a non- provider. Each representation of the resource MUST include a non-
empty "id" value. This identifier MUST be unique across the SCIM empty "id" value. This identifier MUST be unique across the SCIM
service provider's entire set of resources. It MUST be a stable, service provider's entire set of resources. It MUST be a stable,
non-reassignable identifier that does not change when the same non-reassignable identifier that does not change when the same
resource is returned in subsequent requests. The value of the resource is returned in subsequent requests. The value of the
"id" attribute is always issued by the Service Provider and MUST "id" attribute is always issued by the service provider and MUST
NOT be specified by the client. The string "bulkId" is a reserved NOT be specified by the client. The string "bulkId" is a reserved
keyword and MUST NOT be used within any unique identifier value. keyword and MUST NOT be used within any unique identifier value.
The attribute characteristics are "caseExact" as "true" and a The attribute characteristics are "caseExact" as "true" and a
mutability of "readOnly". See Section 9 for additional mutability of "readOnly". See Section 9 for additional
considerations regarding privacy. considerations regarding privacy.
externalId externalId
A String that is an identifier for the resource as defined by the A String that is an identifier for the resource as defined by the
provisioning client. The "externalId" may simplify identification provisioning client. The "externalId" may simplify identification
of a resource between the provisioning Client and the Service of a resource between the provisioning client and the service
Provider by allowing the Client to use a filter to locate the provider by allowing the client to use a filter to locate the
resource with an identifier from the provisioning domain, resource with an identifier from the provisioning domain,
obviating the need to store a local mapping between the obviating the need to store a local mapping between the
provisioning domain's identifier of the resource and the provisioning domain's identifier of the resource and the
identifier used by the service provider. Each resource MAY identifier used by the service provider. Each resource MAY
include a non-empty "externalId" value. The value of the include a non-empty "externalId" value. The value of the
"externalId" attribute is always issued by the provisioning Client "externalId" attribute is always issued by the provisioning client
and MUST NOT be specified by the service provider. The Service and MUST NOT be specified by the service provider. The service
Provider MUST always interpret the externalId as scoped to the provider MUST always interpret the externalId as scoped to the
provisioning domain. While the server does not enforce provisioning domain. While the server does not enforce
uniqueness, it is assumed that the value's uniqueness is uniqueness, it is assumed that the value's uniqueness is
controlled by the Client setting the value. See Section 9 for controlled by the client setting the value. See Section 9 for
additional considerations regarding privacy. The attribute has additional considerations regarding privacy. The attribute has
"caseExact" as "true" and has a mutability of "readWrite". The "caseExact" as "true" and has a mutability of "readWrite". The
attribute is OPTIONAL. attribute is OPTIONAL.
meta meta
A complex attribute containing resource metadata. All meta sub- A complex attribute containing resource metadata. All meta sub-
attributes are asserted by the Service Provider and SHALL be attributes are asserted by the service provider and SHALL be
ignored when provided by clients: ignored when provided by clients:
resourceType The name of the resource type of the resource. This resourceType The name of the resource type of the resource. This
attribute has mutability of "readOnly" and has "caseExact" as attribute has mutability of "readOnly" and has "caseExact" as
"true". The attribute is REQUIRED when provided by the service "true". The attribute is REQUIRED when provided by the service
provider. provider.
created The DateTime the resource was added to the service created The DateTime the resource was added to the service
provider. The attribute MUST be a DateTime. This attribute provider. The attribute MUST be a DateTime. This attribute
has mutability of "readOnly". has mutability of "readOnly".
skipping to change at page 15, line 39 skipping to change at page 16, line 41
Section 3.1.4.2 [RFC7231]). The attribute has mutability of Section 3.1.4.2 [RFC7231]). The attribute has mutability of
"readOnly". The attribute is REQUIRED when provided by the "readOnly". The attribute is REQUIRED when provided by the
service provider. service provider.
version The version of the resource being returned. This value version The version of the resource being returned. This value
must be the same as the ETag HTTP response header (See Sections must be the same as the ETag HTTP response header (See Sections
2.1 and 2.3 of [RFC7232]). The attribute has mutability of 2.1 and 2.3 of [RFC7232]). The attribute has mutability of
"readOnly" and has "caseExact" as "true". The attribute is "readOnly" and has "caseExact" as "true". The attribute is
OPTIONAL subject to the service provider's support for OPTIONAL subject to the service provider's support for
versioning (see "Versioning Resources", Section 3.14 versioning (see "Versioning Resources", Section 3.14
[I-D.ietf-scim-api]). If a Service Provider provides "version" [I-D.ietf-scim-api]). If a service provider provides "version"
(entity-tag) for a representation and the generation of that (entity-tag) for a representation and the generation of that
entity-tag does not satisfy all of the characteristics of a entity-tag does not satisfy all of the characteristics of a
strong validator (see Section 2.1, [RFC7232]), then the origin strong validator (see Section 2.1, [RFC7232]), then the origin
server MUST mark the "version" (entity-tag) as weak by server MUST mark the "version" (entity-tag) as weak by
prefixing its opaque value with "W/" (case-sensitive). prefixing its opaque value with "W/" (case-sensitive).
3.2. Defining New Resource Types 3.2. Defining New Resource Types
SCIM may be extended to define new classes of resources by defining a SCIM may be extended to define new classes of resources by defining a
resource type. Each resource type defines the name, endpoint, base resource type. Each resource type defines the name, endpoint, base
schema (the attributes), and any schema extensions registered for use schema (the attributes), and any schema extensions registered for use
with the resource type. In order to offer new types of resources, a with the resource type. In order to offer new types of resources, a
Service Provider defines the new resource type as specified in service provider defines the new resource type as specified in
Section 6 and defines a schema representation (see Section 8.7). Section 6 and defines a schema representation (see Section 8.7).
3.3. Attribute Extensions to Resources 3.3. Attribute Extensions to Resources
SCIM allows resource types to have extensions in addition to their SCIM allows resource types to have extensions in addition to their
core schema. This is similar to how "ObjectClasses" are used in core schema. This is similar to how "ObjectClasses" are used in LDAP
LDAP. However, unlike LDAP there is no inheritance model; all [RFC4512]. However, unlike LDAP there is no inheritance model; all
extensions are additive (similar to LDAP Auxiliary Object Class extensions are additive (similar to LDAP Auxiliary Object Class).
[RFC4512] ). Each value in the "schemas" attribute indicates Each value in the "schemas" attribute indicates additive schema that
additive schema that MAY exist in a SCIM resource representation. MAY exist in a SCIM resource representation. The "schemas" attribute
The "schemas" attribute MUST contain at least one value which SHALL MUST contain at least one value which SHALL be the base schema for
be the base schema for the resource. The "schemas" attribute MAY the resource. The "schemas" attribute MAY contain additional values
contain additional values indicating extended schemas that are in indicating extended schemas that are in use. Schema extensions
use. Schema extensions SHOULD avoid redefining any attributes SHOULD avoid redefining any attributes defined in this specification
defined in this specification and SHOULD follow conventions defined and SHOULD follow conventions defined in this specification. Except
in this specification. Except for the base object schema, the schema for the base object schema, the schema extension URI SHALL be used as
extension URI SHALL be used as a JSON container to distinguish a JSON container to distinguish attributes belonging to the extension
attributes belonging to the extension namespace from base schema namespace from base schema attributes. See Figure 5 for an example
attributes. See Figure 5 for an example of the JSON representation of the JSON representation of an extended User.
of an extended User.
In order to determine which URI value in the "schemas" attribute is In order to determine which URI value in the "schemas" attribute is
the base schema and which is extended schema for any given resource, the base schema and which is extended schema for any given resource,
the resource's "resourceType" attribute value MAY be used to retrieve the resource's "resourceType" attribute value MAY be used to retrieve
the resource's "ResourceType" schema ( Section 6 ). See example the resource's "ResourceType" schema ( Section 6 ). See example
"ResourceType" representation in Figure 8. "ResourceType" representation in Figure 8.
4. SCIM Core Resources and Extensions 4. SCIM Core Resources and Extensions
This section defines the default resources schemas present in a SCIM This section defines the default resources schemas present in a SCIM
skipping to change at page 16, line 48 skipping to change at page 18, line 8
4.1. User Resource Schema 4.1. User Resource Schema
SCIM provides a resource type for "User" resources. The core schema SCIM provides a resource type for "User" resources. The core schema
for "User" is identified using the URI: for "User" is identified using the URI:
"urn:ietf:params:scim:schemas:core:2.0:User". The following "urn:ietf:params:scim:schemas:core:2.0:User". The following
attributes are defined in addition to the core schema attributes: attributes are defined in addition to the core schema attributes:
4.1.1. Singular Attributes 4.1.1. Singular Attributes
userName userName
A Service Provider unique identifier for the user, typically used A service provider unique identifier for the user, typically used
by the user to directly authenticate to the service provider. by the user to directly authenticate to the service provider.
Often displayed to the user as their unique identifier within the Often displayed to the user as their unique identifier within the
system (as opposed to "id" or "externalId", which are generally system (as opposed to "id" or "externalId", which are generally
opaque and not user-friendly identifiers). Each User MUST include opaque and not user-friendly identifiers). Each User MUST include
a non-empty userName value. This identifier MUST be unique across a non-empty userName value. This identifier MUST be unique across
the service provider's entire set of Users. The attribute is the service provider's entire set of Users. The attribute is
REQUIRED and is case-insensitive. REQUIRED and is case-insensitive.
name name
The components of the user's real name. Service providers MAY The components of the user's real name. Service providers MAY
skipping to change at page 17, line 48 skipping to change at page 19, line 7
in most Western languages (e.g., "III." given the full name in most Western languages (e.g., "III." given the full name
"Ms. Barbara Jane Jensen, III." ). "Ms. Barbara Jane Jensen, III." ).
displayName displayName
The name of the user, suitable for display to end-users. Each The name of the user, suitable for display to end-users. Each
user returned MAY include a non-empty displayName value. The name user returned MAY include a non-empty displayName value. The name
SHOULD be the full name of the User being described if known SHOULD be the full name of the User being described if known
(e.g., "Babs Jensen" or "Ms. Barbara J Jensen, III" ), but MAY be (e.g., "Babs Jensen" or "Ms. Barbara J Jensen, III" ), but MAY be
a username or handle, if that is all that is available (e.g., a username or handle, if that is all that is available (e.g.,
"bjensen" ). The value provided SHOULD be the primary textual "bjensen" ). The value provided SHOULD be the primary textual
label by which this User is normally displayed by the Service label by which this User is normally displayed by the service
Provider when presenting it to end-users. provider when presenting it to end-users.
nickName nickName
The casual way to address the user in real life, e.g., "Bob" or The casual way to address the user in real life, e.g., "Bob" or
"Bobby" instead of "Robert". This attribute SHOULD NOT be used to "Bobby" instead of "Robert". This attribute SHOULD NOT be used to
represent a User's username (e.g., bjensen or mpepperidge). represent a User's username (e.g., bjensen or mpepperidge).
profileUrl profileUrl
A URI that is a uniform resource locator (as defined in A URI that is a uniform resource locator (as defined in
Section 1.1.3 [RFC3986]), that points to a location representing Section 1.1.3 [RFC3986]), that points to a location representing
the user's online profile (e.g. a web page). the user's online profile (e.g. a web page). URIs are
canonicalized per Section 6.2 of [RFC3986].
title title
The user's title, such as "Vice President". The user's title, such as "Vice President".
userType userType
Used to identify the organization to user relationship. Typical Used to identify the organization to user relationship. Typical
values used might be "Contractor", "Employee", "Intern", "Temp", values used might be "Contractor", "Employee", "Intern", "Temp",
"External", and "Unknown" but any value may be used. "External", and "Unknown" but any value may be used.
preferredLanguage preferredLanguage
skipping to change at page 19, line 22 skipping to change at page 20, line 29
example: "America/Los_Angeles". example: "America/Los_Angeles".
active active
A Boolean value indicating the user's administrative status. The A Boolean value indicating the user's administrative status. The
definitive meaning of this attribute is determined by the service definitive meaning of this attribute is determined by the service
provider. As a typical example, a value of true infers the user provider. As a typical example, a value of true infers the user
is able to login while a value of false implies the user's account is able to login while a value of false implies the user's account
has been suspended. has been suspended.
password password
The user's clear text password. This attribute is intended to be This attribute is intended to be used as a means to set, replace,
used as a means to specify an initial password when creating a new or compare (i.e., filter for equality) a password. The clear-text
User or to reset an existing User's password. Password policies value or the hashed value of a password SHALL NOT be returnable by
and the ability to update or set passwords are out of scope of a service provider. If a service provider holds the value
this document. The mutability of this attribute is "writeOnly" locally, the value SHOULD be hashed. When a password is set or
indicating the value MUST NOT be returned by a Service Provider in changed, the clear text password SHOULD be:
any form (the attribute characteristic "returned" is "never").
Please see Sections 7.5 and 7.6 [I-D.ietf-scim-api] for security * Prepared for international language comparison. See
considerations regarding the handling of passwords. Section 7.7 of [I-D.ietf-scim-api].
* Validated against server password policy. Note: the definition
and enforcment of password policy is beyond the scope of this
document.
* And, is hashed or encrypted. See Section 9.2 for acceptable
hasing and encryption handling when storing or persisting for
provisioning workflow reasons.
A service provider that immediately passes the value on to another
system or programming interface, MAY pass the value directly over
a secured connection (e.g., TLS). If the value needs to be
temporarily persisted for a period of time (e.g., because of a
workflow) before provisioning, then the value MUST be protected by
some method such as encryption.
Testing for an equality match MAY be supported if there is an
existing stored hashed value. When testing for equality, the
service provider:
* Prepares the filter value for international language
comparison. See Section 7.7 of [I-D.ietf-scim-api].
* The service provider generates the salted hash of the filter
value and test for a match with the locally held value.
The mutability of the password attribute is "writeOnly" indicating
the value MUST NOT be returned by a service provider in any form
(the attribute characteristic "returned" is "never").
4.1.2. Multi-valued Attributes 4.1.2. Multi-valued Attributes
The following multi-valued attributes are defined. The following multi-valued attributes are defined.
emails emails
E-mail addresses for the User. The value SHOULD be specified E-mail addresses for the User. The value SHOULD be specified
according to [RFC5321]. Service providers SHOULD canonicalize the according to [RFC5321]. Service providers SHOULD canonicalize the
value according to [RFC5321], e.g., "bjensen@example.com" instead value according to [RFC5321], e.g., "bjensen@example.com" instead
of "bjensen@EXAMPLE.COM". The "display" sub-attribute MAY be used of "bjensen@EXAMPLE.COM". The "display" sub-attribute MAY be used
to return the canonicalized representation of the e-mail value. to return the canonicalized representation of the e-mail value.
The "type" sub-attribute of contains values of "work", "home", and The "type" sub-attribute is used to provide a classification
"other", and MAY allow more types to be defined by the SCIM meaningful to the (human) user. The user interface should
clients. encourage the use of basic values of "work", "home", and "other",
and MAY allow additional type values to be used at the descretion
of SCIM clients.
phoneNumbers phoneNumbers
Phone numbers for the user. The value SHOULD be specified Phone numbers for the user. The value SHOULD be specified
according to the format in [RFC3966] e.g., 'tel:+1-201-555-0123'. according to the format in [RFC3966] e.g., 'tel:+1-201-555-0123'.
Service providers SHOULD canonicalize the value according to Service providers SHOULD canonicalize the value according to
[RFC3966] format, when appropriate. The "display" sub-attribute [RFC3966] format, when appropriate. The "display" sub-attribute
MAY be used to return the canonicalized representation of the MAY be used to return the canonicalized representation of the
phone number value. The sub-attribute "type" often has typical phone number value. The sub-attribute "type" often has typical
values of "work", "home", "mobile", "fax", "pager", and "other", values of "work", "home", "mobile", "fax", "pager", and "other",
and MAY allow more types to be defined by the SCIM clients. and MAY allow more types to be defined by the SCIM clients.
ims ims
Instant messaging address for the user. No official Instant messaging address for the user. No official
canonicalization rules exist for all instant messaging addresses, canonicalization rules exist for all instant messaging addresses,
but service providers SHOULD, when appropriate, remove all but service providers SHOULD, when appropriate, remove all
whitespace and convert the address to lowercase. The "type" whitespace and convert the address to lowercase. The "type" sub-
attribute defines several "canonicalValues" to represent currently attribute SHOULD take one of the following values: "aim", "gtalk",
popular IM services: "aim", "gtalk", "icq", "xmpp", "msn", "icq", "xmpp", "msn", "skype", "qq", "yahoo", and "other",
"skype", "qq", "yahoo", and "other". representing currently popular IM services at the time of writing.
Service providers MAY add further values if new IM services are
introduced and MAY specify more detailed canonicalization rules
for each possible value.
photos photos
A URI that is a uniform resource locator (as defined in A URI that is a uniform resource locator (as defined in
Section 1.1.3 [RFC3986]) that points to a resource location Section 1.1.3 [RFC3986]) that points to a resource location
representing the user's image. The resource MUST be a file (e.g., representing the user's image. The resource MUST be a file (e.g.,
a GIF, JPEG, or PNG image file) rather than a web page containing a GIF, JPEG, or PNG image file) rather than a web page containing
an image. Service providers MAY return the same image at an image. Service providers MAY return the same image at
different sizes, though it is recognized that no standard for different sizes, though it is recognized that no standard for
describing images of various sizes currently exists. Note that describing images of various sizes currently exists. Note that
this attribute SHOULD NOT be used to send down arbitrary photos this attribute SHOULD NOT be used to send down arbitrary photos
skipping to change at page 21, line 26 skipping to change at page 23, line 19
and any behavior or authorization granted as a result of and any behavior or authorization granted as a result of
membership are defined by the service provider. The canonical membership are defined by the service provider. The canonical
types "direct" and "indirect" are defined to describe how the types "direct" and "indirect" are defined to describe how the
group membership was derived. Direct group membership indicates group membership was derived. Direct group membership indicates
the user is directly associated with the group and SHOULD indicate the user is directly associated with the group and SHOULD indicate
that clients may modify membership through the "Group" resource. that clients may modify membership through the "Group" resource.
Indirect membership indicates user membership is transitive or Indirect membership indicates user membership is transitive or
dynamic and implies that clients cannot modify indirect group dynamic and implies that clients cannot modify indirect group
membership through the "Group" resource but MAY modify direct membership through the "Group" resource but MAY modify direct
group membership through the "Group" resource which MAY influence group membership through the "Group" resource which MAY influence
indirect memberships. If the SCIM Service Provider exposes a indirect memberships. If the SCIM service provider exposes a
Group resource, the "value" sub-attribute MUST be the "id" and the Group resource, the "value" sub-attribute MUST be the "id" and the
"$ref" sub-attribute must be the URI of the corresponding "Group" "$ref" sub-attribute must be the URI of the corresponding "Group"
resources to which the user belongs. Since this attribute has a resources to which the user belongs. Since this attribute has a
mutability of "readOnly", group membership changes MUST be applied mutability of "readOnly", group membership changes MUST be applied
via the Group Resource (Section 4.2). The attribute has a via the Group Resource (Section 4.2). The attribute has a
mutability of "readOnly". mutability of "readOnly".
entitlements entitlements
A list of entitlements for the user that represent a thing the A list of entitlements for the user that represent a thing the
user has. An entitlement MAY be an additional right to a thing, user has. An entitlement MAY be an additional right to a thing,
skipping to change at page 22, line 34 skipping to change at page 24, line 31
A human readable name for the Group. REQUIRED. A human readable name for the Group. REQUIRED.
The following multi-valued attribute is defined in addition to the The following multi-valued attribute is defined in addition to the
common attributes defined in SCIM Core Schema: common attributes defined in SCIM Core Schema:
members members
A list of members of the Group. While values MAY be added or A list of members of the Group. While values MAY be added or
removed, sub-attributes of members are "immutable". The "value" removed, sub-attributes of members are "immutable". The "value"
sub-attribute must be the "id" and the "$ref" sub-attribute must sub-attribute must be the "id" and the "$ref" sub-attribute must
be the URI of a SCIM resource, either a "User", or a "Group". The be the URI of a SCIM resource, either a "User", or a "Group". The
intention of the "Group" type is to allow the Service Provider to intention of the "Group" type is to allow the service provider to
support nested groups. Service providers MAY require clients to support nested groups. Service providers MAY require clients to
provide a non-empty members value based on the "required" sub provide a non-empty members value based on the "required" sub
attribute of the "members" attribute in the "Group" resource attribute of the "members" attribute in the "Group" resource
schema. schema.
4.3. Enterprise User Schema Extension 4.3. Enterprise User Schema Extension
The following SCIM extension defines attributes commonly used in The following SCIM extension defines attributes commonly used in
representing users that belong to, or act on behalf of a business or representing users that belong to, or act on behalf of a business or
enterprise. The enterprise user extension is identified using the enterprise. The enterprise user extension is identified using the
skipping to change at page 23, line 40 skipping to change at page 25, line 35
displayName The displayName of the user's manager. This displayName The displayName of the user's manager. This
attribute is OPTIONAL and mutability is "readOnly". attribute is OPTIONAL and mutability is "readOnly".
5. Service Provider Configuration Schema 5. Service Provider Configuration Schema
SCIM provides a schema for representing the service provider's SCIM provides a schema for representing the service provider's
configuration identified using the following schema URI: configuration identified using the following schema URI:
"urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig" "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig"
The Service Provider configuration resource enables a Service The service provider configuration resource enables a service
Provider to discover SCIM specification features in a standardized provider to discover SCIM specification features in a standardized
form as well as provide additional implementation details to clients. form as well as provide additional implementation details to clients.
All attributes have a mutability of "readOnly". Unlike other core All attributes have a mutability of "readOnly". Unlike other core
resources, the "id" attribute is not required for the Service resources, the "id" attribute is not required for the service
Provider configuration resource. provider configuration resource.
The following Singular Attributes are defined in addition to the The following Singular Attributes are defined in addition to the
common attributes defined in Core Schema: common attributes defined in Core Schema:
documentationUrl documentationUrl
An HTTP addressable URL pointing to the service provider's human An HTTP addressable URL pointing to the service provider's human
consumable help documentation. consumable help documentation.
patch patch
A complex type that specifies PATCH configuration options. A complex type that specifies PATCH configuration options.
REQUIRED. See Section 3.5.2 [I-D.ietf-scim-api]. REQUIRED. See Section 3.5.2 [I-D.ietf-scim-api].
supported Boolean value specifying whether the operation is supported Boolean value specifying whether the operation is
supported. REQUIRED. supported. REQUIRED.
bulk bulk
A complex type that specifies Bulk configuration options. A complex type that specifies Bulk configuration options. See
REQUIRED Section 3.7 [I-D.ietf-scim-api]. REQUIRED
supported Boolean value specifying whether the operation is supported Boolean value specifying whether the operation is
supported. REQUIRED. See Section 3.7 [I-D.ietf-scim-api]. supported. REQUIRED.
maxOperations An integer value specifying the maximum number of maxOperations An integer value specifying the maximum number of
operations. REQUIRED. operations. REQUIRED.
maxPayloadSize An integer value specifying the maximum payload maxPayloadSize An integer value specifying the maximum payload
size in bytes. REQUIRED. size in bytes. REQUIRED.
filter filter
A complex type that specifies FILTER options. REQUIRED. See A complex type that specifies FILTER options. REQUIRED. See
Section 3.4.2.2 [I-D.ietf-scim-api]. Section 3.4.2.2 [I-D.ietf-scim-api].
skipping to change at page 25, line 18 skipping to change at page 27, line 13
supported. REQUIRED. supported. REQUIRED.
The following multi-valued attribute is defined in addition to the The following multi-valued attribute is defined in addition to the
common attributes defined in core schema: common attributes defined in core schema:
authenticationSchemes authenticationSchemes
A complex type that specifies supported Authentication Scheme A complex type that specifies supported Authentication Scheme
properties. This attribute defines the following canonical values properties. This attribute defines the following canonical values
to represent common schemes: "oauth", "oauth2", to represent common schemes: "oauth", "oauth2",
"oauthbearertoken", "httpbasic", and "httpdigest". To enable "oauthbearertoken", "httpbasic", and "httpdigest". To enable
seamless discovery of configuration, the Service Provider SHOULD, seamless discovery of configuration, the service provider SHOULD,
with the appropriate security considerations, make the with the appropriate security considerations, make the
authenticationSchemes attribute publicly accessible without prior authenticationSchemes attribute publicly accessible without prior
authentication. REQUIRED. authentication. REQUIRED.
name The common authentication scheme name; e.g., HTTP Basic. name The common authentication scheme name; e.g., HTTP Basic.
REQUIRED. REQUIRED.
description A description of the Authentication Scheme. description A description of the Authentication Scheme.
REQUIRED. REQUIRED.
skipping to change at page 27, line 32 skipping to change at page 29, line 25
description description
The schema's human readable description. When applicable service The schema's human readable description. When applicable service
providers MUST specify the description specified in the core providers MUST specify the description specified in the core
schema specification. OPTIONAL. schema specification. OPTIONAL.
The following multi-valued attribute is defined: The following multi-valued attribute is defined:
attributes attributes
A complex type with the following set of sub-attributes that A complex type with the following set of sub-attributes that
defines Service Provider attributes and their qualities: defines service provider attributes and their qualities:
name The attribute's name. name The attribute's name.
type The attribute's data type. Valid values are: "string", type The attribute's data type. Valid values are: "string",
"boolean", "decimal", "integer", "dateTime", "reference", and "boolean", "decimal", "integer", "dateTime", "reference", and
"complex". When an attribute is of type "complex", there "complex". When an attribute is of type "complex", there
SHOULD be a corresponding schema attribute "subAttributes" SHOULD be a corresponding schema attribute "subAttributes"
defined listing the sub-attribtues of the attribute. defined listing the sub-attribtues of the attribute.
subAttributes When an attribute is of type "complex", subAttributes When an attribute is of type "complex",
skipping to change at page 28, line 49 skipping to change at page 30, line 41
returned A single keyword that indicates when an attribute and returned A single keyword that indicates when an attribute and
associated values are returned in response to a GET request or associated values are returned in response to a GET request or
in response to a PUT, POST, or PATCH request. Valid keywords in response to a PUT, POST, or PATCH request. Valid keywords
are: are:
always The attribute is always returned regardless of the always The attribute is always returned regardless of the
contents of the "attributes" parameter. For example, "id" contents of the "attributes" parameter. For example, "id"
is always returned to identify a SCIM resource. is always returned to identify a SCIM resource.
never The attribute is never returned. This may occur because never The attribute is never returned. This may occur because
the original attribute value is not retained by the Service the original attribute value is not retained by the service
Provider (e.g., such as with a hashed value). A Service provider (e.g., such as with a hashed value). A service
Provider MAY allow attributes to be used in a search filter. provider MAY allow attributes to be used in a search filter.
default The attribute is returned by default in all SCIM default The attribute is returned by default in all SCIM
operation responses where attribute values are returned. If operation responses where attribute values are returned. If
the GET request "attributes" parameter is specified, the GET request "attributes" parameter is specified,
attribute values are only returned if the attribute is named attribute values are only returned if the attribute is named
in the attributes parameter. DEFAULT. in the attributes parameter. DEFAULT.
request The attribute is returned in response to any PUT, request The attribute is returned in response to any PUT,
POST, or PATCH operations if the attribute was specified by POST, or PATCH operations if the attribute was specified by
the Client (for example, the attribute was modified). The the client (for example, the attribute was modified). The
attribute is returned in a SCIM query operation only if attribute is returned in a SCIM query operation only if
specified in the "attributes" parameter. specified in the "attributes" parameter.
uniqueness A single keyword value that specifies how the Service uniqueness A single keyword value that specifies how the service
Provider enforces uniqueness of attribute values. A server MAY provider enforces uniqueness of attribute values. A server MAY
reject an invalid value based on uniqueness by returning HTTP reject an invalid value based on uniqueness by returning HTTP
Response code 400 (Bad Request). A Client MAY enforce Response code 400 (Bad Request). A client MAY enforce
uniqueness on the client-side to a greater degree than the uniqueness on the client-side to a greater degree than the
Service Provider enforces. For example, a Client could make a service provider enforces. For example, a client could make a
value unique while the server has uniqueness of "none". Valid value unique while the server has uniqueness of "none". Valid
keywords are: keywords are:
none The values are not intended to be unique in any way. none The values are not intended to be unique in any way.
DEFAULT. DEFAULT.
server The value SHOULD be unique within the context of the server The value SHOULD be unique within the context of the
current SCIM endpoint (or tenancy) and MAY be globally current SCIM endpoint (or tenancy) and MAY be globally
unique (e.g., a "username", email address, or other server unique (e.g., a "username", email address, or other server
generated key or counter). No two resources on the same generated key or counter). No two resources on the same
skipping to change at page 29, line 52 skipping to change at page 31, line 43
+ A SCIM resource type (e.g., "User" or "Group"), + A SCIM resource type (e.g., "User" or "Group"),
+ "external" - indicating the resource is an external resource + "external" - indicating the resource is an external resource
(e.g., such as a photo), or (e.g., such as a photo), or
+ "uri" - indicating that the reference is to a service + "uri" - indicating that the reference is to a service
endpoint or an identifier (e.g., such as a schema urn). endpoint or an identifier (e.g., such as a schema urn).
This attribute is only applicable for attributes that are of This attribute is only applicable for attributes that are of
type "reference" (Section 2.2.7). type "reference" (Section 2.3.7).
8. JSON Representation 8. JSON Representation
8.1. Minimal User Representation 8.1. Minimal User Representation
The following is a non-normative example of the minimal required SCIM The following is a non-normative example of the minimal required SCIM
representation in JSON format. representation in JSON format.
{ {
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"], "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
skipping to change at page 35, line 24 skipping to change at page 37, line 17
"userType": "Employee", "userType": "Employee",
"title": "Tour Guide", "title": "Tour Guide",
"preferredLanguage":"en-US", "preferredLanguage":"en-US",
"locale": "en-US", "locale": "en-US",
"timezone": "America/Los_Angeles", "timezone": "America/Los_Angeles",
"active":true, "active":true,
"password":"t1meMa$heen", "password":"t1meMa$heen",
"groups": [ "groups": [
{ {
"value": "e9e30dba-f08f-4109-8486-d5c6a331660a", "value": "e9e30dba-f08f-4109-8486-d5c6a331660a",
"$ref": "/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a", "$ref": "../Groups/e9e30dba-f08f-4109-8486-d5c6a331660a",
"display": "Tour Guides" "display": "Tour Guides"
}, },
{ {
"value": "fc348aa8-3835-40eb-a20b-c726e15c55b5", "value": "fc348aa8-3835-40eb-a20b-c726e15c55b5",
"$ref": "/Groups/fc348aa8-3835-40eb-a20b-c726e15c55b5", "$ref": "../Groups/fc348aa8-3835-40eb-a20b-c726e15c55b5",
"display": "Employees" "display": "Employees"
}, },
{ {
"value": "71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7", "value": "71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7",
"$ref": "/Groups/71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7", "$ref": "../Groups/71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7",
"display": "US Employees" "display": "US Employees"
} }
], ],
"x509Certificates": [ "x509Certificates": [
{ {
"value": "value":
"MIIDQzCCAqygAwIBAgICEAAwDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMx "MIIDQzCCAqygAwIBAgICEAAwDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMx
EzARBgNVBAgMCkNhbGlmb3JuaWExFDASBgNVBAoMC2V4YW1wbGUuY29tMRQwEgYD EzARBgNVBAgMCkNhbGlmb3JuaWExFDASBgNVBAoMC2V4YW1wbGUuY29tMRQwEgYD
VQQDDAtleGFtcGxlLmNvbTAeFw0xMTEwMjIwNjI0MzFaFw0xMjEwMDQwNjI0MzFa VQQDDAtleGFtcGxlLmNvbTAeFw0xMTEwMjIwNjI0MzFaFw0xMjEwMDQwNjI0MzFa
MH8xCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRQwEgYDVQQKDAtl MH8xCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRQwEgYDVQQKDAtl
skipping to change at page 36, line 11 skipping to change at page 38, line 4
zidPl8HZ7DhXkZIRtJwBweq4bvm3hM1Os7UQH05ZS6cVDgweKNwdLLrT51ikSQG3 zidPl8HZ7DhXkZIRtJwBweq4bvm3hM1Os7UQH05ZS6cVDgweKNwdLLrT51ikSQG3
DYrl+ft781UQRIqxgwqCfXEuDiinPh0kkvIi5jivVu1Z9QiwlYEdRbLJ4zJQBmDr DYrl+ft781UQRIqxgwqCfXEuDiinPh0kkvIi5jivVu1Z9QiwlYEdRbLJ4zJQBmDr
SGTMYn4lRc2HgHO4DqB/bnMVorHB0CC6AV1QoFK4GPe1LwIDAQABo3sweTAJBgNV SGTMYn4lRc2HgHO4DqB/bnMVorHB0CC6AV1QoFK4GPe1LwIDAQABo3sweTAJBgNV
HRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZp HRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZp
Y2F0ZTAdBgNVHQ4EFgQU8pD0U0vsZIsaA16lL8En8bx0F/gwHwYDVR0jBBgwFoAU Y2F0ZTAdBgNVHQ4EFgQU8pD0U0vsZIsaA16lL8En8bx0F/gwHwYDVR0jBBgwFoAU
dGeKitcaF7gnzsNwDx708kqaVt0wDQYJKoZIhvcNAQEFBQADgYEAA81SsFnOdYJt dGeKitcaF7gnzsNwDx708kqaVt0wDQYJKoZIhvcNAQEFBQADgYEAA81SsFnOdYJt
Ng5Tcq+/ByEDrBgnusx0jloUhByPMEVkoMZ3J7j1ZgI8rAbOkNngX8+pKfTiDz1R Ng5Tcq+/ByEDrBgnusx0jloUhByPMEVkoMZ3J7j1ZgI8rAbOkNngX8+pKfTiDz1R
C4+dx8oU6Za+4NJXUjlL5CvV6BEYb1+QAEJwitTVvxB/A67g42/vzgAtoRUeDov1 C4+dx8oU6Za+4NJXUjlL5CvV6BEYb1+QAEJwitTVvxB/A67g42/vzgAtoRUeDov1
+GFiBZ+GNF/cAYKcMtGcrs2i97ZkJMo=" +GFiBZ+GNF/cAYKcMtGcrs2i97ZkJMo="
} }
], ],
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": { "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
"employeeNumber": "701984", "employeeNumber": "701984",
"costCenter": "4130", "costCenter": "4130",
"organization": "Universal Studios", "organization": "Universal Studios",
"division": "Theme Park", "division": "Theme Park",
"department": "Tour Operations", "department": "Tour Operations",
"manager": [{ "manager": {
"value": "26118915-6090-4610-87e4-49d8ca9f808d", "value": "26118915-6090-4610-87e4-49d8ca9f808d",
"$ref": "/Users/26118915-6090-4610-87e4-49d8ca9f808d", "$ref": "../Users/26118915-6090-4610-87e4-49d8ca9f808d",
"displayName": "John Smith" "displayName": "John Smith"
}] }
}, },
"meta": { "meta": {
"resourceType": "User", "resourceType": "User",
"created": "2010-01-23T04:56:22Z", "created": "2010-01-23T04:56:22Z",
"lastModified": "2011-05-13T04:42:34Z", "lastModified": "2011-05-13T04:42:34Z",
"version": "W\/\"3694e05e9dff591\"", "version": "W\/\"3694e05e9dff591\"",
"location": "location":
"https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646" "https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646"
} }
} }
skipping to change at page 37, line 37 skipping to change at page 39, line 37
"version": "W\/\"3694e05e9dff592\"", "version": "W\/\"3694e05e9dff592\"",
"location": "location":
"https://example.com/v2/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a" "https://example.com/v2/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a"
} }
} }
Figure 6: Example Group JSON Representation Figure 6: Example Group JSON Representation
8.5. Service Provider Configuration Representation 8.5. Service Provider Configuration Representation
The following is a non-normative example of the SCIM Service Provider The following is a non-normative example of the SCIM service provider
configuration representation in JSON format. configuration representation in JSON format.
{ {
"schemas": [ "schemas": [
"urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig" "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig"
], ],
"documentationUrl":"http://example.com/help/scim.html", "documentationUrl":"http://example.com/help/scim.html",
"patch": { "patch": {
"supported":true "supported":true
}, },
skipping to change at page 39, line 47 skipping to change at page 41, line 47
"location":"https://example.com/v2/ResourceTypes/Group", "location":"https://example.com/v2/ResourceTypes/Group",
"resourceType": "ResourceType" "resourceType": "ResourceType"
} }
}] }]
Figure 8: Example Resource Type JSON Representation Figure 8: Example Resource Type JSON Representation
8.7. Schema Representation 8.7. Schema Representation
The following sections provide representations of schemas for both The following sections provide representations of schemas for both
SCIM resources and Service Provider schemas. Note that the JSON SCIM resources and service provider schemas. Note that the JSON
representation has been modified for readability and to fit the representation has been modified for readability and to fit the
specification format. specification format.
8.7.1. Resource Schema Representation 8.7.1. Resource Schema Representation
The following is intended as an example of the SCIM Schema The following is intended as an example of the SCIM Schema
representation in JSON format for SCIM resources. Where permitted representation in JSON format for SCIM resources. Where permitted
individual values and schema MAY change. Included but not limited individual values and schema MAY change. Included but not limited
to, are schemas for User, Group, and enterprise user. to, are schemas for User, Group, and enterprise user.
skipping to change at page 61, line 10 skipping to change at page 63, line 10
"description" : "Identifies the name of a department.", "description" : "Identifies the name of a department.",
"required" : false, "required" : false,
"caseExact" : false, "caseExact" : false,
"mutability" : "readWrite", "mutability" : "readWrite",
"returned" : "default", "returned" : "default",
"uniqueness" : "none" "uniqueness" : "none"
}, },
{ {
"name" : "manager", "name" : "manager",
"type" : "complex", "type" : "complex",
"multiValued" : true, "multiValued" : false,
"description" : "The User's manager. A complex type that "description" : "The User's manager. A complex type that
optionally allows Service Providers to represent organizational optionally allows Service Providers to represent organizational
hierarchy by referencing the 'id' attribute of another User.", hierarchy by referencing the 'id' attribute of another User.",
"required" : false, "required" : false,
"subAttributes" : [ "subAttributes" : [
{ {
"name" : "value", "name" : "value",
"type" : "string", "type" : "string",
"multiValued" : false, "multiValued" : false,
"description" : "The id of the SCIM resource representing "description" : "The id of the SCIM resource representing
skipping to change at page 62, line 25 skipping to change at page 64, line 25
"/v2/Schemas/urn:ietf:params:scim:schemas:extension:enterprise:2.0:User" "/v2/Schemas/urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
} }
} }
] ]
Figure 9: Example JSON Representation for Resource Schema Figure 9: Example JSON Representation for Resource Schema
8.7.2. Service Provider Schema Representation 8.7.2. Service Provider Schema Representation
The following is a representation of the SCIM Schema for the fixed The following is a representation of the SCIM Schema for the fixed
Service Provider schemas: ServiceProviderConfig, ResourceType, and service provider schemas: ServiceProviderConfig, ResourceType, and
Schema. Schema.
[ [
{ {
"id" : "id" :
"urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig", "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig",
"name" : "Service Provider Configuration", "name" : "Service Provider Configuration",
"description" : "Schema for representing the service provider's "description" : "Schema for representing the service provider's
configuration", configuration",
"attributes" : [ "attributes" : [
skipping to change at page 77, line 37 skipping to change at page 79, line 37
9.1. Protocol 9.1. Protocol
SCIM data is intended to be exchanged using SCIM Protocol. It is SCIM data is intended to be exchanged using SCIM Protocol. It is
important when handling data to implement the security considerations important when handling data to implement the security considerations
outlined in Section 7 of [I-D.ietf-scim-api]. outlined in Section 7 of [I-D.ietf-scim-api].
9.2. Password and Other Sensitive Security Data 9.2. Password and Other Sensitive Security Data
Passwords and other attributes related to security credentials are of Passwords and other attributes related to security credentials are of
extreme sensitive nature and require special handling when extreme sensitive nature and require special handling when
transmitted or stored. See Sections 7.5 and 7.6 of transmitted or stored. While SCIM Protocol uses clear-text passwords
[I-D.ietf-scim-api] regarding guidelines on how to store and compare for setting and equality testing purposes, password values MUST NOT
password values. be stored in clear-text form.
Administrators should undertake industry best practices to protect
the storage of credentials and in particular SHOULD follow
recommendations outlines in Section 5.1.4.1 [RFC6819]. These
requirements include but are not limited to:
o Provide injection attack counter measures (e.g., by validating all
inputs and parameters),
o No cleartext storage of credentials,
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 use of asymmetric cryptography based
credentials.
9.3. Privacy 9.3. Privacy
The SCIM Core schema defines attributes that MAY contain personally The SCIM Core schema defines attributes that are sensitive and may be
identifying information as well as other sensitive data. These considered personally identifying information (PII). These privacy
privacy considerations should be considered for extensions as well as considerations should be considered for extensions as well as the
the schema defined in this specification schema defined in this specification.
In particular, attributes such as "id" and "externalId" are of For the purposes of this specification personally identifying
particular concern as personally identifiable information that information is defined as any attribute that MAY be used as a unique
uniquely map to Users (because they are URIs). Where possible, it is key to identify a person (e.g., User). Since other information MAY
suggested that service providers take the following remediations: 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 and PII information.
o Assign and bind identifiers to specific tenants and/or clients. Information should be shared on an as-needed basis. A SCIM client
When multiple tenants are able to reference the same resource, should limit information to what it believes a service provider
they should do so via separate identifiers (id or externalId). requires, and a SCIM service provider, should only accept information
This ensures that separate domains linked to the same information it needs. Clients and service providers should take into
can not perform identifier correlation. 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 [I-D.ietf-scim-api],
for more protocol specific considerations for handling of SCIM
information.
SCIM defines attributes such as "id" and "externalId" and SCIM
resource URIs which causes new PII information to be generated which
is important to the way 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 can not perform identifier correlation.
o In the case of "externalId", if multiple values are supported, use o In the case of "externalId", if multiple values are supported, use
access control to restrict access to the Client domain that access control to restrict access to the client domain that
assigned the "externalId" value. assigned the "externalId" value.
o Ensure that access to data is appropriately restricted to o Ensure that access to data is appropriately restricted to
authorized parties with a need-to-know. authorized parties with a need-to-know.
o When persisted, the appropriate protection mechanisms are in place o When persisted, the appropriate protection mechanisms are in place
to restrict access by unauthorized parties including to restrict access by unauthorized parties including
administrators or parties with access to backup data. administrators or parties with access to backup data.
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.
10. IANA Considerations 10. IANA Considerations
10.1. Registration of SCIM URN Sub-namespace & SCIM Registry 10.1. Registration of SCIM URN Sub-namespace & SCIM Registry
IANA is requested to add an entry to the 'IETF URN Sub-namespace for IANA is requested to add an entry to the 'IETF URN Sub-namespace for
Registered Protocol Parameter Identifiers' registry and create a sub- Registered Protocol Parameter Identifiers' registry and create a sub-
namespace for the Registered Parameter Identifier as per [RFC3553]: namespace for the Registered Parameter Identifier as per [RFC3553]:
"urn:ietf:params:scim". "urn:ietf:params:scim".
To manage this sub-namespace, IANA is requested to create the "SCIM" To manage this sub-namespace, IANA is requested to create the "SCIM"
skipping to change at page 83, line 40 skipping to change at page 86, line 27
SCIM Server Related Schema URIs SCIM Server Related Schema URIs
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-scim-api] [I-D.ietf-scim-api]
Hunt, P., Grizzle, K., Ansari, M., Wahlstroem, E., and C. Hunt, P., Grizzle, K., Ansari, M., Wahlstroem, E., and C.
Mortimore, "System for Cross-Domain Identity Management: Mortimore, "System for Cross-Domain Identity Management:
Protocol", draft-ietf-scim-api-16 (work in progress), Protocol", draft-ietf-scim-api-17 (work in progress),
March 2015. April 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, June 2003. Parameters", BCP 73, RFC 3553, June 2003.
skipping to change at page 85, line 16 skipping to change at page 88, line 5
Internet Assigned Numbers Authority, "IANA Time Zone Internet Assigned Numbers Authority, "IANA Time Zone
Database". Database".
[PortableContacts] [PortableContacts]
Smarr, J., "Portable Contacts 1.0 Draft C - Schema Only", Smarr, J., "Portable Contacts 1.0 Draft C - Schema Only",
August 2008. August 2008.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998. Languages", BCP 18, RFC 2277, January 1998.
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
(LDAP): The Protocol", RFC 4511, June 2006.
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Directory Information Models", RFC 4512, June (LDAP): Directory Information Models", RFC 4512, June
2006. 2006.
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
August 2011. August 2011.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
6749, October 2012. 6749, October 2012.
[RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0
Threat Model and Security Considerations", RFC 6819,
January 2013.
[XML-Schema] [XML-Schema]
Peterson, D., Gao, S., Malhotra, A., Sperberg-McQueen, C., Peterson, D., Gao, S., Malhotra, A., Sperberg-McQueen, C.,
and H. Thompson, "XML Schema Definition Language (XSD) 1.1 and H. Thompson, "XML Schema Definition Language (XSD) 1.1
Part 2: Datatypes", April 2012. Part 2: Datatypes", April 2012.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The editors would like to acknowledge the contribution and work of The editors would like to acknowledge the contribution and work of
the past draft editors: the past draft editors:
skipping to change at page 86, line 36 skipping to change at page 89, line 26
Draft 03 - PH - Revisions based on following tickets: Draft 03 - PH - Revisions based on following tickets:
09 - Attribute uniquenes 09 - Attribute uniquenes
10 - Returnability of attributes 10 - Returnability of attributes
35 - Attribute mutability (replaces readOnly) 35 - Attribute mutability (replaces readOnly)
52 - Minor textual changes 52 - Minor textual changes
53 - Standard use of term Client (some was consumer) 53 - Standard use of term client (some was consumer)
56 - Make manager attribute consistent with other $ref attrs 56 - Make manager attribute consistent with other $ref attrs
58 - Add optional id to ResourceType objects for consistency 58 - Add optional id to ResourceType objects for consistency
59 - Fix capitalization per IETF editor practices 59 - Fix capitalization per IETF editor practices
60 - Changed <eref> tags to normal <xref> and <reference> tags 60 - Changed <eref> tags to normal <xref> and <reference> tags
Draft 04 - PH - Revisions based on the following tickets: Draft 04 - PH - Revisions based on the following tickets:
skipping to change at page 90, line 5 skipping to change at page 92, line 39
Add references to SCIM API protocol document where appropriate Add references to SCIM API protocol document where appropriate
Added clarifications and privacy considerations to security Added clarifications and privacy considerations to security
considerations considerations
Clarified IANA section to create new "SCIM" registry Clarified IANA section to create new "SCIM" registry
Removed out-of-date "readOnly" attribute from Group schema Removed out-of-date "readOnly" attribute from Group schema
(replaced a long time ago by "mutability"). (replaced a long time ago by "mutability").
Draft 19 - PH - Comments from IESG review
Additional Gen-Art edits (type canonicalization, moved attribute
types section, etc
Added clarification on password use of clear text and hashing
Clarified statements about sensitive and PII data
Updated references to SCIM Protocol sections
Made capitalization of 'client' and 'service provider' terms
consistent (lower case)
Corrected schema and examples to have singluar value for manager
attribute
Authors' Addresses Authors' Addresses
Phil Hunt (editor) Phil Hunt (editor)
Oracle Corporation Oracle Corporation
Email: phil.hunt@yahoo.com Email: phil.hunt@yahoo.com
Kelly Grizzle Kelly Grizzle
SailPoint SailPoint
 End of changes. 79 change blocks. 
208 lines changed or deleted 322 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/