draft-ietf-scim-core-schema-05.txt   draft-ietf-scim-core-schema-06.txt 
Network Working Group K. Grizzle Network Working Group K. Grizzle
Internet-Draft SailPoint Internet-Draft SailPoint
Intended status: Standards Track P. Hunt, Ed. Intended status: Standards Track P. Hunt, Ed.
Expires: November 14, 2014 Oracle Expires: December 25, 2014 Oracle
E. Wahlstroem E. Wahlstroem
Technology Nexus Technology Nexus
C. Mortimore C. Mortimore
Salesforce Salesforce
May 13, 2014 June 23, 2014
System for Cross-Domain Identity Management: Core Schema System for Cross-Domain Identity Management: Core Schema
draft-ietf-scim-core-schema-05 draft-ietf-scim-core-schema-06
Abstract Abstract
The System for Cross-Domain Identity Management (SCIM) specification The System for Cross-Domain Identity Management (SCIM) specification
is designed to make managing user identity in cloud based is designed to make managing user identity in cloud based
applications and services easier. The specification suite builds applications and services easier. The specification suite builds
upon experience with existing schemas and deployments, placing upon experience with existing schemas and deployments, placing
specific emphasis on simplicity of development and integration, while specific emphasis on simplicity of development and integration, while
applying existing authentication, authorization, and privacy models. applying existing authentication, authorization, and privacy models.
Its intent is to reduce the cost and complexity of user management Its intent is to reduce the cost and complexity of user management
operations by providing a common user schema and extension model, as operations by providing a common user schema and extension model, as
well as binding documents to provide patterns for exchanging this well as binding documents to provide patterns for exchanging this
schema using standard protocols. In essence, make it fast, cheap, schema using standard protocols. In essence, make it fast, cheap,
and easy to move identity in to, out of, and around the cloud. and easy to move identity in to, out of, and around the cloud.
This document provides a platform neutral schema and extension model This document provides a platform neutral schema and extension model
for representing users and groups in JSON format. This schema is for representing users and groups in JSON format. This schema is
intended for exchange and use with cloud service providers. intended for exchange and use with cloud service providers. An HTTP
Additional binding documents provide a standard REST API, SAML protocol binding document is also provided.
binding, and use cases.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 November 14, 2014. This Internet-Draft will expire on December 25, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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. Requirements Notation and Conventions . . . . . . . . . . . . 3 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation and Conventions . . . . . . . . . . 4
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
3. SCIM Schema Structure . . . . . . . . . . . . . . . . . . . . 5 2. SCIM Schema Structure . . . . . . . . . . . . . . . . . . . . 5
3.1. Attribute Data Types . . . . . . . . . . . . . . . . . . 5 2.1. Attribute Data Types . . . . . . . . . . . . . . . . . . 5
3.1.1. String . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1. String . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.3. Decimal . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.3. Decimal . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.4. Integer . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.4. Integer . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.5. DateTime . . . . . . . . . . . . . . . . . . . . . . 6 2.1.5. DateTime . . . . . . . . . . . . . . . . . . . . . . 6
3.1.6. Binary . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.6. Binary . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.7. Reference . . . . . . . . . . . . . . . . . . . . . . 6 2.1.7. Reference . . . . . . . . . . . . . . . . . . . . . . 7
3.1.8. Complex . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.8. Complex . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Multi-valued Attributes . . . . . . . . . . . . . . . . . 7 2.2. Multi-valued Attributes . . . . . . . . . . . . . . . . . 7
4. Schema Extension Model . . . . . . . . . . . . . . . . . . . 8 3. Schema Extension Model . . . . . . . . . . . . . . . . . . . 8
5. SCIM Core Schema . . . . . . . . . . . . . . . . . . . . . . 8 4. SCIM Core Schema . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Common Schema Attributes . . . . . . . . . . . . . . . . 8 4.1. Common Schema Attributes . . . . . . . . . . . . . . . . 9
5.2. "schemas" Attribute . . . . . . . . . . . . . . . . . . . 9 4.2. "schemas" Attribute . . . . . . . . . . . . . . . . . . . 10
6. SCIM User Schema . . . . . . . . . . . . . . . . . . . . . . 10 5. SCIM User Schema . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Singular Attributes . . . . . . . . . . . . . . . . . . . 10 5.1. Singular Attributes . . . . . . . . . . . . . . . . . . . 10
6.2. Multi-valued Attributes . . . . . . . . . . . . . . . . . 12 5.2. Multi-valued Attributes . . . . . . . . . . . . . . . . . 13
7. SCIM Enterprise User Schema Extension . . . . . . . . . . . . 15 6. SCIM Enterprise User Schema Extension . . . . . . . . . . . . 15
8. SCIM Group Schema . . . . . . . . . . . . . . . . . . . . . . 15 7. SCIM Group Schema . . . . . . . . . . . . . . . . . . . . . . 16
9. Service Provider Configuration Schema . . . . . . . . . . . . 16 8. Service Provider Configuration Schema . . . . . . . . . . . . 16
10. ResourceType Schema . . . . . . . . . . . . . . . . . . . . . 18 9. ResourceType Schema . . . . . . . . . . . . . . . . . . . . . 18
11. Schema Schema . . . . . . . . . . . . . . . . . . . . . . . . 19 10. Schema Schema . . . . . . . . . . . . . . . . . . . . . . . . 19
12. JSON Representation . . . . . . . . . . . . . . . . . . . . . 23 11. JSON Representation . . . . . . . . . . . . . . . . . . . . . 23
12.1. Minimal User Representation . . . . . . . . . . . . . . 23 11.1. Minimal User Representation . . . . . . . . . . . . . . 23
12.2. Full User Representation . . . . . . . . . . . . . . . . 24 11.2. Full User Representation . . . . . . . . . . . . . . . . 24
12.3. Enterprise User Extension Representation . . . . . . . . 26 11.3. Enterprise User Extension Representation . . . . . . . . 27
12.4. Group Representation . . . . . . . . . . . . . . . . . . 29 11.4. Group Representation . . . . . . . . . . . . . . . . . . 30
12.5. Service Provider Configuration Representation . . . . . 30 11.5. Service Provider Configuration Representation . . . . . 31
12.6. Resource Type Representation . . . . . . . . . . . . . . 31 11.6. Resource Type Representation . . . . . . . . . . . . . . 32
12.7. Schema Representation . . . . . . . . . . . . . . . . . 32 11.7. Schema Representation . . . . . . . . . . . . . . . . . 32
13. Security Considerations . . . . . . . . . . . . . . . . . . . 54 12. Security Considerations . . . . . . . . . . . . . . . . . . . 54
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
14.1. Registering New SCIM Schemas . . . . . . . . . . . . . . 54 13.1. URN Sub-Namespace for SCIM . . . . . . . . . . . . . . . 54
14.1.1. Registration Procedure . . . . . . . . . . . . . . . 54 13.1.1. Specification Template . . . . . . . . . . . . . . . 55
14.1.2. Schema Registration Template . . . . . . . . . . . . 55 13.1.2. Pre-Registered SCIM Schema Identifiers . . . . . . . 57
14.2. Initial SCIM Schema Registry . . . . . . . . . . . . . . 55 13.2. Registering SCIM Schemas . . . . . . . . . . . . . . . . 57
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 13.2.1. Registration Procedure . . . . . . . . . . . . . . . 57
15.1. Normative References . . . . . . . . . . . . . . . . . . 56 13.2.2. Schema Registration Template . . . . . . . . . . . . 58
15.2. Informative References . . . . . . . . . . . . . . . . . 57 13.3. Initial SCIM Schema Registry . . . . . . . . . . . . . . 59
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 58 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 59
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 58 14.1. Normative References . . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 14.2. Informative References . . . . . . . . . . . . . . . . . 60
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 61
1. Requirements Notation and Conventions Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] .
Throughout this document, values are quoted to indicate that they are
to be taken literally. When using these values in protocol messages,
the quotes MUST NOT be used as part of the value.
2. 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-standard APIs for As a result, many cloud providers implement non-standard APIs for
managing users within their services. This increases both the cost managing users within their services. This increases both the cost
and complexity associated with organizations adopting products and and complexity associated with organizations adopting products and
services from multiple cloud providers as they must perform redundant services from multiple cloud providers as they must perform redundant
integration development. Similarly, cloud services providers seeking integration development. Similarly, cloud services providers seeking
to interoperate with multiple application marketplaces or cloud to inter-operate with multiple application marketplaces or cloud
identity providers must be redundantly integrated. identity providers must be redundantly integrated.
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 binding documents to provide patterns for model, as well as binding documents to provide patterns for
exchanging this schema via a REST API. It draws inspiration and best exchanging this schema via an HTTP API. It draws inspiration and
practice, building upon existing user APIs and schemas from a wide best practice, building upon existing user APIs and schemas from a
variety of sources including, but not limited to, existing APIs wide variety of sources including, but not limited to, existing APIs
exposed by cloud providers, PortableContacts, and LDAP directory exposed by cloud providers, PortableContacts, vCards, and LDAP
services. directory services.
This document provides a platform neutral schema and extension model This document provides a JSON based schema and extension model for
for representing users and groups in JSON format. This schema is representing users and groups, as well as service provider
intended for exchange and use with cloud service providers. configuration. This schema is intended for exchange and use with
Additional binding documents provide a standard REST API, SAML cloud service providers and other cross-domain scenarios. An HTTP
binding, and use cases. protocol binding document is provided separately.
2.1. Definitions 1.1. Requirements Notation and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Throughout this document, values are quoted to indicate that they are
to be taken literally. When using these values in protocol messages,
the quotes MUST NOT be used as part of the value.
1.2. Definitions
Service Provider: An HTTP web application that provides identity Service Provider: An HTTP web application that provides identity
information via the SCIM protocol. information via the SCIM protocol.
Client: A website or application that uses the SCIM protocol to Client: A website or application that uses the SCIM protocol to
manage identity data maintained by the service provider. The manage identity data maintained by the service provider. The
client initiates SCIM HTTP requests to a target service provider. client initiates SCIM HTTP requests to a target service provider.
Resource: The service provider managed artifact containing one or Resource: The service provider managed artifact containing one or
more attributes; e.g., "User" or "Group". more attributes; e.g., "User" or "Group".
skipping to change at page 5, line 5 skipping to change at page 5, line 8
Simple Attribute: A singular or multi-valued attribute whose value Simple Attribute: A singular or multi-valued attribute whose value
is a primitive; e.g., "String". is a primitive; e.g., "String".
Complex Attribute: A singular or multi-valued attribute whose value Complex Attribute: A singular or multi-valued attribute whose value
is a composition of one or more simple attributes; e.g., is a composition of one or more simple attributes; e.g.,
"addresses". "addresses".
Sub-Attribute: A simple attribute contained within a complex Sub-Attribute: A simple attribute contained within a complex
attribute. attribute.
3. SCIM Schema Structure 2. SCIM Schema Structure
SCIM schema provides a minimal core schema for representing users and SCIM schema provides a minimal core schema for representing users and
groups (resources), encompassing common attributes found in many groups (resources), encompassing common attributes found in many
existing deployments and schemas. existing deployments and schemas.
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
at least one simple or complex value either of which may be multi- at least one simple or complex value either of which may be multi-
valued. SCIM schema defines the data type, plurality and other valued. SCIM schema defines the data type, plurality and other
distinguishing features of an attribute. Unless otherwise specified distinguishing features of an attribute. Unless otherwise specified
all attributes are modifiable by consumers. all attributes are modifiable by consumers.
Attribute names SHOULD be camelCased. SCIM resources are represented Attribute names SHOULD be camelCased. SCIM resources are represented
in JSON [RFC7159] and MUST specify schema via the "schemas" attribute in JSON [RFC7159] and MUST specify schema via the "schemas" attribute
per Section 5.2. per Section 4.2.
Attribute names MUST conform to the following ABNF [RFC5234] rules: Attribute names MUST conform to the following ABNF [RFC5234] rules:
ATTRNAME = ALPHA *(nameChar) ATTRNAME = ALPHA *(nameChar)
nameChar = "-" / "_" / DIGIT / ALPHA nameChar = "-" / "_" / DIGIT / ALPHA
Figure 1 Figure 1: ABNF for Attribute Names
3.1. Attribute Data Types 2.1. Attribute Data Types
Attribute data types are derived from JSON [RFC7159] and unless Attribute data types are derived from JSON [RFC7159] and unless
otherwise specified have the following characteristics (see otherwise specified have the following characteristics (see
Section 11 for attribute characteristic definitions): Section 10 for attribute characteristic definitions):
are optional ("required=false"). are optional (is not required).
are case insensitive ("caseExact=false"), are case insensitive (caseExact=false),
are modifiable ("mutability=readWrite"), are modifiable (mutability is readWrite),
are returned in response to queries ("returned=default"), are returned in response to queries (returned by default),
are not unique ("uniqueness=none"), and, are not unique (uniqueness=none), and,
of type String (Section 3.1.1). of type String (Section 2.1.1).
The JSON format defines a limited set of data types, hence, where The JSON format defines a limited set of data types, hence, where
appropriate, alternate JSON representations derived from XML Schema appropriate, alternate JSON representations derived from XML Schema
[XML-Schema] are defined below. SCIM extensions SHOULD NOT introduce [XML-Schema] are defined below. SCIM extensions SHOULD NOT introduce
new data types. new data types.
3.1.1. String 2.1.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 canonical values are specified service providers Additionally, when canonical values are specified service providers
SHOULD conform to those values if appropriate, but MAY provide SHOULD conform to those values if appropriate, but MAY provide
alternate "String" values to represent additional values. alternate "String" values to represent additional values.
3.1.2. Boolean 2.1.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] . Section 3 [RFC7159].
3.1.3. Decimal 2.1.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] . period. The JSON format is defined in Section 6 [RFC7159].
3.1.4. Integer 2.1.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. the value MUST NOT contain fractional or exponent parts.
3.1.5. DateTime 2.1.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.2.7 MUST be encoded as a valid xsd:dateTime as specified in Section 3.2.7
[XML-Schema] . [XML-Schema].
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].
3.1.6. Binary 2.1.6. Binary
Arbitrary binary data. The attribute value MUST be encoded as a Arbitrary binary data. The attribute value MUST be encoded as a
valid xsd:base64Binary as specified in Section 3.2.16 [XML-Schema] . valid xsd:base64Binary as specified in Section 3.2.16 [XML-Schema].
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 perSection 2.7 [RFC7159]. and are represented as a JSON String per Section 2.7 [RFC7159].
3.1.7. Reference 2.1.7. Reference
A reference to a SCIM resource. The value MUST be the absolute or A reference to a SCIM resource. 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]. The base URI for resolved as specified in Section 5.2 [RFC3986]. The base URI for
relative URI resolution MUST include all URI components and path relative URI resolution MUST include all URI components and path
segments up to but not including the Endpoint URI; e.g., the base URI segments up to but not including the Endpoint URI; e.g., the base URI
for a request to "https://example.com/v2/Users/2819c223-7f76-453a- for a request to "https://example.com/v2/Users/2819c223-7f76-453a-
919d-413861904646" would be "https://example.com/v2/" and the 919d-413861904646" would be "https://example.com/v2/" and the
relative URI for this resource would be "Users/2819c223-7f76-453a- relative URI for this resource would be "Users/2819c223-7f76-453a-
919d-413861904646". 919d-413861904646".
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 MAY optionally choose to enforce referential integrity for
references. references.
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.
3.1.8. Complex 2.1.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] . Section 4 [RFC7159].
3.2. Multi-valued Attributes 2.2. Multi-valued Attributes
Multi-valued attributes are unordered lists of attributes. Each Multi-valued attributes are unordered lists of attributes. Each
attribute MAY contain Sub-Attributes and therefore multi-valued attribute MAY contain Sub-Attributes and therefore multi-valued
attributes may contain complex attributes. The sub-attributes below attributes may contain complex attributes. The sub-attributes below
are considered normative and when specified SHOULD be used as are considered normative and when specified SHOULD be used as
defined. defined.
type A label indicating the attribute's function; e.g., "work" or type A label indicating the attribute's function; e.g., "work" or
"home". "home".
skipping to change at page 8, line 16 skipping to change at page 8, line 23
reference. reference.
When returning multi-valued attributes, service providers SHOULD When returning multi-valued attributes, service providers SHOULD
canonicalize the value returned, if appropriate (e.g. for e-mail canonicalize the value returned, if appropriate (e.g. for e-mail
addresses and URLs). Service providers MAY return the same value addresses and URLs). Service providers MAY return the same value
more than once with different types (e.g. the same e-mail address may more than once with different types (e.g. the same e-mail address may
used for work and home), but SHOULD NOT return the same (type, value) used for work and home), but SHOULD NOT return the same (type, value)
combination more than once per Attribute, as this complicates combination more than once per Attribute, as this complicates
processing by the Consumer. processing by the Consumer.
4. Schema Extension Model 3. Schema Extension Model
SCIM schema follows an object extension model similar to SCIM schema follows an object extension model similar to
ObjectClasses used in LDAP. Unlike LDAP there is no inheritance ObjectClasses used in LDAP. Unlike LDAP there is no inheritance
model; all extensions are additive (similar to LDAP Auxiliary Object model; all extensions are additive (similar to LDAP Auxiliary Object
Class [RFC4512]). Each value indicates additive schema that may Class [RFC4512] ). Each "schemas" value indicates additive schema
exist in a SCIM representation as specified by extensions not defined that may exist in a SCIM resource representation. The "schemas"
in this suite. Schema extensions MUST NOT redefine any attributes attribute MUST contain at least one value which SHALL be the base
defined in this specification and SHOULD follow conventions defined schema for the resource. The "schemas" attribute MAY contain
in this specification. Each schema extension must identify a URI additional values indicating extended schemas that are in use.
used to identify the extension. The JSON format MUST use the Schema extensions SHOULD NOT redefine any attributes defined in this
"schemas" attributeSection 5.2 to distinguish extended resources and specification and SHOULD follow conventions defined in this
attributes. specification. Except for the base object schema, the schema
extension URI SHALL be used as a JSON container to distinguish
attributes belonging to the extension namespace from base schema
attributes. See Figure 4 for an example JSON representation of an
extended User.
5. SCIM Core Schema In order to determine which "schemas" URI value is 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" schema ( Section 9 ). See example "ResourceType"
representation in Figure 7.
5.1. Common Schema Attributes 4. SCIM Core Schema
4.1. Common Schema Attributes
Each SCIM resource (Users, Groups, etc.) includes the below common Each SCIM resource (Users, Groups, etc.) includes the following
attributes. These attributes MUST be included in all resources, common attributes. These attributes MUST be included in all
including any extended resource types. It is not necessary to resources, including any extended resource types. Common attributes
specify the schemas attribute if the resource is fully defined in are considered to be part of every base resource schema and do not
this document as the core schema is implicitly included. use their own schemas URI and SHALL not be considered schema
extensions.
id Unique identifier for the SCIM resource as defined by the service id 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 empty "id" value. This identifier MUST be unique across the
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
never be specified by the client. bulkId: is a reserved keyword NOT be specified by the client. The string "bullkId" is a
and MUST NOT be used in the unique identifier. REQUIRED and has a reserved keyword and MUST NOT be used within any unique identifier
mutability of "readOnly". value. REQUIRED and has a mutability of "readOnly".
externalId An identifier for the resource as defined by the client. externalId An identifier for the resource as defined by the client.
The "externalId" may simplify identification of the resource The "externalId" may simplify identification of the resource
between client and service provider by allowing the client to between client and service provider by allowing the client to use
refer to the resource with its own identifier, obviating the need a filter to locate the resource with its own identifier, obviating
to store a local mapping between the local identifier of the the need to store a local mapping between the local identifier of
resource and the identifier used by the service provider. Each the resource and the identifier used by the service provider.
resource MAY include a non-empty externalId value. The value of Each resource MAY include a non-empty externalId value. The value
the "externalId" attribute is always issued by the client and can of the "externalId" attribute is always issued by the client and
never be specified by the service provider. The service provider can never be specified by the service provider. The service
MUST always interpret the externalId as scoped to the client's provider MUST always interpret the externalId as scoped to the
tenant. client's tenant.
meta A complex attribute containing resource metadata. All sub- meta A complex attribute containing resource metadata. All sub-
attributes are OPTIONAL attributes are OPTIONAL
resourceType The name of the resource type of the resource. resourceType The name of the resource type of the resource. This
Attribute has mutability of "readOnly". attribute has mutability of "readOnly".
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. Attribute has provider. The attribute MUST be a DateTime. This attribute
mutability of "readOnly". has mutability of "readOnly".
lastModified The most recent DateTime the details of this lastModified The most recent DateTime the details of this
resource were updated at the service provider. If this resource were updated at the service provider. If this
resource has never been modified since its initial creation, resource has never been modified since its initial creation,
the value MUST be the same as the value of created. The the value MUST be the same as the value of created. The
attribute MUST be a DateTime. Attribute has mutability of attribute MUST be a DateTime and has mutability of "readOnly".
"readOnly".
location The URI of the resource being returned. This value MUST location The URI of the resource being returned. This value MUST
be the same as the Location HTTP response header. Attribute be the same as the Location HTTP response header. The
has mutability of "readOnly". attribute has mutability of "readOnly".
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. Attribute must be the same as the ETag HTTP response header. The
has mutability of "readOnly". attribute has mutability of "readOnly".
attributes The names of the attributes to remove from the
resource during a PATCH operation.
5.2. "schemas" Attribute 4.2. "schemas" Attribute
SCIM supports resources of different types, with extensible schemas. SCIM supports resources of different types, with extensible schemas.
Each resource MUST be indicated using fully qualified URLs. Each resource MUST be indicated using fully qualified URLs.
A "schemas" attribute is used to indicate the version of SCIM schema A "schemas" attribute contains URIs which are used to indicate the
as well as any schema extensions. namespace and version of SCIM schema as well as any schema
extensions. The first value SHALL indicate the base schema for the
resource.
schemas The schemas attribute is an array of strings which allows schemas The schemas attribute is an array of Strings which allows
introspection of the supported schema version for a SCIM introspection of the supported schema version for a SCIM
representation as well any schema extensions supported by that representation as well any schema extensions supported by that
representation. Each String value must be a unique URI. This representation. Each String value must be a unique URI. This
specification defines URIs for User, Group, and a standard specification defines URIs for User, Group, and a standard
enterprise-user extension. All representations of SCIM schema enterprise-user extension. All representations of SCIM schema
MUST include a non-zero value array with value(s) of the URIs MUST include a non-zero value array with value(s) of the URIs
supported by that representation. The schemas attribute for a supported by that representation. The schemas attribute for a
resource MUST only contain values defined as "schema" and resource MUST only contain values defined as "schema" and
"schemaExtensions" for the resource's resource type. Duplicate "schemaExtensions" for the resource's resource type. Duplicate
values MUST NOT be included. Value order is not specified and values MUST NOT be included. Value order is not specified and
MUST not impact behavior. REQUIRED. MUST not impact behavior. REQUIRED.
6. SCIM User Schema 5. SCIM User Schema
SCIM provides a schema for representing Users, identified using the SCIM provides a schema for representing Users, identified using the
following URI: "urn:scim:schemas:core:2.0:User". The following following URI: "urn:scim:schemas:core:2.0:User". The following
attributes are defined in addition to those attributes defined in attributes are defined in addition to those attributes defined in
SCIM Core Schema: SCIM Core Schema:
6.1. Singular Attributes 5.1. Singular Attributes
userName Unique identifier for the user, typically used by the user userName Unique identifier for the user, typically used by the user
to directly authenticate to the service provider. Often displayed to directly authenticate to the service provider. Often displayed
to the user as their unique identifier within the system (as to the user as their unique identifier within the system (as
opposed to id or externalId, which are generally opaque and not opposed to id or externalId, which are generally opaque and not
user-friendly identifiers). Each User MUST include a non-empty user-friendly identifiers). Each User MUST include a non-empty
userName value. This identifier MUST be unique across the userName value. This identifier MUST be unique across the
client's entire set of Users. RECOMMENDED. client's entire set of Users. RECOMMENDED.
name The components of the user's real name. Service providers MAY name The components of the user's real name. Service providers MAY
return just the full name as a single string in the formatted sub- return just the full name as a single string in the formatted sub-
attribute, or they MAY return just the individual component attribute, or they MAY return just the individual component
attributes using the other sub-attributes, or they MAY return attributes using the other sub-attributes, or they MAY return
both. If both variants are returned, they SHOULD be describing both. If both variants are returned, they SHOULD be describing
the same name, with the formatted name indicating how the the same name, with the formatted name indicating how the
component attributes should be combined. component attributes should be combined.
formatted The full name, including all middle names, titles, and formatted The full name, including all middle names, titles, and
suffixes as appropriate, formatted for display (e.g. "Ms. suffixes as appropriate, formatted for display (e.g. "Ms.
Barbara Jane Jensen, III."). Barbara Jane Jensen, III." ).
familyName The family name of the User, or last name in most familyName The family name of the User, or last name in most
Western languages (e.g. "Jensen" given the full name "Ms. Western languages (e.g. "Jensen" given the full name "Ms.
Barbara Jane Jensen, III."). Barbara Jane Jensen, III." ).
givenName The given name of the User, or first name in most givenName The given name of the User, or first name in most
Western languages (e.g. "Barbara" given the full name "Ms. Western languages (e.g. "Barbara" given the full name "Ms.
Barbara Jane Jensen, III."). Barbara Jane Jensen, III." ).
middleName The middle name(s) of the User (e.g. "Jane" given the middleName The middle name(s) of the User (e.g. "Jane" given the
full name "Ms. Barbara Jane Jensen, III."). full name "Ms. Barbara Jane Jensen, III." ).
honorificPrefix The honorific prefix(es) of the User, or title in honorificPrefix The honorific prefix(es) of the User, or title in
most Western languages (e.g. "Ms." given the full name "Ms. most Western languages (e.g. "Ms." given the full name "Ms.
Barbara Jane Jensen, III."). Barbara Jane Jensen, III." ).
honorificSuffix The honorific suffix(es) of the User, or suffix honorificSuffix The honorific suffix(es) of the User, or suffix
in most Western languages (e.g. "III." given the full name "Ms. in most Western languages (e.g. "III." given the full name
Barbara Jane Jensen, III."). "Ms. Barbara Jane Jensen, III." ).
displayName The name of the user, suitable for display to end-users. displayName The name of the user, suitable for display to end-users.
Each user returned MAY include a non-empty displayName value. The Each user returned MAY include a non-empty displayName value. The
name SHOULD be the full name of the User being described if known name 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 a (e.g. "Babs Jensen" or "Ms. Barbara J Jensen, III" ), but MAY be
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 The casual way to address the user in real life, e.g. "Bob" nickName The casual way to address the user in real life, e.g.
or "Bobby" instead of "Robert". This attribute SHOULD NOT be used "Bob" or "Bobby" instead of "Robert". This attribute SHOULD NOT
to represent a User's username (e.g. bjensen or mpepperidge). be used to represent a User's username (e.g. bjensen or
mpepperidge).
profileUrl A fully qualified URL to a page representing the user's profileUrl A fully qualified URL to a page representing the user's
online profile. online profile.
title The user's title, such as "Vice President". title The user's title, such as "Vice President".
userType Used to identify the organization to user relationship. userType Used to identify the organization to user relationship.
Typical values used might be "Contractor", "Employee", "Intern", Typical values used might be "Contractor", "Employee", "Intern",
"Temp", "External", and "Unknown" but any value may be used. "Temp", "External", and "Unknown" but any value may be used.
preferredLanguage Indicates the user's preferred written or spoken preferredLanguage Indicates the user's preferred written or spoken
languages and is generally used for selecting a localized User languages and is generally used for selecting a localized User
interface. The value indicates the set of natural languages that interface. The value indicates the set of natural languages that
are preferred. The format of the value is same as the Accept- are preferred. The format of the value is same as the Accept-
Language header field (not including "Accept-Language:") of HTTP Language header field (not including "Accept-Language:") of HTTP
and is specified in Section 5.3.5 of and is specified in Section 5.3.5 of [RFC7231]. The intent of
[I-D.ietf-httpbis-p2-semantics]. The intent of this value is to this value is to enable cloud applications to perform matching of
enable cloud applications to perform matching of language tags language tags [RFC4647] to the user's language preferences
[RFC4647] to the user's language preferences regardless of what regardless of what may be indicated by a user agent (which might
may be indicated by a user agent (which might be shared), or in a be shared), or in a non-user present interaction (such as in a
non-user present interaction (such as in a delegated OAuth2 delegated OAuth2 [RFC6749] style interaction) where normal HTTP
[RFC6749] style interaction) where normal HTTP Accept-Language Accept-Language header negotiation cannot take place.
header negotiation cannot take place.
locale Used to indicate the User's default location for purposes of locale Used to indicate the User's default location for purposes of
localizing items such as currency, date time format, numerical localizing items such as currency, date time format, numerical
representations, etc. A valid value is a language tag as defined representations, etc. A valid value is a language tag as defined
in [RFC5646]. Computer languages are explicitly excluded. in [RFC5646]. Computer languages are explicitly excluded.
A language tag is a sequence of one or more case-insensitive sub- A language tag is a sequence of one or more case-insensitive sub-
tags, each separated by a hyphen character ("-", %x2D). For tags, each separated by a hyphen character ("-", %x2D). For
backwards compatibility reasons, servers MAY accept tags separated backwards compatibility reasons, servers MAY accept tags separated
by an underscore character ("_", %5F). In most cases, a language by an underscore character ("_", %5F). In most cases, a language
skipping to change at page 12, line 26 skipping to change at page 12, line 45
optionally followed by a series of sub-tags that refine or narrow optionally followed by a series of sub-tags that refine or narrow
that language's range (e.g., "en-CA" = the variety of English as that language's range (e.g., "en-CA" = the variety of English as
communicated in Canada). Whitespace is not allowed within a communicated in Canada). Whitespace is not allowed within a
language tag. Example tags include: language tag. Example tags include:
fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
See [RFC5646] for further information. See [RFC5646] for further information.
timezone The User's time zone in IANA Time Zone database format timezone The User's time zone in IANA Time Zone database format
[RFC6557], also known as "Olson" timezone database [RFC6557], also known as "Olson" timezone database format
format[Olson-TZ]; For example: "America/Los_Angeles". [Olson-TZ] ; For example: "America/Los_Angeles".
active A Boolean value indicating the user's administrative status. active A Boolean value indicating the user's administrative status.
The definitive meaning of this attribute is determined by the The definitive meaning of this attribute is determined by the
service provider. As a typical example, a value of true infers service provider. As a typical example, a value of true infers
the user is able to login while a value of false implies the the user is able to login while a value of false implies the
user's account has been suspended. user's account has been suspended.
password The user's clear text password. This attribute is intended password The user's clear text password. This attribute is intended
to be used as a means to specify an initial password when creating to be used as a means to specify an initial password when creating
a new User or to reset an existing User's password. Password a new User or to reset an existing User's password. Password
policies and the ability to update or set passwords are out of policies and the ability to update or set passwords are out of
scope of this document. The mutability of this attribute is scope of this document. The mutability of this attribute is
"writeOnly" indicating the value MUST NOT be returned by a service "writeOnly" indicating the value MUST NOT be returned by a service
provider in any form. provider in any form.
6.2. Multi-valued Attributes 5.2. Multi-valued Attributes
The following multi-valued attributes are defined. The following multi-valued attributes are defined.
emails E-mail addresses for the User. The value SHOULD be emails E-mail addresses for the User. The value SHOULD be
canonicalized by the service provider, e.g. "bjensen@example.com" canonicalized by the service provider, e.g. "bjensen@example.com"
instead of "bjensen@EXAMPLE.COM". Canonical type values of instead of "bjensen@EXAMPLE.COM". Canonical type values of
"work", "home", and "other". "work", "home", and "other".
phoneNumbers Phone numbers for the user. The value SHOULD be phoneNumbers Phone numbers for the user. The value SHOULD be
canonicalized by the service provider according to format in canonicalized by the service provider according to format in
skipping to change at page 13, line 52 skipping to change at page 14, line 20
extended street address information. This attribute MAY extended street address information. This attribute MAY
contain newlines. contain newlines.
locality The city or locality component. locality The city or locality component.
region The state or region component. region The state or region component.
postalCode The zipcode or postal code component. postalCode The zipcode or postal code component.
country The country name component. When specified the value country The country name component. When specified the value
MUST be in ISO 3166-1 alpha 2 "short" code format[ISO3166]; MUST be in ISO 3166-1 alpha 2 "short" code format [ISO3166] ;
e.g., the United States and Sweden are "US" and "SE", e.g., the United States and Sweden are "US" and "SE",
respectively. respectively.
groups A list of groups that the user belongs to, either thorough groups A list of groups that the user belongs to, either thorough
direct membership, nested groups, or dynamically calculated. The direct membership, nested groups, or dynamically calculated. The
values are meant to enable expression of common group or role values are meant to enable expression of common group or role
based access control models, although no explicit authorization based access control models, although no explicit authorization
model is defined. It is intended that the semantics of group model is defined. It is intended that the semantics of group
membership and any behavior or authorization granted as a result membership and any behavior or authorization granted as a result
of membership are defined by the service provider. The canonical of membership are defined by the service provider. The canonical
skipping to change at page 14, line 27 skipping to change at page 14, line 44
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 8). The attribute has a via the Group Resource (Section 7). The attribute has a
mutability of "readOnly". mutability of "readOnly".
entitlements A list of entitlements for the user that represent a entitlements A list of entitlements for the user that represent a
thing the user has. An entitlement MAY be an additional right to thing the user has. An entitlement MAY be an additional right to
a thing, object, or service. No vocabulary or syntax is specified a thing, object, or service. No vocabulary or syntax is specified
and service providers and clients are expected to encode and service providers and clients are expected to encode
sufficient information in the value so as to accurately and sufficient information in the value so as to accurately and
without ambiguity determine what the user has access to. This without ambiguity determine what the user has access to. This
value has NO canonical types though type may be useful as a means value has NO canonical types though type may be useful as a means
to scope entitlements. to scope entitlements.
roles A list of roles for the user that collectively represent who roles A list of roles for the user that collectively represent who
the user is; e.g., "Student, Faculty". No vocabulary or syntax is the user is; e.g., "Student, Faculty". No vocabulary or syntax is
specified though it is expected that a role value is a String or specified though it is expected that a role value is a String or
label representing a collection of entitlements. This value has label representing a collection of entitlements. This value has
NO canonical types. NO canonical types.
x509Certificates A list of certificates issued to the User. Values x509Certificates A list of certificates issued to the User. Values
are Binary (Section 3.1.6) and DER encoded x509. This value has are Binary (Section 2.1.6) and DER encoded x509. This value has
NO canonical types. NO canonical types.
7. SCIM Enterprise User Schema Extension 6. SCIM 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
following schema URI: following schema URI:
"urn:scim:schemas:extension:enterprise:2.0:EnterpriseUser". "urn:scim:schemas:extension:enterprise:2.0:User".
The following Singular Attributes are defined: The following Singular Attributes are defined:
employeeNumber Numeric or alphanumeric identifier assigned to a employeeNumber Numeric or alphanumeric identifier assigned to a
person, typically based on order of hire or association with an person, typically based on order of hire or association with an
organization. organization.
costCenter Identifies the name of a cost center. costCenter Identifies the name of a cost center.
organization Identifies the name of an organization. organization Identifies the name of an organization.
skipping to change at page 15, line 40 skipping to change at page 16, line 5
value The "id" of the SCIM resource representing the user's value The "id" of the SCIM resource representing the user's
manager. RECOMMENDED. manager. RECOMMENDED.
$ref The URI of the SCIM resource representing the User's $ref The URI of the SCIM resource representing the User's
manager. RECOMMENDED. manager. RECOMMENDED.
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".
8. SCIM Group Schema 7. SCIM Group Schema
SCIM provides a schema for representing groups, identified using the SCIM provides a schema for representing groups, identified using the
following schema URI: "urn:scim:schemas:core:2.0:Group". following schema URI: "urn:scim:schemas:core:2.0:Group".
Group resources are meant to enable expression of common group or Group resources are meant to enable expression of common group or
role based access control models, although no explicit authorization role based access control models, although no explicit authorization
model is defined. It is intended that the semantics of group model is defined. It is intended that the semantics of group
membership and any behavior or authorization granted as a result of membership and any behavior or authorization granted as a result of
membership are defined by the service provider are considered out of membership are defined by the service provider are considered out of
scope for this specification. scope for this specification.
skipping to change at page 16, line 23 skipping to change at page 16, line 35
members A list of members of the Group. While values MAY be added members A list of members of the Group. While values MAY be added
or removed, sub-attributes of members are "immutable". The or removed, sub-attributes of members are "immutable". The
"value" sub-attribute must be the "id" and the "$ref" sub- "value" sub-attribute must be the "id" and the "$ref" sub-
attribute must be the URI of a SCIM resource, either a "User", or attribute must be the URI of a SCIM resource, either a "User", or
a "Group". The intention of the "Group" type is to allow the a "Group". The intention of the "Group" type is to allow the
service provider to support nested groups. Service providers MAY service provider to support nested groups. Service providers MAY
require clients to provide a non-empty members value based on the require clients to provide a non-empty members value based on the
"required" sub attribute of the "members" attribute in the "Group" "required" sub attribute of the "members" attribute in the "Group"
resource schema. resource schema.
9. Service Provider Configuration Schema 8. 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:scim:schemas:core:2.0:ServiceProviderConfig" "urn:scim:schemas:core:2.0:ServiceProviderConfig"
The service provider configuration resource enables a service The service provider configuration resource enables a service
provider to discovery of SCIM specification features in a provider to discovery of SCIM specification features in a
standardized form as well as provide additional implementation standardized form as well as provide additional implementation
details to clients. All attributes are READ-ONLY (a mutability of details to clients. All attributes are READ-ONLY (a mutability of
"readOnly"). Unlike other core resources, the "id" attribute is not "readOnly" ). Unlike other core resources, the "id" attribute is not
required for the service provider configuration resource. required for the service 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 An HTTP addressable URL pointing to the service documentationUrl An HTTP addressable URL pointing to the service
provider's human consumable help documentation. provider's human consumable help documentation.
patch A complex type that specifies PATCH configuration options. patch A complex type that specifies PATCH configuration options.
REQUIRED. REQUIRED.
skipping to change at page 18, line 14 skipping to change at page 18, line 26
description A description of the Authentication Scheme. description A description of the Authentication Scheme.
REQUIRED. REQUIRED.
specUrl A HTTP addressable URL pointing to the Authentication specUrl A HTTP addressable URL pointing to the Authentication
Scheme's specification. OPTIONAL. Scheme's specification. OPTIONAL.
documentationUrl A HTTP addressable URL pointing to the documentationUrl A HTTP addressable URL pointing to the
Authentication Scheme's usage documentation. OPTIONAL. Authentication Scheme's usage documentation. OPTIONAL.
10. ResourceType Schema 9. ResourceType Schema
The "ResourceType" schema specifies the meta-data about a resource The "ResourceType" schema specifies the meta-data about a resource
type. Resource type resources are READ-ONLY and identified using the type. Resource type resources are READ-ONLY and identified using the
following schema URI: "urn:scim:schemas:core:2.0:ResourceType". following schema URI: "urn:scim:schemas:core:2.0:ResourceType".
Unlike other core resources, all attributes are REQUIRED unless Unlike other core resources, all attributes are REQUIRED unless
otherwise specified. The "id" attribute is not required for the otherwise specified. The "id" attribute is not required for the
resource type resource. resource type resource.
The following Singular Attributes are defined: The following Singular Attributes are defined:
skipping to change at page 19, line 9 skipping to change at page 19, line 23
This MUST be equal to the "id" attribute of a "Schema" This MUST be equal to the "id" attribute of a "Schema"
resource. REQUIRED. resource. REQUIRED.
required A Boolean value that specifies whether the schema required A Boolean value that specifies whether the schema
extension is required for the resource type. If true, a extension is required for the resource type. If true, a
resource of this type MUST include this schema extension and resource of this type MUST include this schema extension and
include any attributes declared as required in this schema include any attributes declared as required in this schema
extension. If false, a resource of this type MAY omit this extension. If false, a resource of this type MAY omit this
schema extension. REQUIRED. schema extension. REQUIRED.
11. Schema Schema 10. Schema Schema
The "Schema" schema specifies the attribute(s) and meta-data that The "Schema" schema specifies the attribute(s) and meta-data that
constitute a "Schema" resource. Schema resources have mutability of constitute a "Schema" resource. Schema resources have mutability of
"readOnly" and identified using the following URI: "readOnly" and identified using the following URI:
"urn:scim:schemas:core:2.0:Schema". Unlike other core resources the "urn:scim:schemas:core:2.0:Schema". Unlike other core resources the
"Schema" resource MAY contain a complex object within a sub-attribute "Schema" resource MAY contain a complex object within a sub-attribute
and all attributes are REQUIRED unless otherwise specified. and all attributes are REQUIRED unless otherwise specified.
The following Singular Attributes are defined: The following Singular Attributes are defined:
skipping to change at page 20, line 21 skipping to change at page 20, line 34
mutability A single keyword indicating what types of mutability A single keyword indicating what types of
modifications an attribute MAY accept as follows: modifications an attribute MAY accept as follows:
readOnly The attribute SHALL NOT be modified. readOnly The attribute SHALL NOT be modified.
readWrite The attribute MAY be updated and read at any time. readWrite The attribute MAY be updated and read at any time.
DEFAULT. DEFAULT.
immutable The attribute MAY be defined at resource creation immutable The attribute MAY be defined at resource creation
(e.g. POST) or at record replacement via request (e.g. a (e.g. POST) or at record replacement via request (e.g. a
PUT). The attribute SHALL NOT be updated. PUT). The attribute SHALL NOT be updated.
writeOnly The attribute MAY be updated at any time. Attribute writeOnly The attribute MAY be updated at any time. Attribute
values SHALL NOT be returned (e.g. because the value is a values SHALL NOT be returned (e.g. because the value is a
stored hash). Note: an attribute with mutability of stored hash). Note: an attribute with mutability of
"writeOnly" usually also has a returned setting of "never". "writeOnly" usually also has a returned setting of "never".
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
skipping to change at page 21, line 31 skipping to change at page 21, line 43
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
server SHOULD possess the same value. server SHOULD possess the same value.
global The value SHOULD be globally unique (e.g. an email global The value SHOULD be globally unique (e.g. an email
address, a GUID, or other value). No two resources on any address, a GUID, or other value). No two resources on any
server SHOULD possess the same value. server SHOULD possess the same value.
referenceTypes The names of the resource types that may be referenceTypes The names of the resource types that may be
referenced; e.g., "User". This is only applicable for referenced; e.g., "User". This is only applicable for
attributes that are of the "reference" Section 3.1.7 data type. attributes that are of the "reference" Section 2.1.7 data type.
The following multi-valued attributes are defined. There are The following multi-valued attributes are defined. There are
no canonical type values defined and the primary value serves no canonical type values defined and the primary value serves
no useful purpose. no useful purpose.
name The attribute's name. name The attribute's name.
type The attribute's data type; e.g., String. type The attribute's data type; e.g., String.
description The attribute's human readable description. When description The attribute's human readable description. When
skipping to change at page 22, line 7 skipping to change at page 22, line 17
specified in the core schema specification. specified in the core schema specification.
required A Boolean value that specifies if the attribute is required A Boolean value that specifies if the attribute is
required. required.
caseExact A Boolean value that specifies if the String caseExact A Boolean value that specifies if the String
attribute is case sensitive. attribute is case sensitive.
referenceTypes The names of the resource types that may be referenceTypes The names of the resource types that may be
referenced; e.g., User. This is only applicable for referenced; e.g., User. This is only applicable for
attributes that are of the "reference" Section 3.1.7 data attributes that are of the "reference" Section 2.1.7 data
type. type.
canonicalValues A collection of canonical values. When canonicalValues A collection of canonical values. When
applicable service providers MUST specify the canonical applicable service providers MUST specify the canonical
types specified in the core schema specification; types specified in the core schema specification; e.g.,
e.g.,"work","home". OPTIONAL. "work", "home". OPTIONAL.
mutability A single keyword indicating what types of mutability A single keyword indicating what types of
modifications an attribute MAY accept as follows: modifications an attribute MAY accept as follows:
readOnly The attribute MAY NOT be modified. readOnly The attribute MAY NOT be modified.
readWrite The attribute MAY be updated and read at any readWrite The attribute MAY be updated and read at any
time. DEFAULT. time. DEFAULT.
immutable The attribute MAY be defined at resource creation immutable The attribute MAY be defined at resource creation
(e.g. POST) or at record replacement via request (e.g. a (e.g. POST) or at record replacement via request (e.g. a
PUT). The attribute MAY NOT be updated. PUT). The attribute MAY NOT be updated.
writeOnly The attribute MAY be updated at any time. writeOnly The attribute MAY be updated at any time.
Attribute values MAY NOT be returned (e.g. because the Attribute values MAY NOT be returned (e.g. because the
value is a stored hash). Note: an attribute with value is a stored hash). Note: an attribute with
mutability of "writeOnly" usually also has a returned mutability of "writeOnly" usually also has a returned
setting of "never". setting of "never".
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 associated values are returned in response to a GET request
skipping to change at page 23, line 33 skipping to change at page 23, line 45
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) but MAY not be current SCIM endpoint (or tenancy) but MAY not be
globally unique (e.g. a "username", email address, or globally unique (e.g. a "username", email address, or
other server generated key or counter). No two resources other server generated key or counter). No two resources
on the same server SHOULD possess the same value. on the same server SHOULD possess the same value.
global The value SHOULD be globally unique (e.g. an email global The value SHOULD be globally unique (e.g. an email
address, a GUID, or other value). No two resources on address, a GUID, or other value). No two resources on
any server SHOULD possess the same value. any server SHOULD possess the same value.
12. JSON Representation 11. JSON Representation
12.1. Minimal User Representation 11.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:scim:schemas:core:2.0:User"], "schemas": ["urn:scim:schemas:core:2.0:User"],
"id": "2819c223-7f76-453a-919d-413861904646", "id": "2819c223-7f76-453a-919d-413861904646",
"userName": "bjensen@example.com", "userName": "bjensen@example.com",
"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\/\"3694e05e9dff590\"", "version": "W\/\"3694e05e9dff590\"",
"location": "https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646" "location": "https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646"
} }
} }
12.2. Full User Representation
Figure 2: Example Minimal User JSON Representation
11.2. Full User Representation
The following is a non-normative example of the fully populated SCIM The following is a non-normative example of the fully populated SCIM
representation in JSON format. representation in JSON format.
{ {
"schemas": ["urn:scim:schemas:core:2.0:User"], "schemas": ["urn:scim:schemas:core:2.0:User"],
"id": "2819c223-7f76-453a-919d-413861904646", "id": "2819c223-7f76-453a-919d-413861904646",
"externalId": "701984", "externalId": "701984",
"userName": "bjensen@example.com", "userName": "bjensen@example.com",
"name": { "name": {
skipping to change at page 26, line 43 skipping to change at page 27, line 9
], ],
"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\/\"a330bc54f0671c9\"", "version": "W\/\"a330bc54f0671c9\"",
"location": "https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646" "location": "https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646"
} }
} }
12.3. Enterprise User Extension Representation Figure 3: Example Full User JSON Representation
11.3. Enterprise User Extension Representation
The following is a non-normative example of the fully populated User The following is a non-normative example of the fully populated User
using the enterprise User extension in JSON format. using the enterprise User extension in JSON format.
{ {
"schemas": ["urn:scim:schemas:core:2.0:User", "urn:scim:schemas:extension:enterprise:2.0:User"], "schemas":
[ "urn:scim:schemas:core:2.0:User",
"urn:scim:schemas:extension:enterprise:2.0:User"],
"id": "2819c223-7f76-453a-919d-413861904646", "id": "2819c223-7f76-453a-919d-413861904646",
"externalId": "701984", "externalId": "701984",
"userName": "bjensen@example.com", "userName": "bjensen@example.com",
"name": { "name": {
"formatted": "Ms. Barbara J Jensen III", "formatted": "Ms. Barbara J Jensen III",
"familyName": "Jensen", "familyName": "Jensen",
"givenName": "Barbara", "givenName": "Barbara",
"middleName": "Jane", "middleName": "Jane",
"honorificPrefix": "Ms.", "honorificPrefix": "Ms.",
"honorificSuffix": "III" "honorificSuffix": "III"
skipping to change at page 29, line 44 skipping to change at page 30, line 16
}, },
"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": "https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646" "location": "https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646"
} }
} }
12.4. Group Representation Figure 4: Example Enterprise User JSON Representation
11.4. Group Representation
The following is a non-normative example of SCIM Group representation The following is a non-normative example of SCIM Group representation
in JSON format. in JSON format.
{ {
"schemas": ["urn:scim:schemas:core:2.0:Group"], "schemas": ["urn:scim:schemas:core:2.0:Group"],
"id": "e9e30dba-f08f-4109-8486-d5c6a331660a", "id": "e9e30dba-f08f-4109-8486-d5c6a331660a",
"displayName": "Tour Guides", "displayName": "Tour Guides",
"members": [ "members": [
{ {
skipping to change at page 30, line 30 skipping to change at page 30, line 48
], ],
"meta": { "meta": {
"resourceType": "Group", "resourceType": "Group",
"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\/\"3694e05e9dff592\"", "version": "W\/\"3694e05e9dff592\"",
"location": "https://example.com/v2/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a" "location": "https://example.com/v2/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a"
} }
} }
12.5. Service Provider Configuration Representation Figure 5: Example Group JSON Representation
11.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": ["urn:scim:schemas:core:2.0:ServiceProviderConfig"], "schemas": ["urn: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 31, line 36 skipping to change at page 32, line 11
], ],
"meta": { "meta": {
"location":"https://example.com/v2/ServiceProviderConfig", "location":"https://example.com/v2/ServiceProviderConfig",
"resourceType": "ServiceProviderConfig", "resourceType": "ServiceProviderConfig",
"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\/\"3694e05e9dff594\"" "version": "W\/\"3694e05e9dff594\""
} }
} }
12.6. Resource Type Representation Figure 6: Example Service Provider Config JSON Representation
11.6. Resource Type Representation
The following is a non-normative example of the SCIM resource type The following is a non-normative example of the SCIM resource type
representation in JSON format. representation in JSON format.
{ {
"schemas": ["urn:scim:schemas:core:2.0:ResourceType"], "schemas": ["urn:scim:schemas:core:2.0:ResourceType"],
"id":"User", "id":"User",
"name":"User", "name":"User",
"endpoint": "/Users", "endpoint": "/Users",
"description": "Core User", "description": "Core User",
"schema": "urn:scim:schemas:core:2.0:User", "schema": "urn:scim:schemas:core:2.0:User",
"schemaExtensions": [ "schemaExtensions": [
{ {
"schema": "urn:scim:schemas:extension:enterprise:2.0:EnterpriseUser", "schema": "urn:scim:schemas:extension:enterprise:2.0:User",
"required": true "required": true
} }
], ],
"meta": { "meta": {
"location":"https://example.com/v2/ResourceTypes/User", "location":"https://example.com/v2/ResourceTypes/User",
"resourceType": "ResourceType", "resourceType": "ResourceType",
"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\/\"3694e05e9dff595\"" "version": "W\/\"3694e05e9dff595\""
} }
} }
12.7. Schema Representation Figure 7: Example Resource Type JSON Representation
11.7. Schema Representation
The following is intended as normative example of the SCIM Schema The following is intended as normative example of the SCIM Schema
representation in JSON format. Where permitted individual values and representation in JSON format. Where permitted individual values and
schema MAY change. Included but not limited to, are schemas for schema MAY change. Included but not limited to, are schemas for
User, Group, and enterprise user. User, Group, and enterprise user.
{[ {[
{ {
"id" : "urn:scim:schemas:core:2.0:User", "id" : "urn:scim:schemas:core:2.0:User",
"name" : "User", "name" : "User",
skipping to change at page 54, line 17 skipping to change at page 54, line 33
"meta" : { "meta" : {
"resourceType" : "Schema", "resourceType" : "Schema",
"created" : "2010-01-23T04:56:22Z", "created" : "2010-01-23T04:56:22Z",
"lastModified" : "2014-02-04T00:00:00Z", "lastModified" : "2014-02-04T00:00:00Z",
"version" : "W/\"3694e05e9dff596\"", "version" : "W/\"3694e05e9dff596\"",
"location" : "https://example.com/v2/Schemas/urn:scim:schemas:extension:enterprise:2.0:User" "location" : "https://example.com/v2/Schemas/urn:scim:schemas:extension:enterprise:2.0:User"
} }
} }
]} ]}
13. Security Considerations Figure 8: Eample Schema JSON Representation
12. Security Considerations
The SCIM Core schema contains personally identifiable information as The SCIM Core schema contains personally identifiable information as
well as other sensitive data. Aside from prohibiting password values well as other sensitive data. Aside from prohibiting password values
in a SCIM response this specification does not provide any means or in a SCIM response this specification does not provide any means or
guarantee of confidentiality. guarantee of confidentiality.
14. IANA Considerations 13. IANA Considerations
14.1. Registering New SCIM Schemas 13.1. URN Sub-Namespace for SCIM
SCIM schemas and SCIM messages utilize URIs to identify the schema in
use or other relevant context. This section creates and registers an
IETF URN Sub-namespace for use in the SCIM specifications and future
extensions.
13.1.1. Specification Template
Namespace ID:
The Namespace ID "scim" is requested.
Registration Information:
Version: 1
Date: [[insert final submission date]]
Declared registrant of the namespace:
Registering organization
The Internet Engineering Task Force
Designated contact
A designated expert will monitor the SCIM public mailing list,
"scim@ietf.org".
Declaration of Syntactic Structure:
The Namespace Specific String (NSS) of all URNs that use the
"scim" NID shall have the following structure:
urn:scim:{type}:{name}{:subName}:{version}{:className}{:resourceType}
The keywords have the following meaning:
type
An entity type (e.g. "schemas", "api", or "param" ).
name
A required US-ASCII string that conforms to the URN syntax
requirements (see [RFC2141] ) and defines a major namespace of
object used within SCIM (e.g. "core", "extension" ). The name
"extension" MUST be used when the registered schema it refers
to is intended to be used as an extension to another schema.
An optional US-ASCII string that conforms to the URN syntax
requirements (see [RFC2141] ) and defines a sub-class of object
used within SCIM (e.g. "enterprise", "extension" ).
version
The first SCIM API version number where the URN is valid (e.g.
"2.0" ).
className
An optional US-ASCII string that conforms to the URN syntax
requirements (see [RFC2141] ) and defines a major class of
object used within SCIM.
resourceType
An optional US-ASCII string that conforms to the URN syntax
requirements (see [RFC2141] ) and typically is used when
referring to a resource type within SCIM (e.g. User).
Relevant Ancillary Documentation:
None
Identifier Uniqueness Considerations:
The designated contact shall be responsible for reviewing and
enforcing uniqueness.
Identifier Persistence Considerations:
Once a name has been allocated it MUST NOT be re-allocated for a
different purpose. The rules provided for assignments of values
within a sub-namespace MUST be constructed so that the meaning of
values cannot change. This registration mechanism is not
appropriate for naming values whose meaning may change over time.
As the SCIM specifications are updated and the SCIM API version is
adjusted, a new registration will be made when significant changes
are made. Example, "urn:scim:schemas:core:1.0" and
"urn:scim:schemas:core:2.0".
Process of Identifier Assignment:
Identifiers with namespace type "schema" (e.g. "urn:scim:schemas"
) are assigned after the review of the assigned contact via the
SCIM public mailing list, "scim@ietf.org" as documented in
Section 13.2.
Namespaces with type "api" (e.g. "urn:scim:api" ) are reserved for
IETF approved SCIM specifications. Namespaces with type "param"
are reserved for future use.
Process of Identifier Resolution:
The namespace is not currently listed with a Resolution Discovery
System (RDS), but nothing about the namespace prohibits the future
definition of appropriate resolution methods or listing with an
RDS.
Rules for Lexical Equivalence:
No special considerations; the rules for lexical equivalence
specified in [RFC2141] apply.
Conformance with URN Syntax:
No special considerations.
Validation Mechanism:
None specified.
Scope:
Global.
13.1.2. Pre-Registered SCIM Schema Identifiers
The following SCIM Identifiers are defined:
urn:scim:schemas:core:2.0
SCIM Core Schema as specified in Section 4 and Section 13.3.
urn:scim:schemas:extension:enterprise:2.0
Enterprise schema extensions as defined in Section 6 and
Section 13.3.
13.2. Registering SCIM Schemas
This section defines the process for registering new SCIM schemas This section defines the process for registering new SCIM schemas
with IANA. A schema URI is used as a value in the schemas attribute with IANA. A schema URI is used as a value in the schemas attribute
(Section 5.2) for the purpose of distinguishing extensions used in a ( Section 4.2 ) for the purpose of distinguishing extensions used in
SCIM resource. a SCIM resource.
14.1.1. Registration Procedure 13.2.1. Registration Procedure
The IETF has created a mailing list, scim@ietf.org, which can be used The IETF has created a mailing list, scim@ietf.org, which can be used
for public discussion of SCIM schema proposals prior to registration. for public discussion of SCIM schema proposals prior to registration.
Use of the mailing list is strongly encouraged. The IESG has Use of the mailing list is strongly encouraged. The IESG has
appointed a designated expert who will monitor the scim@ietf.org appointed a designated expert who will monitor the scim@ietf.org
mailing list and review registrations. mailing list and review registrations.
Registration of new schemas MUST be reviewed by the designated expert Registration of new schemas MUST be reviewed by the designated expert
and published in an RFC. A Standards Track RFC is REQUIRED for the and published in an RFC. A Standards Track RFC is REQUIRED for the
registration of new value data types that modify existing properties. registration of new value data types that modify existing properties.
A Standards Track RFC is also REQUIRED for registration of SCIM A Standards Track RFC is also REQUIRED for registration of SCIM
schema URIs that modify SCIM schema previously documented in a schema URIs that modify SCIM schema previously documented in a
Standards Track RFC. Standards Track RFC.
The registration procedure begins when a completed registration The registration procedure begins when a completed registration
template, defined in the sections below, is sent to vcarddav@ietf.org template, defined in the sections below, is sent to scim@ietf.org and
and iana@iana.org. Within two weeks, the designated expert is iana@iana.org. Within two weeks, the designated expert is expected
expected to tell IANA and the submitter of the registration whether to tell IANA and the submitter of the registration whether the
the registration is approved, approved with minor changes, or registration is approved, approved with minor changes, or rejected
rejected with cause. When a registration is rejected with cause, it with cause. When a registration is rejected with cause, it can be
can be re-submitted if the concerns listed in the cause are re-submitted if the concerns listed in the cause are addressed.
addressed. Decisions made by the designated expert can be appealed Decisions made by the designated expert can be appealed to the IESG
to the IESG Applications Area Director, then to the IESG. They Applications Area Director, then to the IESG. They follow the normal
follow the normal appeals procedure for IESG decisions. appeals procedure for IESG decisions.
Once the registration procedure concludes successfully, IANA creates Once the registration procedure concludes successfully, IANA creates
or modifies the corresponding record in the SCIM schema registry. or modifies the corresponding record in the SCIM schema registry.
The completed registration template is discarded. The completed registration template is discarded.
An RFC specifying new schema URI MUST include the completed An RFC specifying new schema URI MUST include the completed
registration templates, which MAY be expanded with additional registration templates, which MAY be expanded with additional
information. These completed templates are intended to go in the information. These completed templates are intended to go in the
body of the document, not in the IANA Considerations section. The body of the document, not in the IANA Considerations section. The
RFC SHOULD include any attributes defined. RFC SHOULD include any attributes defined.
14.1.2. Schema Registration Template 13.2.2. Schema Registration Template
A SCIM schema URI is defined by completing the following template: A SCIM schema URI is defined by completing the following template:
Schema URI: Schema URI: A unique URI for the SCIM schema extension. Schema URI: Schema URI: A unique URI for the SCIM schema extension.
Schema Name: A descriptive name of the schema extension (e.g. Schema Name: A descriptive name of the schema extension (e.g.
Generic Device) Generic Device)
Intended or Associated Resource Type: A value defining the resource Intended or Associated Resource Type: A value defining the resource
type (e.g. "Device"). type (e.g. "Device").
Purpose: A description of the purpose of the extension and/or its Purpose: A description of the purpose of the extension and/or its
intended use. intended use.
Single-value Attributes: A list and description of single-valued Single-value Attributes: A list and description of single-valued
attributes defined including complex attributes. attributes defined including complex attributes.
Multi-valued Attributes: A list and description of multi-valued Multi-valued Attributes: A list and description of multi-valued
attributes defined including complex attributes. attributes defined including complex attributes.
14.2. Initial SCIM Schema Registry 13.3. Initial SCIM Schema Registry
The IANA has created and will maintain the following registries for The IANA has created and will maintain the following registries for
SCIM schema URIs with pointers to appropriate reference documents. SCIM schema URIs with pointers to appropriate reference documents.
+---------------------------------------------+----------+----------+ +-------------------------------------------+-----------+-----------+
| Schema URI | Name | Referenc | | Schema URI | Name | Reference |
| | | e | +-------------------------------------------+-----------+-----------+
+---------------------------------------------+----------+----------+ | urn:scim:schemas:core:2.0:User | User | See |
| urn:scim:schemas:core:2.0:User | User | See | | | Resource | Section 5 |
| | Resource | Section | | urn:scim:schemas:extension:enterprise:2.0 | Enterpris | See |
| | | 6 | | :User | e User | Section 6 |
| urn:scim:schemas:extension:enterprise:2.0:E | Enterpri | See | | | Extension | |
| nterpriseUser | se User | Section | | urn:scim:schemas:core:2.0:Group | Group | See |
| | Extensio | 7 | | | Resource | Section 7 |
| | n | | +-------------------------------------------+-----------+-----------+
| urn:scim:schemas:core:2.0:Group | Group | See |
| | Resource | Section |
| | | 8 |
+---------------------------------------------+----------+----------+
SCIM Schema URIs for Data Resources SCIM Schema URIs for Data Resources
+-----------------------------------------+-------------+-----------+ +-----------------------------------------+-------------+-----------+
| Schema URI | Name | Reference | | Schema URI | Name | Reference |
+-----------------------------------------+-------------+-----------+ +-----------------------------------------+-------------+-----------+
| urn:scim:schemas:core:2.0:ServiceProvid | Service | See | | urn:scim:schemas:core:2.0:ServiceProvid | Service | See |
| erConfig | Provider Co | Section 9 | | erConfig | Provider Co | Section 8 |
| | nfiguration | | | | nfiguration | |
| | Schema | | | | Schema | |
| urn:scim:schemas:core:2.0:ResourceType | Resource | See | | urn:scim:schemas:core:2.0:ResourceType | Resource | See |
| | Type Config | Section | | | Type Config | Section 9 |
| | | 10 |
| urn:scim:schemas:core:2.0:Schema | Schema | See | | urn:scim:schemas:core:2.0:Schema | Schema | See |
| | Definitions | Section | | | Definitions | Section |
| | Schema | 11 | | | Schema | 10 |
+-----------------------------------------+-------------+-----------+ +-----------------------------------------+-------------+-----------+
SCIM Server Related Schema URIs SCIM Server Related Schema URIs
15. References 14. References
15.1. Normative References
[I-D.ietf-httpbis-p2-semantics] 14.1. Normative References
Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", draft-ietf-
httpbis-p2-semantics-25 (work in progress), November 2013.
[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.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC
3966, December 2004. 3966, December 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005. 3986, January 2005.
skipping to change at page 57, line 30 skipping to change at page 60, line 27
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009. Languages", BCP 47, RFC 5646, September 2009.
[RFC6557] Lear, E. and P. Eggert, "Procedures for Maintaining the [RFC6557] Lear, E. and P. Eggert, "Procedures for Maintaining the
Time Zone Database", BCP 175, RFC 6557, February 2012. Time Zone Database", BCP 175, RFC 6557, February 2012.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014. Interchange Format", RFC 7159, March 2014.
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
[XML-Schema] [XML-Schema]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", October 2004. Second Edition", October 2004.
15.2. Informative References 14.2. Informative References
[ISO3166] "ISO 3166:1988 (E/F) - Codes for the representation of [ISO3166] "ISO 3166:1988 (E/F) - Codes for the representation of
names of countries - The International Organization for names of countries - The International Organization for
Standardization, 3rd edition", 08 1988. Standardization, 3rd edition", 08 1988.
[ISO639-2] [ISO639-2]
ISO 639.2 Registration Authority, "ISO639-2: Codes for the ISO 639.2 Registration Authority, "ISO639-2: Codes for the
Representation of Names of Languages", July 2013. Representation of Names of Languages", July 2013.
[Olson-TZ] [Olson-TZ]
skipping to change at page 60, line 5 skipping to change at page 62, line 51
23 - Clarified that the server is not required to preserve case 23 - Clarified that the server is not required to preserve case
for case insensitive strings for case insensitive strings
41 - Add IANA considerations 41 - Add IANA considerations
72 - Added text to indicate UTF-8 is default and mandatory 72 - Added text to indicate UTF-8 is default and mandatory
encoding format per BCP18 encoding format per BCP18
- Typo corrections and removed some redundant text - Typo corrections and removed some redundant text
Draft 06 - PH - Revisions based on the following tickets
63 - Corrected enterprise user URI in 14.2 and section 7, URI
namespace changes due to ticket #41
66 - Updated reference to final HTTP/1.1 drafts (RFC 7230)
41 - Add IANA considerations
- Removed redundant text (e.g. SAML binding, replaced REST with
HTTP)
- Reordered introduction, definitions and notation sections to
follow typical format
- meta.attributes removed due to new PURGE command in draft 04 (no
longer used)
Authors' Addresses Authors' Addresses
Kelly Grizzle Kelly Grizzle
SailPoint SailPoint
Email: kelly.grizzle@sailpoint.com Email: kelly.grizzle@sailpoint.com
Phil Hunt (editor) Phil Hunt (editor)
Oracle Corporation Oracle Corporation
 End of changes. 112 change blocks. 
270 lines changed or deleted 445 lines changed or added

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