draft-ietf-scim-core-schema-06.txt   draft-ietf-scim-core-schema-07.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: December 25, 2014 Oracle Expires: February 2, 2015 Oracle
E. Wahlstroem E. Wahlstroem
Technology Nexus Technology Nexus
C. Mortimore C. Mortimore
Salesforce Salesforce
June 23, 2014 August 1, 2014
System for Cross-Domain Identity Management: Core Schema System for Cross-Domain Identity Management: Core Schema
draft-ietf-scim-core-schema-06 draft-ietf-scim-core-schema-07
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
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 December 25, 2014. This Internet-Draft will expire on February 2, 2015.
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
skipping to change at page 2, line 37 skipping to change at page 2, line 37
2.1. Attribute Data Types . . . . . . . . . . . . . . . . . . 5 2.1. Attribute Data Types . . . . . . . . . . . . . . . . . . 5
2.1.1. String . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1. String . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3. Decimal . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.3. Decimal . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.4. Integer . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.4. Integer . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.5. DateTime . . . . . . . . . . . . . . . . . . . . . . 6 2.1.5. DateTime . . . . . . . . . . . . . . . . . . . . . . 6
2.1.6. Binary . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.6. Binary . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.7. Reference . . . . . . . . . . . . . . . . . . . . . . 7 2.1.7. Reference . . . . . . . . . . . . . . . . . . . . . . 7
2.1.8. Complex . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.8. Complex . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Multi-valued Attributes . . . . . . . . . . . . . . . . . 7 2.2. Multi-valued Attributes . . . . . . . . . . . . . . . . . 7
2.3. Unassigned and Null Values . . . . . . . . . . . . . . . 8
3. Schema Extension Model . . . . . . . . . . . . . . . . . . . 8 3. Schema Extension Model . . . . . . . . . . . . . . . . . . . 8
4. SCIM Core Schema . . . . . . . . . . . . . . . . . . . . . . 8 4. SCIM Core Schema . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Common Schema Attributes . . . . . . . . . . . . . . . . 9 4.1. Common Schema Attributes . . . . . . . . . . . . . . . . 9
4.2. "schemas" Attribute . . . . . . . . . . . . . . . . . . . 10 4.2. "schemas" Attribute . . . . . . . . . . . . . . . . . . . 10
5. SCIM User Schema . . . . . . . . . . . . . . . . . . . . . . 10 5. SCIM User Schema . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Singular Attributes . . . . . . . . . . . . . . . . . . . 10 5.1. Singular Attributes . . . . . . . . . . . . . . . . . . . 11
5.2. Multi-valued Attributes . . . . . . . . . . . . . . . . . 13 5.2. Multi-valued Attributes . . . . . . . . . . . . . . . . . 13
6. SCIM Enterprise User Schema Extension . . . . . . . . . . . . 15 6. SCIM Enterprise User Schema Extension . . . . . . . . . . . . 15
7. SCIM Group Schema . . . . . . . . . . . . . . . . . . . . . . 16 7. SCIM Group Schema . . . . . . . . . . . . . . . . . . . . . . 16
8. Service Provider Configuration Schema . . . . . . . . . . . . 16 8. Service Provider Configuration Schema . . . . . . . . . . . . 16
9. ResourceType Schema . . . . . . . . . . . . . . . . . . . . . 18 9. ResourceType Schema . . . . . . . . . . . . . . . . . . . . . 18
10. Schema Schema . . . . . . . . . . . . . . . . . . . . . . . . 19 10. Schema Schema . . . . . . . . . . . . . . . . . . . . . . . . 19
11. JSON Representation . . . . . . . . . . . . . . . . . . . . . 23 11. JSON Representation . . . . . . . . . . . . . . . . . . . . . 24
11.1. Minimal User Representation . . . . . . . . . . . . . . 23 11.1. Minimal User Representation . . . . . . . . . . . . . . 24
11.2. Full User Representation . . . . . . . . . . . . . . . . 24 11.2. Full User Representation . . . . . . . . . . . . . . . . 24
11.3. Enterprise User Extension Representation . . . . . . . . 27 11.3. Enterprise User Extension Representation . . . . . . . . 27
11.4. Group Representation . . . . . . . . . . . . . . . . . . 30 11.4. Group Representation . . . . . . . . . . . . . . . . . . 30
11.5. Service Provider Configuration Representation . . . . . 31 11.5. Service Provider Configuration Representation . . . . . 31
11.6. Resource Type Representation . . . . . . . . . . . . . . 32 11.6. Resource Type Representation . . . . . . . . . . . . . . 32
11.7. Schema Representation . . . . . . . . . . . . . . . . . 32 11.7. Schema Representation . . . . . . . . . . . . . . . . . 33
12. Security Considerations . . . . . . . . . . . . . . . . . . . 54 12. Security Considerations . . . . . . . . . . . . . . . . . . . 55
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
13.1. URN Sub-Namespace for SCIM . . . . . . . . . . . . . . . 54 13.1. URN Sub-Namespace for SCIM . . . . . . . . . . . . . . . 55
13.1.1. Specification Template . . . . . . . . . . . . . . . 55 13.1.1. Specification Template . . . . . . . . . . . . . . . 55
13.1.2. Pre-Registered SCIM Schema Identifiers . . . . . . . 57 13.1.2. Pre-Registered SCIM Schema Identifiers . . . . . . . 58
13.2. Registering SCIM Schemas . . . . . . . . . . . . . . . . 57 13.2. Registering SCIM Schemas . . . . . . . . . . . . . . . . 58
13.2.1. Registration Procedure . . . . . . . . . . . . . . . 57 13.2.1. Registration Procedure . . . . . . . . . . . . . . . 58
13.2.2. Schema Registration Template . . . . . . . . . . . . 58 13.2.2. Schema Registration Template . . . . . . . . . . . . 59
13.3. Initial SCIM Schema Registry . . . . . . . . . . . . . . 59 13.3. Initial SCIM Schema Registry . . . . . . . . . . . . . . 59
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 60
14.1. Normative References . . . . . . . . . . . . . . . . . . 59 14.1. Normative References . . . . . . . . . . . . . . . . . . 60
14.2. Informative References . . . . . . . . . . . . . . . . . 60 14.2. Informative References . . . . . . . . . . . . . . . . . 61
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 61 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 62
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 61 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64
1. Introduction and Overview 1. Introduction and Overview
While there are existing standards for describing and exchanging user While there are existing standards for describing and exchanging user
information, many of these standards can be difficult to implement information, many of these standards can be difficult to implement
and/or use; e.g., their wire protocols do not easily traverse and/or use; e.g., their wire protocols do not easily traverse
firewalls and/or are not easily layered onto existing web protocols. firewalls and/or are not easily layered onto existing web protocols.
As a result, many cloud providers implement non-standard APIs for As a result, many cloud providers implement non-standardized
managing users within their services. This increases both the cost protocols for managing users within their services. This increases
and complexity associated with organizations adopting products and both the cost and complexity associated with organizations adopting
services from multiple cloud providers as they must perform redundant products and services from multiple cloud providers as they must
integration development. Similarly, cloud services providers seeking perform redundant integration development. Similarly, cloud services
to inter-operate with multiple application marketplaces or cloud providers seeking to inter-operate with multiple application
identity providers must be redundantly integrated. marketplaces or cloud 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 an HTTP API. It draws inspiration and exchanging this schema via an HTTP based protocol. It draws
best practice, building upon existing user APIs and schemas from a inspiration and best practice, building upon existing user protocols
wide variety of sources including, but not limited to, existing APIs and schemas from a wide variety of sources including, but not limited
exposed by cloud providers, PortableContacts, vCards, and LDAP to, existing services exposed by cloud providers, PortableContacts,
directory services. vCards, and LDAP directory services.
This document provides a JSON based schema and extension model for This document provides a JSON based schema and extension model for
representing users and groups, as well as service provider representing users and groups, as well as service provider
configuration. This schema is intended for exchange and use with configuration. This schema is intended for exchange and use with
cloud service providers and other cross-domain scenarios. An HTTP cloud service providers and other cross-domain scenarios. An HTTP
protocol binding document is provided separately. protocol binding document is provided separately.
1.1. Requirements Notation and Conventions 1.1. Requirements Notation and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 8, line 23 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.
2.3. Unassigned and Null Values
Unassigned attributes, the null value, or empty array (in the case of
a multi-valued attribute) SHALL be considered to be equivalent in
"state". Assigning an attribute with the value "null" or an empty
array (in the case of multi-valued attributes) has the effect of
making the attribute "unassigned". When an resource is expressed in
JSON form, unassigned attributes, though they are defined in schema,
MAY be omitted for compactness.
3. 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 "schemas" value indicates additive schema Class [RFC4512] ). Each "schemas" value indicates additive schema
that may exist in a SCIM resource representation. The "schemas" that may exist in a SCIM resource representation. The "schemas"
attribute MUST contain at least one value which SHALL be the base attribute MUST contain at least one value which SHALL be the base
schema for the resource. The "schemas" attribute MAY contain schema for the resource. The "schemas" attribute MAY contain
additional values indicating extended schemas that are in use. additional values indicating extended schemas that are in use.
skipping to change at page 55, line 50 skipping to change at page 56, line 34
requirements (see [RFC2141] ) and defines a major namespace of requirements (see [RFC2141] ) and defines a major namespace of
object used within SCIM (e.g. "core", "extension" ). The name object used within SCIM (e.g. "core", "extension" ). The name
"extension" MUST be used when the registered schema it refers "extension" MUST be used when the registered schema it refers
to is intended to be used as an extension to another schema. to is intended to be used as an extension to another schema.
An optional US-ASCII string that conforms to the URN syntax An optional US-ASCII string that conforms to the URN syntax
requirements (see [RFC2141] ) and defines a sub-class of object requirements (see [RFC2141] ) and defines a sub-class of object
used within SCIM (e.g. "enterprise", "extension" ). used within SCIM (e.g. "enterprise", "extension" ).
version version
The first SCIM API version number where the URN is valid (e.g. The first SCIM protocol version number where the URN is valid
"2.0" ). (e.g. "2.0" ).
className className
An optional US-ASCII string that conforms to the URN syntax An optional US-ASCII string that conforms to the URN syntax
requirements (see [RFC2141] ) and defines a major class of requirements (see [RFC2141] ) and defines a major class of
object used within SCIM. object used within SCIM.
resourceType resourceType
An optional US-ASCII string that conforms to the URN syntax An optional US-ASCII string that conforms to the URN syntax
requirements (see [RFC2141] ) and typically is used when requirements (see [RFC2141] ) and typically is used when
referring to a resource type within SCIM (e.g. User). referring to a resource type within SCIM (e.g. User).
skipping to change at page 56, line 32 skipping to change at page 57, line 18
enforcing uniqueness. enforcing uniqueness.
Identifier Persistence Considerations: Identifier Persistence Considerations:
Once a name has been allocated it MUST NOT be re-allocated for a Once a name has been allocated it MUST NOT be re-allocated for a
different purpose. The rules provided for assignments of values different purpose. The rules provided for assignments of values
within a sub-namespace MUST be constructed so that the meaning of within a sub-namespace MUST be constructed so that the meaning of
values cannot change. This registration mechanism is not values cannot change. This registration mechanism is not
appropriate for naming values whose meaning may change over time. appropriate for naming values whose meaning may change over time.
As the SCIM specifications are updated and the SCIM API version is As the SCIM specifications are updated and the SCIM protocol
adjusted, a new registration will be made when significant changes version is adjusted, a new registration will be made when
are made. Example, "urn:scim:schemas:core:1.0" and significant changes are made. Example,
"urn:scim:schemas:core:2.0". "urn:scim:schemas:core:1.0" and "urn:scim:schemas:core:2.0".
Process of Identifier Assignment: Process of Identifier Assignment:
Identifiers with namespace type "schema" (e.g. "urn:scim:schemas" Identifiers with namespace type "schema" (e.g. "urn:scim:schemas"
) are assigned after the review of the assigned contact via the ) are assigned after the review of the assigned contact via the
SCIM public mailing list, "scim@ietf.org" as documented in SCIM public mailing list, "scim@ietf.org" as documented in
Section 13.2. Section 13.2.
Namespaces with type "api" (e.g. "urn:scim:api" ) are reserved for Namespaces with type "api" (e.g. "urn:scim:api" ) are reserved for
IETF approved SCIM specifications. Namespaces with type "param" IETF approved SCIM specifications. Namespaces with type "param"
skipping to change at page 63, line 4 skipping to change at page 63, line 44
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 Draft 06 - PH - Revisions based on the following tickets
63 - Corrected enterprise user URI in 14.2 and section 7, URI 63 - Corrected enterprise user URI in 14.2 and section 7, URI
namespace changes due to ticket #41 namespace changes due to ticket #41
66 - Updated reference to final HTTP/1.1 drafts (RFC 7230) 66 - Updated reference to final HTTP/1.1 drafts (RFC 7230)
41 - Add IANA considerations 41 - Add IANA considerations
- Removed redundant text (e.g. SAML binding, replaced REST with - Removed redundant text (e.g. SAML binding, replaced REST with
HTTP) HTTP)
- Reordered introduction, definitions and notation sections to - Reordered introduction, definitions and notation sections to
follow typical format follow typical format
- meta.attributes removed due to new PURGE command in draft 04 (no - meta.attributes removed due to new PURGE command in draft 04 (no
longer used) longer used)
Draft 07 - PH - Edits and revisions
- Dropped use of the term API in favour of HTTP protocol or just
protocol.
- Clarified meaning of null and unassigned
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. 19 change blocks. 
41 lines changed or deleted 60 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/