draft-ietf-scim-api-00.txt   draft-ietf-scim-api-01.txt 
Network Working Group T. Drake, Ed. Network Working Group T. Drake, Ed.
Internet-Draft UnboundID Internet-Draft UnboundID
Intended status: Standards Track C. Mortimore Intended status: Standards Track C. Mortimore
Expires: February 28, 2013 SalesForce Expires: October 17, 2013 SalesForce
M. Ansari M. Ansari
Cisco Cisco
K. Grizzle K. Grizzle
SailPoint SailPoint
E. Wahlstroem E. Wahlstroem
Technology Nexus Technology Nexus
August 27, 2012 April 15, 2013
System for Cross-Domain Identity Management:Protocol System for Cross-Domain Identity Management:Protocol
draft-ietf-scim-api-00 draft-ietf-scim-api-01
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 seeks to applications and services easier. The specification suite seeks to
build upon experience with existing schemas and deployments, placing build 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.
It's intent is to reduce the cost and complexity of user management It's intent is to reduce the cost and complexity of user management
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 February 28, 2013. This Internet-Draft will expire on October 17, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 4
1.1. Intended Audience . . . . . . . . . . . . . . . . . . . . 3 1.1. Intended Audience . . . . . . . . . . . . . . . . . . . . 4
1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 3 1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 4
1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Authentication and Authorization . . . . . . . . . . . . . . . 3 2. Authentication and Authorization . . . . . . . . . . . . . . . 4
3. API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Creating Resources . . . . . . . . . . . . . . . . . . . . 6 3.1. Creating Resources . . . . . . . . . . . . . . . . . . . . 7
3.2. Retrieving Resources . . . . . . . . . . . . . . . . . . . 7 3.1.1. Resource Types . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Retrieving a known Resource . . . . . . . . . . . . . 7 3.2. Retrieving Resources . . . . . . . . . . . . . . . . . . . 8
3.2.2. List/Query Resources . . . . . . . . . . . . . . . . . 8 3.2.1. Retrieving a known Resource . . . . . . . . . . . . . 8
3.3. Modifying Resources . . . . . . . . . . . . . . . . . . . 15 3.2.2. List/Query Resources . . . . . . . . . . . . . . . . . 10
3.3.1. Modifying with PUT . . . . . . . . . . . . . . . . . . 15 3.2.3. Querying Resources Using HTTP POST . . . . . . . . . . 17
3.3.2. Modifying with PATCH . . . . . . . . . . . . . . . . . 17 3.3. Modifying Resources . . . . . . . . . . . . . . . . . . . 19
3.4. Deleting Resources . . . . . . . . . . . . . . . . . . . . 25 3.3.1. Modifying with PUT . . . . . . . . . . . . . . . . . . 19
3.5. Bulk . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.3.2. Modifying with PATCH . . . . . . . . . . . . . . . . . 21
3.6. Data Input/Output Formats . . . . . . . . . . . . . . . . 41 3.4. Deleting Resources . . . . . . . . . . . . . . . . . . . . 29
3.7. Additional retrieval query parameters . . . . . . . . . . 42 3.5. Bulk . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.8. Attribute Notation . . . . . . . . . . . . . . . . . . . . 42 3.6. Data Input/Output Formats . . . . . . . . . . . . . . . . 45
3.9. HTTP Response Codes . . . . . . . . . . . . . . . . . . . 43 3.7. Additional retrieval query parameters . . . . . . . . . . 45
3.10. API Versioning . . . . . . . . . . . . . . . . . . . . . . 44 3.8. Attribute Notation . . . . . . . . . . . . . . . . . . . . 46
3.11. Versioning Resources . . . . . . . . . . . . . . . . . . . 44 3.9. HTTP Response Codes . . . . . . . . . . . . . . . . . . . 46
3.12. HTTP Method Overloading . . . . . . . . . . . . . . . . . 46 3.10. API Versioning . . . . . . . . . . . . . . . . . . . . . . 48
4. Security Considerations . . . . . . . . . . . . . . . . . . . 46 3.11. Versioning Resources . . . . . . . . . . . . . . . . . . . 48
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.12. HTTP Method Overloading . . . . . . . . . . . . . . . . . 50
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47 4. Multi-Tenancy . . . . . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 4.1. Associating Consumers to Tenants . . . . . . . . . . . . . 51
4.1.1. URL Prefix Example . . . . . . . . . . . . . . . . . . 51
4.1.2. Subdomain Example . . . . . . . . . . . . . . . . . . 52
4.1.3. HTTP Header . . . . . . . . . . . . . . . . . . . . . 52
4.2. SCIM Identifiers with Multiple Tenants . . . . . . . . . . 52
5. Security Considerations . . . . . . . . . . . . . . . . . . . 52
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 52
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53
1. Introduction and Overview 1. Introduction and Overview
The SCIM Protocol is an application-level, REST protocol for The SCIM Protocol is an application-level, REST protocol for
provisioning and managing identity data on the web. The protocol provisioning and managing identity data on the web. The protocol
supports creation, modification, retrieval, and discovery of core supports creation, modification, retrieval, and discovery of core
identity Resources; i.e., Users and Groups, as well as custom identity Resources; i.e., Users and Groups, as well as custom
Resource extensions. Resource extensions.
1.1. Intended Audience 1.1. Intended Audience
skipping to change at page 4, line 31 skipping to change at page 5, line 31
Providers that support extended Resources SHOULD define Resource Providers that support extended Resources SHOULD define Resource
endpoints using the established convention; pluralize the Resource endpoints using the established convention; pluralize the Resource
name defined in the extended schema by appending an 's'. Given there name defined in the extended schema by appending an 's'. Given there
are cases where Resource pluralization is ambiguous; e.g., a Resource are cases where Resource pluralization is ambiguous; e.g., a Resource
named 'person' is legitimately 'persons' and 'people' Consumers named 'person' is legitimately 'persons' and 'people' Consumers
SHOULD discover Resource endpoints via the Schema Sub-Attribute SHOULD discover Resource endpoints via the Schema Sub-Attribute
'endpoint'. 'endpoint'.
GET Retrieves a complete or partial Resource. GET Retrieves a complete or partial Resource.
POST Create new Resource or bulk modify Resources. POST Create new Resource, perform an extended Search, or bulk modify
Resources.
PUT Modifies a Resource with a complete, Consumer specified Resource PUT Modifies a Resource with a complete, Consumer specified Resource
(replace). (replace).
PATCH Modifies a Resource with a set of Consumer specified changes PATCH Modifies a Resource with a set of Consumer specified changes
(partial update). (partial update).
DELETE Deletes a Resource. DELETE Deletes a Resource.
+------------+--------------------+---------------+-----------------+ +------------+--------------------+---------------+-----------------+
skipping to change at page 5, line 39 skipping to change at page 6, line 39
| | | 3.4) | | | | | 3.4) | |
| Service | /ServiceProviderCo | GET | Retrieve the | | Service | /ServiceProviderCo | GET | Retrieve the |
| Provider | nfigs | (Section 3.2. | Service | | Provider | nfigs | (Section 3.2. | Service |
| Configurat | | 1) | Provider's | | Configurat | | 1) | Provider's |
| ion | | | Configuration | | ion | | | Configuration |
| Schema | /Schemas | GET | Retrieve a | | Schema | /Schemas | GET | Retrieve a |
| | | (Section 3.2. | Resource's | | | | (Section 3.2. | Resource's |
| | | 1) | Schema | | | | 1) | Schema |
| Bulk | /Bulk | POST | Bulk modify | | Bulk | /Bulk | POST | Bulk modify |
| | | (Section 3.5) | Resources | | | | (Section 3.5) | Resources |
| Search | [prefix]/.search | POST | Perform a |
| | | (Section 3.2. | search at |
| | | 3) | system root or |
| | | | within a |
| | | | resource |
| | | | endpoint for |
| | | | one or more |
| | | | resource types |
| | | | using POST. |
+------------+--------------------+---------------+-----------------+ +------------+--------------------+---------------+-----------------+
Table 1: Defined endpoints Table 1: Defined endpoints
All requests to the Service Provider are made via HTTP operations on All requests to the Service Provider are made via HTTP operations on
a URL derived from the Base URL. Responses are returned in the body a URL derived from the Base URL. Responses are returned in the body
of the HTTP response, formatted as JSON or XML, depending on what is of the HTTP response, formatted as JSON. Response and error codes
requested. Response and error codes SHOULD be transmitted via the SHOULD be transmitted via the HTTP status code of the response (if
HTTP status code of the response (if possible), and SHOULD also be possible), and SHOULD also be specified in the body of the response.
specified in the body of the response.
3.1. Creating Resources 3.1. Creating Resources
To create new Resources, clients send POST requests to the Resource To create new Resources, clients send POST requests to the Resource
endpoint; i.e., /Users or /Groups. endpoint; i.e., /Users or /Groups.
Successful Resource creation is indicated with a 201 ("Created") Successful Resource creation is indicated with a 201 ("Created")
response code. Upon successful creation, the response body MUST response code. Upon successful creation, the response body MUST
contain the newly created Resource. Since the server is free to contain the newly created Resource. Since the server is free to
alter and/or ignore POSTed content, returning the full representation alter and/or ignore POSTed content, returning the full representation
skipping to change at page 7, line 15 skipping to change at page 8, line 15
HTTP/1.1 201 Created HTTP/1.1 201 Created
Content-Type: application/json Content-Type: application/json
Location: https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 Location: https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646
ETag: W/"e180ee84f0671b1" ETag: W/"e180ee84f0671b1"
{ {
"schemas":["urn:scim:schemas:core:1.0"], "schemas":["urn:scim:schemas:core:1.0"],
"id":"2819c223-7f76-453a-919d-413861904646", "id":"2819c223-7f76-453a-919d-413861904646",
"externalId":"bjensen", "externalId":"bjensen",
"meta":{ "meta":{
"resourceType":"User",
"created":"2011-08-01T21:32:44.882Z", "created":"2011-08-01T21:32:44.882Z",
"lastModified":"2011-08-01T21:32:44.882Z", "lastModified":"2011-08-01T21:32:44.882Z",
"location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646", "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646",
"version":"W\/\"e180ee84f0671b1\"" "version":"W\/\"e180ee84f0671b1\""
}, },
"name":{ "name":{
"formatted":"Ms. Barbara J Jensen III", "formatted":"Ms. Barbara J Jensen III",
"familyName":"Jensen", "familyName":"Jensen",
"givenName":"Barbara" "givenName":"Barbara"
}, },
"userName":"bjensen" "userName":"bjensen"
} }
3.1.1. Resource Types
When adding a resource to a specific endpoint, the meta attribute
"resourceType" SHALL be set by the Service Provider to the
corresponding resource type for the endpoint and any extension types.
For example, "/Users" will set "resourceType" to "User", and
"/Groups" will set "resourceType" to "Group".
[TBD: For extended resource types, the "resourceType" attribute SHALL
be set by the Service Provider to have multiple values including the
base type plus any extneded types (e.g. 'User' and 'Employee').]
3.2. Retrieving Resources 3.2. Retrieving Resources
Users and Group Resources are retrieved via opaque, unique URLs or Users and Group Resources are retrieved via opaque, unique URLs or
via Query. Service Providers MAY choose to respond with a sub-set of via Query. Service Providers MAY choose to respond with a sub-set of
Resource attributes, though MUST minimally return the Resource id and Resource attributes, though MUST minimally return the Resource id and
meta attributes. meta attributes.
3.2.1. Retrieving a known Resource 3.2.1. Retrieving a known Resource
To retrieve a known Resource, clients send GET requests to the To retrieve a known Resource, clients send GET requests to the
skipping to change at page 8, line 16 skipping to change at page 10, line 15
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/json Content-Type: application/json
Location: https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 Location: https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646
ETag: W/"f250dd84f0671c3" ETag: W/"f250dd84f0671c3"
{ {
"schemas":["urn:scim:schemas:core:1.0"], "schemas":["urn:scim:schemas:core:1.0"],
"id":"2819c223-7f76-453a-919d-413861904646, "id":"2819c223-7f76-453a-919d-413861904646,
"externalId":"bjensen", "externalId":"bjensen",
"meta":{ "meta":{
"resourceType":"User",
"created":"2011-08-01T18:29:49.793Z", "created":"2011-08-01T18:29:49.793Z",
"lastModified":"2011-08-01T18:29:49.793Z", "lastModified":"2011-08-01T18:29:49.793Z",
"location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646", "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646",
"version":"W\/\"f250dd84f0671c3\"" "version":"W\/\"f250dd84f0671c3\""
}, },
"name":{ "name":{
"formatted":"Ms. Barbara J Jensen III", "formatted":"Ms. Barbara J Jensen III",
"familyName":"Jensen", "familyName":"Jensen",
"givenName":"Barbara" "givenName":"Barbara"
}, },
skipping to change at page 9, line 28 skipping to change at page 11, line 26
"Resources":[ "Resources":[
{ {
"userName":"bjensen" "userName":"bjensen"
}, },
{ {
"userName":"jsmith" "userName":"jsmith"
} }
] ]
} }
3.2.2.1. Filtering 3.2.2.1. Query Endpoints
Queries MAY be performed against a SCIM:
Resource (e.g. /Users/{userid}),
Resource Type endpoint (e.g. /Users or /Groups), or
Server Root (e.g. /).
A search against a server root indicates that ALL resources within
the server SHALL be included subject to filtering. For example, a
filter against 'resourceType' could be used to restrict results to
one or more specific resource types.
When processing search operations across endpoints that include more
than one SCIM resource type (e.g. a search from the server root
endpoint), filters MUST be processed in the same fashion as outlined
in Section 3.2.2.2. For filtered attributes that are not part of a
particular resource type, the service provider SHALL treat the
attribute as if there is no attribute value. For example, a presence
or equality filter for an undefined attribute evaluates as FALSE.
3.2.2.2. Filtering
Filtering is OPTIONAL. Consumers may request a subset of Resources Filtering is OPTIONAL. Consumers may request a subset of Resources
by specifying the 'filter' URL query parameter containing a filter by specifying the 'filter' URL query parameter containing a filter
expression. When specified only those Resources matching the filter expression. When specified only those Resources matching the filter
expression SHALL be returned. The expression language that is used expression SHALL be returned. The expression language that is used
in the filter parameter supports references to attributes and in the filter parameter supports references to attributes and
literals. The literal values can be strings enclosed in double literals. The literal values can be strings enclosed in double
quotes, numbers, date times enclosed in double quotes, and Boolean quotes, numbers, date times enclosed in double quotes, and Boolean
values; i.e., true or false. String literals MUST be valid JSON values; i.e., true or false. String literals MUST be valid JSON
strings [2]. strings [2].
skipping to change at page 12, line 44 skipping to change at page 15, line 28
filter=meta.lastModified le "2011-05-13T04:42:34Z" filter=meta.lastModified le "2011-05-13T04:42:34Z"
filter=title pr and userType eq "Employee" filter=title pr and userType eq "Employee"
filter=title pr or userType eq "Intern" filter=title pr or userType eq "Intern"
filter=userType eq "Employee" and (emails co "example.com" or emails filter=userType eq "Employee" and (emails co "example.com" or emails
co "example.org") co "example.org")
3.2.2.2. Sorting 3.2.2.3. Sorting
Sort is OPTIONAL. Sorting allows Consumers to specify the order in Sort is OPTIONAL. Sorting allows Consumers to specify the order in
which Resources are returned by specifying a combination of sortBy which Resources are returned by specifying a combination of sortBy
and sortOrder URL parameters. and sortOrder URL parameters.
sortBy: The sortBy parameter specifies the attribute whose value sortBy: The sortBy parameter specifies the attribute whose value
SHALL be used to order the returned responses. If the sortBy SHALL be used to order the returned responses. If the sortBy
attribute corresponds to a Singular Attribute, Resources are attribute corresponds to a Singular Attribute, Resources are
sorted according to that attribute's value; if it's a Multi-valued sorted according to that attribute's value; if it's a Multi-valued
Attribute, Resources are sorted by the value of the primary Attribute, Resources are sorted by the value of the primary
skipping to change at page 13, line 29 skipping to change at page 16, line 9
Allowed values are "ascending" and "descending". If a value for Allowed values are "ascending" and "descending". If a value for
sortBy is provided and no sortOrder is specified, the sortOrder sortBy is provided and no sortOrder is specified, the sortOrder
SHALL default to ascending. String type attributes are case SHALL default to ascending. String type attributes are case
insensitive by default unless the attribute type is defined as a insensitive by default unless the attribute type is defined as a
caseExact string. sortOrder MUST sort according to the attribute caseExact string. sortOrder MUST sort according to the attribute
type; i.e., for caseIgnore attributes, sort the result using case type; i.e., for caseIgnore attributes, sort the result using case
insensitive, Unicode alphabetic sort order, with no specific insensitive, Unicode alphabetic sort order, with no specific
locale implied and for caseExact attribute types, sort the result locale implied and for caseExact attribute types, sort the result
using case sensitive, Unicode alphabetic sort order. using case sensitive, Unicode alphabetic sort order.
3.2.2.3. Pagination 3.2.2.4. Pagination
Pagination parameters can be used together to "page through" large Pagination parameters can be used together to "page through" large
numbers of Resources so as not to overwhelm the Consumer or Service numbers of Resources so as not to overwhelm the Consumer or Service
Provider. Pagination is not session based hence Consumers SHOULD Provider. Pagination is not session based hence Consumers SHOULD
never assume repeatable results. For example, a request for a list never assume repeatable results. For example, a request for a list
of 10 Resources beginning with a startIndex of 1 may return different of 10 Resources beginning with a startIndex of 1 may return different
results when repeated as a Resource in the original result could be results when repeated as a Resource in the original result could be
deleted or new ones could be added in-between requests. Pagination deleted or new ones could be added in-between requests. Pagination
parameters and general behavior are derived from the OpenSearch parameters and general behavior are derived from the OpenSearch
Protocol [3]. Protocol [3].
skipping to change at page 15, line 4 skipping to change at page 17, line 27
{ {
"totalResults":100, "totalResults":100,
"itemsPerPage":10, "itemsPerPage":10,
"startIndex":1, "startIndex":1,
"schemas":["urn:scim:schemas:core:1.0"], "schemas":["urn:scim:schemas:core:1.0"],
"Resources":[{ "Resources":[{
... ...
}] }]
} }
Given the example above, to continue paging set the startIndex to 11 Given the example above, to continue paging set the startIndex to 11
and re-fetch; i.e., /Users?startIndex=11&count=10 and re-fetch; i.e., /Users?startIndex=11&count=10
3.2.3. Querying Resources Using HTTP POST
Clients MAY execute queries without passing parameters on the URL by
using the HTTP POST verb combined with the '/.search' path extension.
The inclusion of '/.search' on the end of a valid SCIM endpoint SHALL
be used to indicate the HTTP POST verb is intended to be a query
operation.
To create a new search result set, a SCIM client sends an HTTP POST
request to the desired SCIM resource endpoint (ending in '/.search').
The body of the POST request MAY include any of the parameters as
defined in Section 3.2.2.
After receiving a HTTP POST request, a response is returned as
specified in Section 3.2.2.
[NOTE: See resourceType meta attribute in example below --> need to
update rest of document!]
The following example shows an HTTP POST Search request with search
parameters attributes, filter, and count included:
POST /.search
Host: example.com
Accept: application/json
Content-Type: application/json
Authorization: Bearer h480djs93hd8
Content-Length: ...
{
"schemas": ["urn:scim:schemas:core:1.0"],
"attributes":["displayName","username"],
"filter":"displayName sw \"smith\"",
"count":10
}
Figure 1: Example POST Search Request
A search response is shown with the first page of results. For
brevity reasons, only two matches are shown: one User and one Group.
HTTP/1.1 200 OK
Content-Type: application/json
Location: https://example.com/.search
{
"totalResults":100,
"itemsPerPage":10,
"startIndex":1,
"schemas":["urn:scim:schemas:core:1.0"],
"Resources":[
{
"meta":{
"location":
"https://example.com/Users/2819c223-7f76-413861904646",
"resourceType":"User",
"lastModified": ...
}
"username":"jsmith",
"displayName":"Smith, James"
},
{
"meta":{
"location":
"https://example.com/Groups/c8596b90-7539-4f20968d1908",
"resourceType":"Group",
"lastModified": ...
}
"displayName":"Smith Family"
},
...
]
}
Figure 2: Example POST Search Response
3.3. Modifying Resources 3.3. Modifying Resources
Resources can be modified in whole or in part via PUT or PATCH, Resources can be modified in whole or in part via PUT or PATCH,
respectively. Implementers MUST support PUT as specified in RFC2616 respectively. Implementers MUST support PUT as specified in RFC2616
. Resources such as Groups may be very large hence implementers . Resources such as Groups may be very large hence implementers
SHOULD support PATCH [4] to enable partial resource modifications. SHOULD support PATCH [4] to enable partial resource modifications.
3.3.1. Modifying with PUT 3.3.1. Modifying with PUT
PUT performs a full update. Consumers must retrieve the entire PUT performs a full update. Consumers must retrieve the entire
skipping to change at page 17, line 29 skipping to change at page 21, line 29
}, },
"emails":[ "emails":[
{ {
"value":"bjensen@example.com" "value":"bjensen@example.com"
}, },
{ {
"value":"babs@jensen.org" "value":"babs@jensen.org"
} }
], ],
"meta": { "meta": {
"resourceType","User",
"created":"2011-08-08T04:56:22Z", "created":"2011-08-08T04:56:22Z",
"lastModified":"2011-08-08T08:00:12Z", "lastModified":"2011-08-08T08:00:12Z",
"location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646", "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646",
"version":"W\/\"b431af54f0671a2\"" "version":"W\/\"b431af54f0671a2\""
} }
} }
3.3.2. Modifying with PATCH 3.3.2. Modifying with PATCH
PATCH is OPTIONAL. PATCH enables consumers to send only those PATCH is OPTIONAL. PATCH enables consumers to send only those
skipping to change at page 19, line 5 skipping to change at page 23, line 5
have a value Sub-Attribute or that have a non-unique value Sub- have a value Sub-Attribute or that have a non-unique value Sub-
Attribute are matched by comparing all Sub-Attribute values from Attribute are matched by comparing all Sub-Attribute values from
the PATCH request body to the Sub-Attribute values of the the PATCH request body to the Sub-Attribute values of the
Resource. A delete operation is ignored if the attribute's name Resource. A delete operation is ignored if the attribute's name
is in the meta.attributes list. If the requested value to delete is in the meta.attributes list. If the requested value to delete
does not match a unique value on the Resource the server MAY does not match a unique value on the Resource the server MAY
return a HTTP 400 error. return a HTTP 400 error.
The following example shows how to add a member to a group: The following example shows how to add a member to a group:
PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
Host: example.com Host: example.com
Accept: application/json Accept: application/json
Content-Type: application/json Content-Type: application/json
Authorization: Bearer h480djs93hd8 Authorization: Bearer h480djs93hd8
If-Match: W/"a330bc54f0671c9" If-Match: W/"a330bc54f0671c9"
{ {
"schemas": ["urn:scim:schemas:core:1.0"], "schemas": ["urn:scim:schemas:core:1.0"],
"members": [ "members": [
{ {
"display": "Babs Jensen", "display": "Babs Jensen",
"value": "2819c223-7f76-453a-919d-413861904646" "$ref": "https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646",
} "value": "2819c223-7f76-453a-919d-413861904646"
] }
} ]
}
The "display" Sub-Attribute in this request is optional since the The "display" Sub-Attribute in this request is optional since the
value attribute uniquely identifies the user to be added. If the value attribute uniquely identifies the user to be added. If the
user was already a member of this group, no changes should be made to user was already a member of this group, no changes should be made to
the Resource and a success response should be returned. The server the Resource and a success response should be returned. The server
responds with either the entire updated Group or no response body: responds with either the entire updated Group or no response body:
HTTP/1.1 204 No Content HTTP/1.1 204 No Content
Authorization: Bearer h480djs93hd8 Authorization: Bearer h480djs93hd8
ETag: W/"b431af54f0671a2" ETag: W/"b431af54f0671a2"
Location: "https://example.com/v1/Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce" Location: "https://example.com/v1/Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce"
The following example shows how to remove a member from a group. As The following example shows how to remove a member from a group. As
with the previous example, the "display" Sub-Attribute is optional. with the previous example, the "display" Sub-Attribute is optional.
If the user was not a member of this group, no changes should be made If the user was not a member of this group, no changes should be made
to the Resource and a success response should be returned. to the Resource and a success response should be returned.
Note that server responses have been omitted for the rest of the Note that server responses have been omitted for the rest of the
PATCH examples. PATCH examples.
PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
Host: example.com Host: example.com
Accept: application/json Accept: application/json
Content-Type: application/json Content-Type: application/json
Authorization: Bearer h480djs93hd8 Authorization: Bearer h480djs93hd8
If-Match: W/"a330bc54f0671c9" If-Match: W/"a330bc54f0671c9"
{ {
"schemas": ["urn:scim:schemas:core:1.0"], "schemas": ["urn:scim:schemas:core:1.0"],
"members": [ "members": [
{ {
"display": "Babs Jensen", "display": "Babs Jensen",
"value": "2819c223-7f76-453a-919d-413861904646" "$ref": "https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646",
"operation": "delete" "value": "2819c223-7f76-453a-919d-413861904646"
} "operation": "delete"
] }
} ]
}
The following example shows how to remove all members from a group: The following example shows how to remove all members from a group:
PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
Host: example.com Host: example.com
Accept: application/json Accept: application/json
Content-Type: application/json Content-Type: application/json
Authorization: Bearer h480djs93hd8 Authorization: Bearer h480djs93hd8
If-Match: W/"a330bc54f0671c9" If-Match: W/"a330bc54f0671c9"
skipping to change at page 21, line 5 skipping to change at page 25, line 5
"meta": { "meta": {
"attributes": [ "attributes": [
"members" "members"
] ]
} }
} }
The following example shows how to replace all of the members of a The following example shows how to replace all of the members of a
group with a different members list: group with a different members list:
PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
Host: example.com Host: example.com
Accept: application/json Accept: application/json
Content-Type: application/json Content-Type: application/json
Authorization: Bearer h480djs93hd8 Authorization: Bearer h480djs93hd8
If-Match: W/"a330bc54f0671c9" If-Match: W/"a330bc54f0671c9"
{ {
"schemas": ["urn:scim:schemas:core:1.0"], "schemas": ["urn:scim:schemas:core:1.0"],
"meta": { "meta": {
"attributes": [ "attributes": [
"members" "members"
] ]
}, },
"members": [ "members": [
{ {
"display": "Babs Jensen", "display": "Babs Jensen",
"value": "2819c223-7f76-453a-919d-413861904646" "$ref": "https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646",
}, "value": "2819c223-7f76-453a-919d-413861904646"
{ },
"display": "James Smith", {
"value": "08e1d05d-121c-4561-8b96-473d93df9210" "display": "James Smith",
} "$ref": "https://example.com/v1/Users/08e1d05d-121c-4561-8b96-473d93df9210",
] "value": "08e1d05d-121c-4561-8b96-473d93df9210"
} }
]
}
The following example shows how to add a member to and remove a The following example shows how to add a member to and remove a
member from a Group in a single request: member from a Group in a single request:
PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
Host: example.com Host: example.com
Accept: application/json Accept: application/json
Content-Type: application/json Content-Type: application/json
Authorization: Bearer h480djs93hd8 Authorization: Bearer h480djs93hd8
If-Match: W/"a330bc54f0671c9" If-Match: W/"a330bc54f0671c9"
{ {
"schemas": ["urn:scim:schemas:core:1.0"], "schemas": ["urn:scim:schemas:core:1.0"],
"members": [ "members": [
{ {
"display": "Babs Jensen", "display": "Babs Jensen",
"value": "2819c223-7f76-453a-919d-413861904646" "$ref": "https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646",
"operation": "delete" "value": "2819c223-7f76-453a-919d-413861904646"
}, "operation": "delete"
{ },
"display": "James Smith", {
"value": "08e1d05d-121c-4561-8b96-473d93df9210" "display": "James Smith",
} "$ref": "https://example.com/v1/Users/08e1d05d-121c-4561-8b96-473d93df9210",
] "value": "08e1d05d-121c-4561-8b96-473d93df9210"
} }
]
}
The following example shows how to change a User's primary email. If The following example shows how to change a User's primary email. If
the User already has the email address, it is made the primary the User already has the email address, it is made the primary
address and the current primary address (if present) is made non- address and the current primary address (if present) is made non-
primary. If the User does not already have the email address, it is primary. If the User does not already have the email address, it is
added and made the primary address. added and made the primary address.
PATCH /Users/2819c223-7f76-453a-919d-413861904646 PATCH /Users/2819c223-7f76-453a-919d-413861904646
Host: example.com Host: example.com
Accept: application/json Accept: application/json
skipping to change at page 25, line 39 skipping to change at page 29, line 44
deleted resource in conflict calculation. For example if a User deleted resource in conflict calculation. For example if a User
resource is deleted, a CREATE request for a User resource with the resource is deleted, a CREATE request for a User resource with the
same userName as the previously deleted resource should not fail with same userName as the previously deleted resource should not fail with
a 409 error due to userName conflict. a 409 error due to userName conflict.
DELETE /Users/2819c223-7f76-453a-919d-413861904646 DELETE /Users/2819c223-7f76-453a-919d-413861904646
Host: example.com Host: example.com
Authorization: Bearer h480djs93hd8 Authorization: Bearer h480djs93hd8
If-Match: W/"c310cd84f0281b7" If-Match: W/"c310cd84f0281b7"
Server Response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Example: Consumer attempt to retrieve the previously deleted User Example: Consumer attempt to retrieve the previously deleted User
GET /Users/2819c223-7f76-453a-919d-413861904646 GET /Users/2819c223-7f76-453a-919d-413861904646
Host: example.com Host: example.com
Authorization: Bearer h480djs93hd8 Authorization: Bearer h480djs93hd8
Server Response:
HTTP/1.1 404 NOT FOUND HTTP/1.1 404 NOT FOUND
{ {
"Errors":[ "Errors":[
{ {
"description":"Resource 2819c223-7f76-453a-919d-413861904646 not found", "description":"Resource 2819c223-7f76-453a-919d-413861904646 not found",
"code":"404" "code":"404"
} }
] ]
} }
skipping to change at page 35, line 23 skipping to change at page 39, line 23
"displayName": "Tour Guides", "displayName": "Tour Guides",
"meta": { "meta": {
"created":"2011-08-01T18:29:49.793Z", "created":"2011-08-01T18:29:49.793Z",
"lastModified":"2011-08-01T20:31:02.315Z", "lastModified":"2011-08-01T20:31:02.315Z",
"location": "https://example.com/v1/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a", "location": "https://example.com/v1/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a",
"version": "W\/\"lha5bbazU3fNvfe5\"" "version": "W\/\"lha5bbazU3fNvfe5\""
}, },
"members": [ "members": [
{ {
"value": "92b725cd-9465-4e7d-8c16-01f8e146b87a", "value": "92b725cd-9465-4e7d-8c16-01f8e146b87a",
"type": "user" "$ref": "https://example.com/v1/Users/92b725cd-9465-4e7d-8c16-01f8e146b87a",
"type": "User"
} }
] ]
} }
Extensions that include references to other Resources MUST be handled Extensions that include references to other Resources MUST be handled
in the same way by the Service Provider. The following example uses in the same way by the Service Provider. The following example uses
the bulkId attribute within the enterprise extension managerId the bulkId attribute within the enterprise extension managerId
attribute. attribute.
POST /v1/Bulk POST /v1/Bulk
skipping to change at page 39, line 36 skipping to change at page 43, line 36
"displayName": "Group A", "displayName": "Group A",
"meta": { "meta": {
"created":"2011-08-01T18:29:49.793Z", "created":"2011-08-01T18:29:49.793Z",
"lastModified":"2011-08-01T18:29:51.135Z", "lastModified":"2011-08-01T18:29:51.135Z",
"location":"https://example.com/v1/Groups/c3a26dd3-27a0-4dec-a2ac-ce211e105f97", "location":"https://example.com/v1/Groups/c3a26dd3-27a0-4dec-a2ac-ce211e105f97",
"version":"W\/\"mvwNGaxB5SDq074p\"" "version":"W\/\"mvwNGaxB5SDq074p\""
}, },
"members": [ "members": [
{ {
"value": "6c5bb468-14b2-4183-baf2-06d523e03bd3", "value": "6c5bb468-14b2-4183-baf2-06d523e03bd3",
"type": "group" "$ref": "https://example.com/v1/Groups/6c5bb468-14b2-4183-baf2-06d523e03bd3",
"type": "Group"
} }
] ]
}, },
{ {
"id": "6c5bb468-14b2-4183-baf2-06d523e03bd3", "id": "6c5bb468-14b2-4183-baf2-06d523e03bd3",
"schemas": [ "schemas": [
"urn:scim:schemas:core:1.0" "urn:scim:schemas:core:1.0"
], ],
"displayName": "Group B", "displayName": "Group B",
"meta": { "meta": {
"created":"2011-08-01T18:29:50.873Z", "created":"2011-08-01T18:29:50.873Z",
"lastModified":"2011-08-01T18:29:50.873Z", "lastModified":"2011-08-01T18:29:50.873Z",
"location":"https://example.com/v1/Groups/6c5bb468-14b2-4183-baf2-06d523e03bd3", "location":"https://example.com/v1/Groups/6c5bb468-14b2-4183-baf2-06d523e03bd3",
"version":"W\/\"wGB85s2QJMjiNnuI\"" "version":"W\/\"wGB85s2QJMjiNnuI\""
}, },
"members": [ "members": [
{ {
"value": "c3a26dd3-27a0-4dec-a2ac-ce211e105f97", "value": "c3a26dd3-27a0-4dec-a2ac-ce211e105f97",
"type": "group" "$ref": "https://example.com/v1/Groups/c3a26dd3-27a0-4dec-a2ac-ce211e105f97",
"type": "Group"
} }
] ]
} }
] ]
} }
The Service Provider MUST define the maximum number of operations and The Service Provider MUST define the maximum number of operations and
maximum payload size a Consumer may send in a single request. If maximum payload size a Consumer may send in a single request. If
either limits are exceeded the Service Provider MUST return the HTTP either limits are exceeded the Service Provider MUST return the HTTP
response code 413 Request Entity Too Large. The returned response response code 413 Request Entity Too Large. The returned response
skipping to change at page 41, line 14 skipping to change at page 45, line 14
3.6. Data Input/Output Formats 3.6. Data Input/Output Formats
Consumers MUST specify the format in which the data is submitted via Consumers MUST specify the format in which the data is submitted via
the HTTP header content-type and MAY specify the desired response the HTTP header content-type and MAY specify the desired response
data format via an HTTP Accept Header; e.g.,"Accept: application/ data format via an HTTP Accept Header; e.g.,"Accept: application/
json" or via URI suffix; e.g., json" or via URI suffix; e.g.,
GET /Users/2819c223-7f76-453a-919d-413861904646.json GET /Users/2819c223-7f76-453a-919d-413861904646.json
Host: example.com Host: example.com
GET /Users/2819c223-7f76-453a-919d-413861904646.xml
Host: example.com
Service Providers MUST support the Accept Headers "Accept: Service Providers MUST support the Accept Headers "Accept:
application/json" for JSON [5] and, if supported, "Accept: application/json" for JSON [5]. The format defaults to JSON if no
application/xml" for XML [6]. The format defaults to JSON if no format is specified.
format is specified. The data structure returned is equivalent in
both formats; the only difference is in the encoding of the data.
Singular attributes are encoded as string name-value-pairs in JSON; Singular attributes are encoded as string name-value-pairs in JSON;
e.g., e.g.,
"attribute": "value" "attribute": "value"
and elements in XML; e.g.,
<attribute>value</attribute>
Multi-valued attributes in JSON are encoded as arrays; e.g., Multi-valued attributes in JSON are encoded as arrays; e.g.,
"attributes": [ "value1", "value2" ] "attributes": [ "value1", "value2" ]
and repeated tags in XML; e.g.,
<attributes>value1</attributes>
<attributes>value2</attributes>
Elements with nested elements are represented as objects in JSON; Elements with nested elements are represented as objects in JSON;
e.g, e.g,
"attribute": { "subattribute1": "value1", "subattribute2": "value2" } "attribute": { "subattribute1": "value1", "subattribute2": "value2" }
and repeated tags in XML; e.g.,
<attribute>
<subattribute1>value1</subattribute1>
<subattribute2>value2</subattribute2>
</attribute>
3.7. Additional retrieval query parameters 3.7. Additional retrieval query parameters
Consumers MAY request a partial Resource representation on any Consumers MAY request a partial Resource representation on any
operation that returns a Resource within the response by specifying operation that returns a Resource within the response by specifying
the URL query parameter 'attributes'. When specified, each Resource the URL query parameter 'attributes'. When specified, each Resource
returned MUST contain the minimal set of Resource attributes and, returned MUST contain the minimal set of Resource attributes and,
MUST contain no other attributes or Sub-Attributes than those MUST contain no other attributes or Sub-Attributes than those
explicitly requested. The query parameter attributes value is a explicitly requested. The query parameter attributes value is a
comma separated list of Resource attribute names in standard, comma separated list of Resource attribute names in standard,
attribute notation (Section 3.8) form (e.g. userName, name, emails). attribute notation (Section 3.8) form (e.g. userName, name, emails).
skipping to change at page 43, line 15 skipping to change at page 46, line 41
attribute 'age' defined in 'urn:hr:schemas:user' is fully encoded as attribute 'age' defined in 'urn:hr:schemas:user' is fully encoded as
'urn:hr:schemas:user:age'. A Complex attributes' Sub-Attributes are 'urn:hr:schemas:user:age'. A Complex attributes' Sub-Attributes are
referenced via nested, dot ('.') notation; i.e., {urn}:{Attribute referenced via nested, dot ('.') notation; i.e., {urn}:{Attribute
name}.{Sub-Attribute name}. For example, the fully qualified path name}.{Sub-Attribute name}. For example, the fully qualified path
for a User's givenName is urn:scim:schemas:core:1.0:name.givenName for a User's givenName is urn:scim:schemas:core:1.0:name.givenName
All facets (URN, attribute and Sub-Attribute name) of the fully All facets (URN, attribute and Sub-Attribute name) of the fully
encoded Attribute name are case insensitive. encoded Attribute name are case insensitive.
3.9. HTTP Response Codes 3.9. HTTP Response Codes
The SCIM Protocol uses the response status codes defined in HTTP [7] The SCIM Protocol uses the response status codes defined in HTTP [6]
to indicate operation success or failure. In addition to returning a to indicate operation success or failure. In addition to returning a
HTTP response code implementers MUST return the errors in the body of HTTP response code implementers MUST return the errors in the body of
the response in the client requested format containing the error the response in the client requested format containing the error
response and, per the HTTP specification, human-readable response and, per the HTTP specification, human-readable
explanations. Implementers SHOULD handle the identified errors as explanations. Implementers SHOULD handle the identified errors as
described below. described below.
+--------------+---------------------------+------------------------+ +--------------+---------------------------+------------------------+
| Code | Applicability | Suggested Explanation | | Code | Applicability | Suggested Explanation |
+--------------+---------------------------+------------------------+ +--------------+---------------------------+------------------------+
skipping to change at page 46, line 34 skipping to change at page 50, line 30
3.12. HTTP Method Overloading 3.12. HTTP Method Overloading
In recognition that some clients, servers and firewalls prevent PUT, In recognition that some clients, servers and firewalls prevent PUT,
PATCH and DELETE operations a client MAY override the POST operation PATCH and DELETE operations a client MAY override the POST operation
by specifying the custom header "X-HTTP-Method-Override" with the by specifying the custom header "X-HTTP-Method-Override" with the
desired PUT, PATCH, DELETE operation. For example: desired PUT, PATCH, DELETE operation. For example:
POST /Users/2819c223-7f76-453a-919d-413861904646 POST /Users/2819c223-7f76-453a-919d-413861904646
X-HTTP-Method-Override: DELETE X-HTTP-Method-Override: DELETE
4. Security Considerations 4. Multi-Tenancy
A single Service Provider may expose the SCIM protocol to multiple
Consumers. Depending on the nature of the service, the Consumers may
have authority to access and alter Resources initially created by
other Consumers. Alternatively, Consumers may expect to access
disjoint sets of Resources, and may expect that their resources are
inaccessible by other Consumers. These scenarios are called "multi-
tenancy", where each Consumer is understood to be or represent a
"tenant" of the Service Provider. Consumers may also be multi-
tenanted.
The following common cases may occur:
1. All Consumers share all Resources (no tenancy)
2. Each single Consumer creates and accesses a private subset of
Resources (1 Consumer:1 Tenant)
3. Sets of Consumers share sets of Resources (M Consumers:1 Tenant)
4. One Consumer to Multiple Tenants (1 Consumer:M Tenants)
Service Providers may implement any subset of the above cases.
Multi-Tenancy is OPTIONAL. The SCIM protocol does not define a
scheme for multi-tenancy.
The SCIM protocol does not prescribe the mechanisms whereby Consumers
and Service Providers interact for:
o Registering or provisioning Tenants
o Associating a subset of Consumers with a subset of the Tenants
o Indicating which tenant is associated with the data in a request
or response, or indicating which Tenant is the subject of a query
o Implementers are encouraged to use mechanisms which comply with
RESTful conventions.
4.1. Associating Consumers to Tenants
The Service Provider MAY use the authentication mechanism (Section 2)
to determine the identity of the Consumer, and thus infer the
associated Tenant.
For implementations where a Consumer is associated with more than one
Tenant, the Service Provider MAY use one of the following methods for
explicit specification of the Tenant.
If any of these methods of allowing the Consumer to explicitly
specify the Tenant are employed, the Service Provider should ensure
that access controls are in place to prevent or allow cross-tenant
use cases.
The Service Provider should consider precedence in cases where a
Consumer may explicitly specify a Tenant while being implicitly
associated with a different Tenant.
4.1.1. URL Prefix Example
https://www.example.com/Tenants/{tenant_id}/v1/Users
4.1.2. Subdomain Example
https://{tenant_id}.example.com/v1/Groups
4.1.3. HTTP Header
The Service Provider may recognize a {tenant_id} provided by the
Consumer in the HTTP Header "SCIM_TENANT_ID" as the indicator of the
desired target Tenant.
In all of these methods, the {tenant_id} is a unique identifier for
the Tenant as defined by the Service Provider.
4.2. SCIM Identifiers with Multiple Tenants
Considerations for a Multi-Tenant Implementation:
The Service Provider may choose to implement SCIM ids which are
unique across all Resources for all Tenants, but this is not
required.
The externalId, defined by the Consumer, is required to be unique
ONLY within the Resources associated with the associated Tenant.
5. Security Considerations
The SCIM Protocol is based on HTTP and thus subject to the security The SCIM Protocol is based on HTTP and thus subject to the security
considerations found in Section 15 of [RFC2616]. SCIM Resources considerations found in Section 15 of [RFC2616]. SCIM Resources
(e.g., Users and Groups) can contain sensitive information. (e.g., Users and Groups) can contain sensitive information.
Therefore, SCIM Consumers and Service Providers MUST implement TLS. Therefore, SCIM Consumers and Service Providers MUST implement TLS.
Which version(s) ought to be implemented will vary over time, and Which version(s) ought to be implemented will vary over time, and
depend on the widespread deployment and known security depend on the widespread deployment and known security
vulnerabilities at the time of implementation. At the time of this vulnerabilities at the time of implementation. At the time of this
writing, TLS version 1.2 [RFC5246 [8]] is the most recent version, writing, TLS version 1.2 [RFC5246 [7]] is the most recent version,
but has very limited actual deployment, and might not be readily but has very limited actual deployment, and might not be readily
available in implementation toolkits. TLS version 1.0 [RFC2246 [8]] available in implementation toolkits. TLS version 1.0 [RFC2246 [7]]
is the most widely deployed version, and will give the broadest is the most widely deployed version, and will give the broadest
interoperability. interoperability.
5. Contributors 6. Contributors
Samuel Erdtman (samuel@erdtman.se) Samuel Erdtman (samuel@erdtman.se)
Patrick Harding (pharding@pingidentity.com) Patrick Harding (pharding@pingidentity.com)
6. Acknowledgments 7. Acknowledgments
The editor would like to thank the participants in the the SCIM The editor would like to thank the participants in the the SCIM
working group for their support of this specification. working group for their support of this specification.
Authors' Addresses Authors' Addresses
Trey Drake (editor) Trey Drake (editor)
UnboundID UnboundID
Email: trey.drake@unboundid.com Email: trey.drake@unboundid.com
 End of changes. 43 change blocks. 
148 lines changed or deleted 354 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/