draft-ietf-scim-api-17.txt   draft-ietf-scim-api-18.txt 
Network Working Group P. Hunt, Ed. Network Working Group P. Hunt, Ed.
Internet-Draft Oracle Internet-Draft Oracle
Intended status: Standards Track K. Grizzle Intended status: Standards Track K. Grizzle
Expires: October 26, 2015 SailPoint Expires: November 12, 2015 SailPoint
M. Ansari M. Ansari
Cisco Cisco
E. Wahlstroem E. Wahlstroem
Nexus Technology Nexus Technology
C. Mortimore C. Mortimore
Salesforce Salesforce
April 24, 2015 May 11, 2015
System for Cross-Domain Identity Management: Protocol System for Cross-Domain Identity Management: Protocol
draft-ietf-scim-api-17 draft-ietf-scim-api-18
Abstract Abstract
The System for Cross-Domain Identity Management (SCIM) specification The System for Cross-Domain Identity Management (SCIM) specification
is an HTTP based protocol that makes managing identities in multi- is an HTTP based protocol that makes managing identities in multi-
domain scenarios easier to support through a standardized service. domain scenarios easier to support through a standardized service.
Examples include but are not limited to enterprise to cloud service Examples include but are not limited to enterprise to cloud service
providers, and inter-cloud based scenarios. The specification suite providers, and inter-cloud based scenarios. The specification suite
seeks to build upon experience with existing schemas and deployments, seeks to build upon experience with existing schemas and deployments,
placing specific emphasis on simplicity of development and placing specific emphasis on simplicity of development and
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 26, 2015. This Internet-Draft will expire on November 12, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 . . . . . . . . . . . . . . . . . . 3
1.1. Intended Audience . . . . . . . . . . . . . . . . . . . . 3 1.1. Intended Audience . . . . . . . . . . . . . . . . . . . . 3
1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 4
1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Authentication and Authorization . . . . . . . . . . . . . . 4 2. Authentication and Authorization . . . . . . . . . . . . . . 5
3. SCIM Protocol . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Use of Tokens as Authorizations . . . . . . . . . . . . . 7
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Anonymous Requests . . . . . . . . . . . . . . . . . . . 7
3.2. SCIM Endpoints . . . . . . . . . . . . . . . . . . . . . 6 3. SCIM Protocol . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Creating Resources . . . . . . . . . . . . . . . . . . . 8 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 7
3.3.1. Resource Types . . . . . . . . . . . . . . . . . . . 10 3.2. SCIM Endpoints . . . . . . . . . . . . . . . . . . . . . 9
3.4. Retrieving Resources . . . . . . . . . . . . . . . . . . 10 3.3. Creating Resources . . . . . . . . . . . . . . . . . . . 10
3.4.1. Retrieving a known Resource . . . . . . . . . . . . . 10 3.3.1. Resource Types . . . . . . . . . . . . . . . . . . . 13
3.4.2. Query Resources . . . . . . . . . . . . . . . . . . . 11 3.4. Retrieving Resources . . . . . . . . . . . . . . . . . . 13
3.4.3. Querying Resources Using HTTP POST . . . . . . . . . 22 3.4.1. Retrieving a known Resource . . . . . . . . . . . . . 13
3.5. Modifying Resources . . . . . . . . . . . . . . . . . . . 25 3.4.2. Query Resources . . . . . . . . . . . . . . . . . . . 14
3.5.1. Replacing with PUT . . . . . . . . . . . . . . . . . 26 3.4.3. Querying Resources Using HTTP POST . . . . . . . . . 25
3.5.2. Modifying with PATCH . . . . . . . . . . . . . . . . 28 3.5. Modifying Resources . . . . . . . . . . . . . . . . . . . 28
3.6. Deleting Resources . . . . . . . . . . . . . . . . . . . 42 3.5.1. Replacing with PUT . . . . . . . . . . . . . . . . . 29
3.7. Bulk Operations . . . . . . . . . . . . . . . . . . . . . 43 3.5.2. Modifying with PATCH . . . . . . . . . . . . . . . . 31
3.7.1. Circular Reference Processing . . . . . . . . . . . . 45 3.6. Deleting Resources . . . . . . . . . . . . . . . . . . . 45
3.7.2. BulkdId Temporary Identifiers . . . . . . . . . . . . 48 3.7. Bulk Operations . . . . . . . . . . . . . . . . . . . . . 46
3.7.3. Response and Error Handling . . . . . . . . . . . . . 52 3.7.1. Circular Reference Processing . . . . . . . . . . . . 48
3.7.4. Maximum Operations . . . . . . . . . . . . . . . . . 58 3.7.2. BulkdId Temporary Identifiers . . . . . . . . . . . . 51
3.8. Data Input/Output Formats . . . . . . . . . . . . . . . . 59 3.7.3. Response and Error Handling . . . . . . . . . . . . . 55
3.9. Additional Operation Response Parameters . . . . . . . . 60 3.7.4. Maximum Operations . . . . . . . . . . . . . . . . . 61
3.10. Attribute Notation . . . . . . . . . . . . . . . . . . . 61 3.8. Data Input/Output Formats . . . . . . . . . . . . . . . . 62
3.11. "/Me" Authenticated Subject Alias . . . . . . . . . . . . 61 3.9. Additional Operation Response Parameters . . . . . . . . 63
3.12. HTTP Status and Error Response Handling . . . . . . . . . 62 3.10. Attribute Notation . . . . . . . . . . . . . . . . . . . 64
3.13. API Versioning . . . . . . . . . . . . . . . . . . . . . 66 3.11. "/Me" Authenticated Subject Alias . . . . . . . . . . . . 64
3.14. Versioning Resources . . . . . . . . . . . . . . . . . . 66 3.12. HTTP Status and Error Response Handling . . . . . . . . . 65
4. Service Provider Configuration Endpoints . . . . . . . . . . 68 3.13. API Versioning . . . . . . . . . . . . . . . . . . . . . 69
5. Preparation and Comparison of Internationalized Strings . . . 70 3.14. Versioning Resources . . . . . . . . . . . . . . . . . . 69
6. Multi-Tenancy . . . . . . . . . . . . . . . . . . . . . . . . 71 4. Service Provider Configuration Endpoints . . . . . . . . . . 71
6.1. Associating Clients to Tenants . . . . . . . . . . . . . 71 5. Preparation and Comparison of Internationalized Strings . . . 73
6.2. SCIM Identifiers with Multiple Tenants . . . . . . . . . 72 6. Multi-Tenancy . . . . . . . . . . . . . . . . . . . . . . . . 74
7. Security Considerations . . . . . . . . . . . . . . . . . . . 72 6.1. Associating Clients to Tenants . . . . . . . . . . . . . 74
7.1. TLS Support . . . . . . . . . . . . . . . . . . . . . . . 72 6.2. SCIM Identifiers with Multiple Tenants . . . . . . . . . 75
7.2. Disclosure of Sensitive Information in URIs . . . . . . . 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 75
7.3. Anonymous Requests . . . . . . . . . . . . . . . . . . . 73 7.1. HTTP Considerations . . . . . . . . . . . . . . . . . . . 75
7.4. HTTP Considerations . . . . . . . . . . . . . . . . . . . 74 7.2. TLS Support Considerations . . . . . . . . . . . . . . . 76
7.5. Secure Storage and Handling of Sensitive Data . . . . . . 74 7.3. Authorization Token Considerations . . . . . . . . . . . 76
7.6. Case Insensitive Comparison & International Languages . . 75 7.4. Bearer and Cookie Considerations . . . . . . . . . . . . 76
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75 7.5. Privacy Considerations . . . . . . . . . . . . . . . . . 77
8.1. Media Type Registration . . . . . . . . . . . . . . . . . 75 7.5.1. Personal Information . . . . . . . . . . . . . . . . 77
8.2. SCIM Message URI Registry . . . . . . . . . . . . . . . . 76 7.5.2. Disclosure of Sensitive Information in URIs . . . . . 77
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 7.6. Anonymous Requests . . . . . . . . . . . . . . . . . . . 78
9.1. Normative References . . . . . . . . . . . . . . . . . . 77 7.7. Secure Storage and Handling of Sensitive Data . . . . . . 78
9.2. Informative References . . . . . . . . . . . . . . . . . 78 7.8. Case Insensitive Comparison & International Languages . . 79
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 79 8.1. Media Type Registration . . . . . . . . . . . . . . . . . 79
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 79 8.2. SCIM Message URI Registry . . . . . . . . . . . . . . . . 81
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 81
9.1. Normative References . . . . . . . . . . . . . . . . . . 81
9.2. Informative References . . . . . . . . . . . . . . . . . 83
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 84
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 84
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 84
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 89
1. Introduction and Overview 1. Introduction and Overview
The SCIM Protocol is an application-level, HTTP protocol for The SCIM Protocol is an application-level, HTTP protocol for
provisioning and managing identity data on the web and in cross- provisioning and managing identity data on the web and in cross-
domain environments such as enterprise to cloud, or inter-cloud domain environments such as enterprise to cloud, or inter-cloud
scenarios. The protocol supports creation, modification, retrieval, scenarios. The protocol supports creation, modification, retrieval,
and discovery of core identity resources such as Users and Groups, as and discovery of core identity resources such as Users and Groups, as
well as custom resources and resource extensions. well as custom resources and resource extensions.
skipping to change at page 4, line 38 skipping to change at page 4, line 45
parameters as part of forming the request. The base URI most parameters as part of forming the request. The base URI most
often is a URL which most often consists of the "https" protocol often is a URL which most often consists of the "https" protocol
scheme, a domain name and some initial path [RFC3986]. Example: scheme, a domain name and some initial path [RFC3986]. Example:
"https://example.com/scim/" "https://example.com/scim/"
For readability, all examples in this document are expressed For readability, all examples in this document are expressed
assuming the SCIM service root and the server root are the same assuming the SCIM service root and the server root are the same
(no path pre-fix). It is expected that SCIM servers MAY be (no path pre-fix). It is expected that SCIM servers MAY be
deployed using any URI path prefix. For example, a SCIM server deployed using any URI path prefix. For example, a SCIM server
might be have a prefix of "https://example.com/", or might be have a prefix of "https://example.com/", or
"https://example.com/scim/tenancypath/". Additionally client MAY "https://example.com/scim/tenancypath/". Additionally a client
also apply a version number to the server root prefix (see MAY also apply a version number to the server root prefix (see
Section 3.13 ). Section 3.13 ).
2. Authentication and Authorization 2. Authentication and Authorization
Because SCIM builds on the HTTP protocol, it does not itself define a SCIM Protocol is based upon HTTP and does not itself define a SCIM
scheme for authentication and authorization. SCIM depends on specific scheme for authentication and authorization. SCIM depends
standard HTTP authentication schemes. Implementers SHOULD support on the use of TLS and/or standard HTTP authentication and
existing authentication/authorization schemes. In particular, OAuth2 authorization schemes as per [RFC7235]. For example, the following
(see [RFC6749], [RFC6750]) is RECOMMENDED. Appropriate security methodologies could be used among others:
considerations of the selected authentication and authorization
schemes SHOULD be taken. Because this protocol uses HTTP response
status codes as the primary means of reporting the result of a
request, servers are advised to respond to unauthorized or
unauthenticated requests using the 401 response code in accordance
with Section 3.1 of [RFC7235].
All examples show an OAuth2 bearer token [RFC6750] (though it is not TLS Client Authentication
required); e.g., The SCIM service provider MAY request TLS client authentication
(also known as mutual authentication). See Section 7.3 [RFC5246].
GET /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1 HTTP Origin-Bound Authentication (HOBA) is a variation on TLS
Host: example.com client authentication and uses a digital-signature-based design
Authorization: Bearer h480djs93hd8 for an HTTP authentication method (see [RFC7486]). The design can
also be used in JavaScript-based authentication embedded in HTML.
HOBA is an alternative to HTTP authentication schemes that require
passwords and therefore avoids all problems related to passwords,
such as leakage of server-side password databases.
Bearer Tokens
Bearer tokens [RFC6750] MAY be used when combined with TLS and a
token framework such as OAuth 2.0 [RFC6749]. Tokens that are
issued based on weak or no authentication of authorizing users
and/or OAuth clients SHOULD NOT be used. See Section 7.4 for
security considerations regarding the use of bearer tokens in
SCIM. While bearer tokens most often represent an authorization,
it is assumed that the authorization was based upon a successful
authentication of the SCIM client. Accordingly the SCIM service
provider must have a method for validating, parsing, and or
introspecting the bearer token for the relevant authentication and
authorization information. The method for this is assumed to be
defined by the token issuing system and is beyond the scope of
this specification.
POP Tokens
A proof-of-possession token demonstrates the presenter of the
token possesses a particular key and that the recipient can
cryptographically confirm proof-of-possession of the key by the
presenter. This property is sometimes also described as the
presenter being a holder-of-key. See OAuth 2.0 Proof-of-
Possession Security Architecture [I-D.ietf-oauth-pop-architecture]
for an example of such a token and its use.
Cookies
Javascript clients MAY assert HTTP cookies over TLS that contain
an authentication state that is understood by the SCIM service
provider (see [RFC6265]). An example of this is scenarios where
web-form authentication has taken place with the user and HTTP
cookies were set representing the authentication state. For the
purposes of SCIM, the security considerations in Section 7.4
apply.
Basic Authentication
Usage of basic authentication should be avoided due to its use of
a single factor that is based upon a relatively static, symmetric
secret. Implementers SHOULD combine the use of basic
authentication with other factors. The security considerations of
HTTP BASIC, are well documented in
[I-D.ietf-httpauth-basicauth-update], and therefore implementers
are encouraged to prefer stronger authentication methods.
Designating the specific methods of authentication and
authorization are out-of-scope for SCIM, however this information
is provided as a resource to implementers.
As per Section 4.1 of [RFC7235], a SCIM service provider SHALL
indicate supported HTTP authentication schemes via the "WWW-
Authenticate" header.
For all of the above methodologies, the SCIM service provider MUST be
able to map the authenticated client to an access control policy in
order to determine the client's authorization to retrieve and update
SCIM resources. For example, while a browser session may have been
established via HTTP cookie or TLS client authentication, the unique
client MUST be mapped to a security subject (e.g., User). The
authorization model and the process by which this is done is beyond
the scope of this specification.
When processing requests, the service provider SHOULD consider the When processing requests, the service provider SHOULD consider the
subject performing the request and whether the action is appropriate subject performing the request and whether the action is appropriate
given the subject and the resource affected by the request. The given the subject and the resource affected by the request. The
subject performing the request is usually determined from the subject performing the request is usually determined directly or
"Authorization" header present in the request. indirectly from the "Authorization" header present in the request.
For example, a subject MAY be permitted to retrieve and update their
own "User" resource, but will normally have restricted ability to
access resources associated with other Users. In other cases, the
SCIM service provider might only grant access to a subject's own
associated "User" resource (e.g., for the purpose of updating
personal contact attributes).
For illustrative purposes only, examples show an OAuth2 bearer token
value [RFC6750] in the authorization header; e.g.,
GET /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1
Host: example.com
Authorization: Bearer h480djs93hd8
This is not intended to imply that bearer tokens are preferred.
However, the use of bearer tokens in the specification does reflect
common implementation practice.
2.1. Use of Tokens as Authorizations
When using bearer tokens or proof-of-possession tokens that represent
an authorization grant such as issued by OAuth (see [RFC6749]),
implementers SHOULD consider the type of authorization granted, any
authorized scopes (see Section 3.3 of [RFC6749]), and the security
subject(s) that SHOULD be mapped from the authorization when
considering local access control rules. Section 6 of the OAuth
Assertions draft [I-D.ietf-oauth-assertions], documents common
scenarios for authorization including:
o Clients using an assertion to authenticate and/or act on behalf of
itself
o Clients acting on behalf of a user.
o A Client acting on behalf of an anonymous user (e.g., see next
section).
Implementers SHOULD take into account the threats and countermeasures
documented in the security considerations for the use of client
authorizations see Section 8 of [I-D.ietf-oauth-assertions].
2.2. Anonymous Requests
In some SCIM deployments it MAY be acceptable to permit
unauthenticated (anonymous) requests. For example, a user self-
registration request where the service provider chooses to accept a
SCIM Create request (see Section 3.3) from an anonymous client. See
Section 7.6, for security considerations regarding anonymous
requests.
3. SCIM Protocol 3. SCIM Protocol
3.1. Introduction 3.1. Introduction
SCIM is a protocol that is based on HTTP protocol [RFC7230]. Along SCIM is a protocol that is based on HTTP protocol [RFC7230]. Along
with HTTP headers and URIs, SCIM uses JSON [RFC7159] payloads to with HTTP headers and URIs, SCIM uses JSON [RFC7159] payloads to
convey both SCIM resources, as well as protocol specific payload convey both SCIM resources, as well as protocol specific payload
messages that convey request parameters and response information such messages that convey request parameters and response information such
as errors. Both resources and messages are passed in the form of as errors. Both resources and messages are passed in the form of
skipping to change at page 7, line 35 skipping to change at page 10, line 23
POST (Section 3.3), Modify Groups POST (Section 3.3), Modify Groups
PUT (Section 3.5.1), PUT (Section 3.5.1),
PATCH (Section 3.5.2), PATCH (Section 3.5.2),
DELETE (Section 3.6) DELETE (Section 3.6)
Self /Me GET, POST, PUT, PATCH, Alias for operations Self /Me GET, POST, PUT, PATCH, Alias for operations
DELETE (Section 3.11) against a resource DELETE (Section 3.11) against a resource
mapped to an mapped to an
authenticated authenticated
Subject (e.g., Subject (e.g.,
User). User).
Service /ServiceProvider GET (Section 4) Retrieve service Service /ServiceProvider GET (Section 4) Retrieve Service
Provider Config provider's Provider Config Provider's
Config configuration Config configuration
Resource /ResourceTypes GET (Section 4) Retrieve supported Resource /ResourceTypes GET (Section 4) Retrieve supported
Type resource types Type resource types
Schema /Schemas GET (Section 4) Retrieve one or more Schema /Schemas GET (Section 4) Retrieve one or more
supported schemas. supported schemas.
Bulk /Bulk POST (Section 3.7) Bulk updates to one Bulk /Bulk POST (Section 3.7) Bulk updates to one
or more resources or more resources
Search [prefix]/.search POST (Section 3.4.3) Search from system Search [prefix]/.search POST (Section 3.4.3) Search from system
root or within a root or within a
resource endpoint resource endpoint
skipping to change at page 10, line 17 skipping to change at page 13, line 17
When adding a resource to a specific endpoint, the meta attribute When adding a resource to a specific endpoint, the meta attribute
"resourceType" SHALL be set by the HTTP service provider to the "resourceType" SHALL be set by the HTTP service provider to the
corresponding resource type for the endpoint. For example, "/Users" corresponding resource type for the endpoint. For example, "/Users"
will set "resourceType" to "User", and "/Groups" will set will set "resourceType" to "User", and "/Groups" will set
"resourceType" to "Group". "resourceType" to "Group".
3.4. Retrieving Resources 3.4. Retrieving Resources
Resources are retrieved via opaque, unique URLs or via Query (see Resources are retrieved via opaque, unique URLs or via Query (see
Section 3.4.2). The attributes returned are defined in the server's Section 3.4.2). The attributes returned are defined in the server's
attribute schema (see Section 10 [I-D.ietf-scim-core-schema]) and attribute schema (see Section 8.7 [I-D.ietf-scim-core-schema]) and
request parameters (see Section 3.9). By default, resource request parameters (see Section 3.9). By default, resource
attributes returned in a response are those whose schema "returned" attributes returned in a response are those whose schema "returned"
setting is "always" or "default". setting is "always" or "default".
3.4.1. Retrieving a known Resource 3.4.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
resource endpoint; e.g., "/Users/{id}" or "/Groups/{id}", or resource endpoint; e.g., "/Users/{id}" or "/Groups/{id}", or
"/Schemas/{id}". "/Schemas/{id}".
skipping to change at page 13, line 42 skipping to change at page 16, line 42
For filtered attributes that are not part of a particular resource For filtered attributes that are not part of a particular resource
type, the service provider SHALL treat the attribute as if there is type, the service provider SHALL treat the attribute as if there is
no attribute value. For example, a presence or equality filter for no attribute value. For example, a presence or equality filter for
an undefined attribute evaluates as FALSE. an undefined attribute evaluates as FALSE.
3.4.2.2. Filtering 3.4.2.2. Filtering
Filtering is an OPTIONAL parameter for SCIM service providers. Filtering is an OPTIONAL parameter for SCIM service providers.
Clients MAY discover service provider filter capabilities by looking Clients MAY discover service provider filter capabilities by looking
at the "filter" attribute of the "ServiceProviderConfig" (see at the "filter" attribute of the "ServiceProviderConfig" (see
Section 8 [I-D.ietf-scim-core-schema]). Clients MAY request a subset Section 5 and Section 8.5 [I-D.ietf-scim-core-schema]). Clients MAY
of resources by specifying the "filter" query parameter containing a request a subset of resources by specifying the "filter" query
filter expression. When specified only those resources matching the parameter containing a filter expression. When specified only those
filter expression SHALL be returned. The expression language that is resources matching the filter expression SHALL be returned. The
used in the filter parameter supports references to attributes and expression language that is used in the filter parameter supports
literals. references to attributes and literals.
Attribute names and attribute operators used in filters are case Attribute names and attribute operators used in filters are case
insensitive. For example, the following two expressions will insensitive. For example, the following two expressions will
evaluate to the same logical value: evaluate to the same logical value:
filter=userName Eq "john" filter=userName Eq "john"
filter=Username eq "john" filter=Username eq "john"
The filter parameter MUST contain at least one valid Boolean The filter parameter MUST contain at least one valid Boolean
skipping to change at page 20, line 11 skipping to change at page 23, line 11
ims[type eq "xmpp" and value co "@foo.com"] ims[type eq "xmpp" and value co "@foo.com"]
Figure 2: Example Filters Figure 2: Example Filters
3.4.2.3. Sorting 3.4.2.3. Sorting
Sort is OPTIONAL. Sorting allows clients to specify the order in Sort is OPTIONAL. Sorting allows clients 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
attribute (see Section 2.2 [I-D.ietf-scim-core-schema]), if any, attribute (see Section 2.4 [I-D.ietf-scim-core-schema]), if any,
or else the first value in the list, if any. If the attribute is or else the first value in the list, if any. If the attribute is
complex the attribute name must be a path to a sub-attribute in complex the attribute name must be a path to a sub-attribute in
standard attribute notation (Section 3.10) ; e.g., standard attribute notation (Section 3.10) ; e.g.,
"sortBy=name.givenName". For all attribute types, if there is no "sortBy=name.givenName". For all attribute types, if there is no
data for the specified "sortBy" value they are sorted via the data for the specified "sortBy" value they are sorted via the
"sortOrder" parameter; i.e., they are ordered last if ascending "sortOrder" parameter; i.e., they are ordered last if ascending
and first if descending. and first if descending.
sortOrder: The order in which the sortBy parameter is applied. sortOrder The order in which the sortBy parameter is applied.
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
case exact string. "sortOrder" MUST sort according to the case exact string. "sortOrder" MUST sort according to the
attribute type; i.e., for case insensitive attributes, sort the attribute type; i.e., for case insensitive attributes, sort the
result using case insensitive, unicode alphabetic sort order, with result using case insensitive, unicode alphabetic sort order, with
no specific locale implied and for case exact attribute types, no specific locale implied and for case exact attribute types,
sort the result using case sensitive, Unicode alphabetic sort sort the result using case sensitive, Unicode alphabetic sort
order. order.
skipping to change at page 30, line 26 skipping to change at page 33, line 26
"path":"members[value eq "path":"members[value eq
\"2819c223-7f76-453a-919d-413861904646\"]" \"2819c223-7f76-453a-919d-413861904646\"]"
"path":"members[value eq "path":"members[value eq
\"2819c223-7f76-453a-919d-413861904646\"].displayName" \"2819c223-7f76-453a-919d-413861904646\"].displayName"
Figure 8: Example Path Values Figure 8: Example Path Values
Each operation against an attribute MUST be compatible with the Each operation against an attribute MUST be compatible with the
attribute's mutability and schema as defined in the Attribute Types attribute's mutability and schema as defined in the Section 2.2 and
Section of [I-D.ietf-scim-core-schema]. For example, a client MUST 2.3 of [I-D.ietf-scim-core-schema]. For example, a client MUST NOT
NOT modify an attribute that has mutability "readOnly" or modify an attribute that has mutability "readOnly" or "immutable".
"immutable". However, a client MAY "add" a value to an "immutable" However, a client MAY "add" a value to an "immutable" attribute if
attribute if the attribute had no previous value. An operation that the attribute had no previous value. An operation that is not
is not compatibile with an attribute's mutability or schema SHALL compatible with an attribute's mutability or schema SHALL return the
return the appropriate HTTP response status code and a JSON detail appropriate HTTP response status code and a JSON detail error
error response as defined in Section 3.12. response as defined in Section 3.12.
The attribute notation rules described in Section 3.10 apply for The attribute notation rules described in Section 3.10 apply for
describing attribute paths. For all operations, the value of the describing attribute paths. For all operations, the value of the
"schemas" attribute on the SCIM service provider's representation of "schemas" attribute on the SCIM service provider's representation of
the resource SHALL be assumed by default. If one of the PATCH the resource SHALL be assumed by default. If one of the PATCH
operations modifies the "schemas" attribute, subsequent operations operations modifies the "schemas" attribute, subsequent operations
SHALL assume the modified state of the "schemas" attribute. Clients SHALL assume the modified state of the "schemas" attribute. clients
MAY implicitly modify the "schemas" attribute by adding (or MAY implicitly modify the "schemas" attribute by adding (or
replacing) an attribute with its fully qualified name including replacing) an attribute with its fully qualified name including
schema URN. For example, adding the attribute "urn:ietf:params:scim: schema URN. For example, adding the attribute "urn:ietf:params:scim:
schemas:extension:enterprise:2.0:User:employeeNumber", automatically schemas:extension:enterprise:2.0:User:employeeNumber", automatically
adds the value adds the value
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User" to the "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User" to the
resource's "schemas" attribute. resource's "schemas" attribute.
Each patch operation represents a single action to be applied to the Each patch operation represents a single action to be applied to the
same SCIM resource specified by the request URI. Operations are same SCIM resource specified by the request URI. Operations are
skipping to change at page 38, line 22 skipping to change at page 41, line 22
exist, the service provider SHALL treat the operation as an "add". exist, the service provider SHALL treat the operation as an "add".
o If the target location specifies a complex attribute, a set of o If the target location specifies a complex attribute, a set of
sub-attributes SHALL be specified in the "value" parameter which sub-attributes SHALL be specified in the "value" parameter which
replaces any existing values or adds where an attribute did not replaces any existing values or adds where an attribute did not
previously exist. Sub-attributes that are not specified in the previously exist. Sub-attributes that are not specified in the
"value" parameter are left unchanged. "value" parameter are left unchanged.
o If the target location is a multi-valued attribute and a value o If the target location is a multi-valued attribute and a value
selection ("valuePath") filter is specified that matches one or selection ("valuePath") filter is specified that matches one or
more values of the mulit-valued attribute, then all matching more values of the multi-valued attribute, then all matching
record values SHALL be replaced. record values SHALL be replaced.
o If the target location is a complex-multi-valued attribute with a o If the target location is a complex-multi-valued attribute with a
value selection filter ("valuePath") and a specific sub-attribute value selection filter ("valuePath") and a specific sub-attribute
(e.g., "addresses[type eq "work"].streetAddress" ), the matching (e.g., "addresses[type eq "work"].streetAddress" ), the matching
sub-attribute of all matching records is replaced. sub-attribute of all matching records is replaced.
o If the target location is a mulit-valued attribute for which a o If the target location is a multi-valued attribute for which a
value selection filter ("valuePath") has been supplied and no value selection filter ("valuePath") has been supplied and no
record match was made, the service provider SHALL fail by record match was made, the service provider SHALL fail by
returning HTTP status "400", and a "scimType" of "noTarget". returning HTTP status "400", and a "scimType" of "noTarget".
The following example shows how to replace all the members of a group The following example shows how to replace all the members of a group
with a different members list in a single replace operation. Some with a different members list in a single replace operation. Some
text removed for readability ("..."): text removed for readability ("..."):
PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
Host: example.com Host: example.com
skipping to change at page 43, line 11 skipping to change at page 46, line 11
Host: example.com Host: example.com
Authorization: Bearer h480djs93hd8 Authorization: Bearer h480djs93hd8
If-Match: W/"c310cd84f0281b7" If-Match: W/"c310cd84f0281b7"
In response to a successful delete, the server SHALL respond with In response to a successful delete, the server SHALL respond with
successful HTTP status 204 (No Content). A non-normative example successful HTTP status 204 (No Content). A non-normative example
response: response:
HTTP/1.1 204 No Content HTTP/1.1 204 No Content
Example: client attempt to retrieve the previously deleted User Example: Client 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: Server Response:
HTTP/1.1 404 NOT FOUND HTTP/1.1 404 NOT FOUND
{ {
skipping to change at page 44, line 31 skipping to change at page 47, line 31
unique within a bulk request and created by the client. The unique within a bulk request and created by the client. The
bulkId serves as a surrogate resource id enabling clients to bulkId serves as a surrogate resource id enabling clients to
uniquely identify newly created resources in the Response and uniquely identify newly created resources in the Response and
cross reference new resources in and across operations within a cross reference new resources in and across operations within a
bulk request. REQUIRED when method is POST. bulk request. REQUIRED when method is POST.
version The current resource version. Version is MAY be used if version The current resource version. Version is MAY be used if
the service provider supports ETags and the method is PUT, the service provider supports ETags and the method is PUT,
PATCH, or DELETE. PATCH, or DELETE.
path The resource's relative path. If the method is POST the path The resource's relative path to the SCIM service provider's
value must specify a resource type endpoint; e.g., /Users or root. If the method is POST the value must specify a resource
/Groups whereas all other method values must specify the path type endpoint; e.g., /Users or /Groups whereas all other method
to a specific resource; e.g., /Users/2819c223-7f76-453a-919d- values must specify the path to a specific resource; e.g.,
413861904646. REQUIRED in a request. /Users/2819c223-7f76-453a-919d-413861904646. REQUIRED in a
request.
data The resource data as it would appear for a single POST, PUT data The resource data as it would appear for a single POST, PUT
or PATCH resource operation. REQUIRED in a request when method or PATCH resource operation. REQUIRED in a request when method
is POST, PUT and PATCH. is POST, PUT and PATCH.
location The resource endpoint URL. REQUIRED in a response, location The resource endpoint URL. REQUIRED in a response,
except in the event of a POST failure. except in the event of a POST failure.
response The HTTP response body to the specified request response The HTTP response body to the specified request
operation. When indicating a response with an HTTP status operation. When indicating a response with an HTTP status
skipping to change at page 51, line 5 skipping to change at page 54, line 5
"code": "201" "code": "201"
} }
} }
] ]
} }
In the above example, the Alice User resource has an "id" of In the above example, the Alice User resource has an "id" of
"92b725cd-9465-4e7d-8c16-01f8e146b87a" and the Tour Guides Group has "92b725cd-9465-4e7d-8c16-01f8e146b87a" and the Tour Guides Group has
an "id" of "e9e30dba-f08f-4109-8486-d5c6a331660a". an "id" of "e9e30dba-f08f-4109-8486-d5c6a331660a".
A subsequent GET request for the 'Tour Guides' Group (with an "id" A subsequent GET request for the 'Tour Guides' Group (with an "id" of
of"e9e30dba-f08f-4109-8486-d5c6a331660a") returns the following with "e9e30dba-f08f-4109-8486-d5c6a331660a") returns the following with
Alice's "id" as the value for the member in the Group 'Tour Guides': Alice's "id" as the value for the member in the Group 'Tour Guides':
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/scim+json Content-Type: application/scim+json
Location: Location:
https://example.com/v2/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a https://example.com/v2/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a
ETag: W/"lha5bbazU3fNvfe5" ETag: W/"lha5bbazU3fNvfe5"
{ {
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"], "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
skipping to change at page 52, line 37 skipping to change at page 55, line 37
"bulkId": "ytrewq", "bulkId": "ytrewq",
"data": { "data": {
"schemas": [ "schemas": [
"urn:ietf:params:scim:schemas:core:2.0:User", "urn:ietf:params:scim:schemas:core:2.0:User",
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User" "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
], ],
"userName": "Bob", "userName": "Bob",
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": { "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
"employeeNumber": "11250", "employeeNumber": "11250",
"manager": { "manager": {
"managerId": "batchId:qwerty", "value": "batchId:qwerty"
"displayName": "Alice"
} }
} }
} }
} }
] ]
} }
3.7.3. Response and Error Handling 3.7.3. Response and Error Handling
The service provider response MUST include the result of all The service provider response MUST include the result of all
skipping to change at page 58, line 33 skipping to change at page 61, line 33
"version": "W\/\"lha5bbazU3fNvfe5\"", "version": "W\/\"lha5bbazU3fNvfe5\"",
"status": "201" "status": "201"
} }
] ]
} }
3.7.4. Maximum Operations 3.7.4. Maximum Operations
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 client may send in a single request. These maximum payload size a client may send in a single request. These
limits MAY be retrieved from the Service Provider Configuration (see limits MAY be retrieved from the service provider Configuration (see
'bulk' in Section 8 of [I-D.ietf-scim-core-schema]). If either 'bulk' in Section 5 and 8.5 of [I-D.ietf-scim-core-schema]). If
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
MUST specify the limit exceeded in the body of the error response. MUST specify the limit exceeded in the body of the error response.
The following example the client sent a request exceeding the service The following example the client sent a request exceeding the service
provider's max payload size of 1 megabyte: provider's max payload size of 1 megabyte:
POST /v2/Bulk POST /v2/Bulk
Host: example.com Host: example.com
Accept: application/scim+json Accept: application/scim+json
Content-Type: application/scim+json Content-Type: application/scim+json
skipping to change at page 60, line 17 skipping to change at page 63, line 17
For any SCIM operation where a resource representation is returned For any SCIM operation where a resource representation is returned
(e.g., HTTP GET), the attributes returned are defined as the minimum (e.g., HTTP GET), the attributes returned are defined as the minimum
attribute set plus default attributes set. The minimum set are those attribute set plus default attributes set. The minimum set are those
attributes whose schema have "returned" set to "always". The default attributes whose schema have "returned" set to "always". The default
attribute set are those attributes whose schema have "returned" set attribute set are those attributes whose schema have "returned" set
to "default". to "default".
Clients MAY request a partial resource representation on any Clients 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
either of the mutually exclusive URL query parameters "attributes" or either of the mutually exclusive URL query parameters "attributes" or
"excludedAtributes" as follows: "excludedAttributes" as follows:
attributes When specified the default list of attributes SHALL be attributes When specified the default list of attributes SHALL be
overridden and each resource returned MUST contain the overridden and each resource returned MUST contain the
minimum set of resource attributes and any attributes or sub- minimum set of resource attributes and any attributes or sub-
attributes explicitly requested by the "attributes" attributes explicitly requested by the "attributes"
parameter. The query parameter attributes value is a comma parameter. The query parameter attributes value is a comma
separated list of resource attribute names in standard separated list of resource attribute names in standard
attribute notation (Section 3.10) form (e.g., userName, name, attribute notation (Section 3.10) form (e.g., userName, name,
emails). emails).
skipping to change at page 62, line 22 skipping to change at page 65, line 22
o A service provider MAY process the SCIM request directly. In any o A service provider MAY process the SCIM request directly. In any
response, the HTTP "Location" header MUST be the permanent response, the HTTP "Location" header MUST be the permanent
location of the aliased resource associated with the authenticated location of the aliased resource associated with the authenticated
subject. subject.
When using the SCIM Create Resource command (HTTP POST) with the When using the SCIM Create Resource command (HTTP POST) with the
"/Me" alias, the desired resourceType being created is at the "/Me" alias, the desired resourceType being created is at the
discretion of the service provider based on the authenticated subject discretion of the service provider based on the authenticated subject
(if not anonymous) making the request and any request body attributes (if not anonymous) making the request and any request body attributes
(e.g., "schemas"). See Section 7.3 for information on security (e.g., "schemas"). See Section 7.6 for information on security
considerations related to this operation. considerations related to this operation.
3.12. HTTP Status and Error Response Handling 3.12. HTTP Status and Error Response Handling
The SCIM Protocol uses the HTTP status response status codes defined The SCIM Protocol uses the HTTP status response status codes defined
in Section 6 [RFC7231] to indicate operation success or failure. In in Section 6 [RFC7231] to indicate operation success or failure. In
addition to returning a HTTP response code implementers MUST return addition to returning a HTTP response code implementers MUST return
the errors in the body of the response in the client requested format the errors in the body of the response in the client requested format
containing the error response and, per the HTTP specification, human- containing the error response and, per the HTTP specification, human-
readable explanations. Error responses are identified using the readable explanations. Error responses are identified using the
following "schema" URI: following "schema" URI:
"urn:ietf:params:scim:api:messages:2.0:Error". The following "urn:ietf:params:scim:api:messages:2.0:Error". The following
attributes are defined for a SCIM error response using a JSON body: attributes are defined for a SCIM error response using a JSON body:
status status
The HTTP status code (see Section 6 [RFC7231]). REQUIRED The HTTP status code (see Section 6 [RFC7231]) expressed as a JSON
String. REQUIRED
scimType scimType
A SCIM detailed error keyword. See Table 8. OPTIONAL A SCIM detailed error keyword. See Table 8. OPTIONAL
detail detail
A detailed, human readable message. OPTIONAL A detailed, human readable message. OPTIONAL
Implementers SHOULD handle the identified HTTP status codes as Implementers SHOULD handle the identified HTTP status codes as
described below. described below.
skipping to change at page 63, line 22 skipping to change at page 66, line 23
| 308 | GET, POST, | The client is directed to repeat | | 308 | GET, POST, | The client is directed to repeat |
| PERMANENT | PUT, PATCH, | the same HTTP request at the | | PERMANENT | PUT, PATCH, | the same HTTP request at the |
| REDIRECT | DELETE | location identified. The client | | REDIRECT | DELETE | location identified. The client |
| | | SHOULD use the location provided | | | | SHOULD use the location provided |
| | | in the response as the permanent | | | | in the response as the permanent |
| | | reference to the resource | | | | reference to the resource |
| | | [RFC7538]. | | | | [RFC7538]. |
| 400 BAD | GET, POST, | Request is unparsable, | | 400 BAD | GET, POST, | Request is unparsable, |
| REQUEST | PUT, PATCH, | syntactically incorrect, or | | REQUEST | PUT, PATCH, | syntactically incorrect, or |
| | DELETE | violates schema | | | DELETE | violates schema |
| 401 | GET, POST, | Authorization failure | | 401 | GET, POST, | Authorization failure. The |
| UNAUTHORIZED | PUT, PATCH, | | | UNAUTHORIZED | PUT, PATCH, | authorization header is invalid or |
| | DELETE | | | | DELETE | missing. |
| 403 | GET, POST, | Server does not support requested | | 403 | GET, POST, | Operation is not permitted based |
| FORBIDDEN | PUT, PATCH, | operation | | FORBIDDEN | PUT, PATCH, | on the supplied authorization. |
| | DELETE | | | | DELETE | |
| 404 NOT | GET, POST, | Specified resource (e.g., User) or | | 404 NOT | GET, POST, | Specified resource (e.g., User) or |
| FOUND | PUT, PATCH, | end-point, does not exist | | FOUND | PUT, PATCH, | end-point, does not exist |
| | DELETE | | | | DELETE | |
| 409 CONFLICT | POST, PUT, | The specified version number does | | 409 CONFLICT | POST, PUT, | The specified version number does |
| | PATCH, DELETE | not match the resource's latest | | | PATCH, DELETE | not match the resource's latest |
| | | version number or a service | | | | version number or a service |
| | | provider refused to create a new, | | | | provider refused to create a new, |
| | | duplicate resource | | | | duplicate resource |
| 412 | PUT, PATCH,D | Failed to update as resource {id} | | 412 | PUT, PATCH,D | Failed to update as resource {id} |
skipping to change at page 65, line 12 skipping to change at page 68, line 12
| | attribute value that could | | | | attribute value that could | |
| | be operated on. This occurs | | | | be operated on. This occurs | |
| | when the specified "path" | | | | when the specified "path" | |
| | value contains a filter that | | | | value contains a filter that | |
| | yields no match. | | | | yields no match. | |
| invalidValue | A required value was | GET (Section | | invalidValue | A required value was | GET (Section |
| | missing, or the value | 3.4.2), POST | | | missing, or the value | 3.4.2), POST |
| | specified was not compatible | (Create - Section | | | specified was not compatible | (Create - Section |
| | with the operation or | 3.3, Query - | | | with the operation or | 3.3, Query - |
| | attribute type (see Section | Section 3.4.2), PUT | | | attribute type (see Section | Section 3.4.2), PUT |
| | 2.1 [I-D.ietf-scim-core-sche | (Section 3.5.1), | | | 2.2 [I-D.ietf-scim-core-sche | (Section 3.5.1), |
| | ma]), or schema (see Section | PATCH (Section | | | ma]), or resource schema | PATCH (Section |
| | 4 [I-D.ietf-scim-core-schema | 3.5.2) | | | (see Section 4 [I-D.ietf-sci | 3.5.2) |
| | ]). | | | | m-core-schema]). | |
| invalidVers | The specified SCIM protocol | GET (Section | | invalidVers | The specified SCIM protocol | GET (Section |
| | version is not supported | 3.4.2), POST (ALL), | | | version is not supported | 3.4.2), POST (ALL), |
| | (see Section 3.13). | PUT (Section | | | (see Section 3.13). | PUT (Section |
| | | 3.5.1), PATCH | | | | 3.5.1), PATCH |
| | | (Section 3.5.2), | | | | (Section 3.5.2), |
| | | DELETE (Section | | | | DELETE (Section |
| | | 3.6) | | | | 3.6) |
| sensitive | The specified request cannot | GET (Section |
| | be completed due to passing | 3.4.2). |
| | of sensitive (e.g., | |
| | personal) information in a | |
| | request URI. For example, | |
| | personal information SHALL | |
| | NOT be transmitted over | |
| | request URIs. See Section | |
| | 7.5.2. | |
+--------------+------------------------------+---------------------+ +--------------+------------------------------+---------------------+
Table 8: Table of SCIM Detail Error Keyword Values Table 8: Table of SCIM Detail Error Keyword Values
Note that in the table above (Table 8), the applicability table Note that in the table above (Table 8), the applicability table
applies to the normal HTTP method but MAY apply within a SCIM Bulk applies to the normal HTTP method but MAY apply within a SCIM Bulk
operation (via HTTP POST). operation (via HTTP POST).
Error example in response to a non-existent GET request. Error example in response to a non-existent GET request.
HTTP/1.1 404 NOT FOUND HTTP/1.1 404 NOT FOUND
{ {
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"], "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"detail":"Resource 2819c223-7f76-453a-919d-413861904646 not found", "detail":"Resource 2819c223-7f76-453a-919d-413861904646 not found",
"status":"404 "status": "404"
} }
Error example in response to a PUT request. Error example in response to a PUT request.
HTTP/1.1 400 BAD REQUEST HTTP/1.1 400 BAD REQUEST
{ {
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"], "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"scimType":"mutability" "scimType":"mutability"
"detail":"Attribute 'id' is readOnly", "detail":"Attribute 'id' is readOnly",
"status":"400" "status": "400"
} }
[[Editor's note: while the detail error codes seem to have consensus,
there is a question about whether the error codes should be
extensible so that individual service providers may define site
specific codes. Should all scimTypes be URIs, so that scimTypes can
be registered via IANA? Should there be a separate field defined for
this purpose? Or, should custom signalling (for non-protocol/schema
errors, be out of scope?]]
3.13. API Versioning 3.13. API Versioning
The Base URL MAY be appended with a version identifier as a separate The Base URL MAY be appended with a version identifier as a separate
segment in the URL path. At this time of this specification, the segment in the URL path. At this time of this specification, the
identifier is 'v2'. If specified, the version identifier MUST appear identifier is 'v2'. If specified, the version identifier MUST appear
in the URL path immediately preceding the resource endpoint and in the URL path immediately preceding the resource endpoint and
conform to the following scheme: the character 'v' followed by the conform to the following scheme: the character 'v' followed by the
desired SCIM version number; e.g., a version 'v2' User request is desired SCIM version number; e.g., a version 'v2' User request is
specified as /v2/Users. When specified service providers MUST specified as /v2/Users. When specified service providers MUST
perform the operation using the desired version or reject the perform the operation using the desired version or reject the
request. When omitted service providers SHOULD perform the operation request. When omitted service providers SHOULD perform the operation
using the most recent SCIM protocol version supported by the service using the most recent SCIM protocol version supported by the service
provider. provider.
3.14. Versioning Resources 3.14. Versioning Resources
The SCIM protocol supports resource versioning via standard HTTP The SCIM protocol supports resource versioning via standard HTTP
ETags Section 2.3 [RFC7233]. Service providers MAY support weak ETags Section 2.3 [RFC7232]. Service providers MAY support weak
ETags as the preferred mechanism for performing conditional ETags as the preferred mechanism for performing conditional
retrievals and ensuring clients do not inadvertently overwrite each retrievals and ensuring clients do not inadvertently overwrite each
others changes, respectively. When supported SCIM ETags MUST be others changes, respectively. When supported SCIM ETags MUST be
specified as an HTTP header and SHOULD be specified within the specified as an HTTP header and SHOULD be specified within the
'version' attribute contained in the resource's 'meta' attribute. 'version' attribute contained in the resource's 'meta' attribute.
Example: Example:
POST /Users HTTP/1.1 POST /Users HTTP/1.1
Host: example.com Host: example.com
skipping to change at page 68, line 18 skipping to change at page 71, line 18
GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=displayName GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=displayName
Host: example.com Host: example.com
Accept: application/scim+json Accept: application/scim+json
Authorization: Bearer h480djs93hd8 Authorization: Bearer h480djs93hd8
If-None-Match: W/"e180ee84f0671b1" If-None-Match: W/"e180ee84f0671b1"
If the resource has not changed the service provider simply returns If the resource has not changed the service provider simply returns
an empty body with a 304 "Not Modified" response code. an empty body with a 304 "Not Modified" response code.
If the service providers supports versioning of resources the client If the service providers supports versioning of resources the client
MAY supply an If-Match Section 3.1 [RFC7233] header for PUT and PATCH MAY supply an If-Match Section 3.2 [RFC7233] header for PUT and PATCH
operations to ensure that the requested operation succeeds only if operations to ensure that the requested operation succeeds only if
the supplied ETag matches the latest service provider resource; e.g., the supplied ETag matches the latest service provider resource; e.g.,
If-Match: W/"e180ee84f0671b1" If-Match: W/"e180ee84f0671b1"
4. Service Provider Configuration Endpoints 4. Service Provider Configuration Endpoints
SCIM 2 defines 3 endpoints to facilitate discovery of SCIM service SCIM 2 defines 3 endpoints to facilitate discovery of SCIM service
provider features and schema that MAY be retrieved using HTTP GET: provider features and schema that MAY be retrieved using HTTP GET:
/ServiceProviderConfig /ServiceProviderConfig
An HTTP GET to this endpoint will return a JSON structure that An HTTP GET to this endpoint will return a JSON structure that
describes the SCIM specification features available on a service describes the SCIM specification features available on a service
provider. This endpoint SHALL return responses with a JSON object provider. This endpoint SHALL return responses with a JSON object
using a "schemas" attribute of using a "schemas" attribute of
"urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig". "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig".
The attributes returned in the JSON object are defined in The attributes returned in the JSON object are defined in
Section 5 [I-D.ietf-scim-core-schema]. An example representation Section 5 [I-D.ietf-scim-core-schema]. An example representation
of SCIM Service Provider configuration may be found in Section 8.5 of SCIM service provider configuration may be found in Section 8.5
[I-D.ietf-scim-core-schema]. [I-D.ietf-scim-core-schema].
/Schemas /Schemas
An HTTP GET to this endpoint is used to retrieve information about An HTTP GET to this endpoint is used to retrieve information about
resource schemas supported by a SCIM Service Provider. An HTTP resource schemas supported by a SCIM service provider. An HTTP
GET to the endpoint "/Schemas" SHALL return all supported schemas GET to the endpoint "/Schemas" SHALL return all supported schemas
in ListResponse format (see Figure 3). Individual schema in ListResponse format (see Figure 3). Individual schema
definitions can be returned by appending the schema URI to the definitions can be returned by appending the schema URI to the
schemas endpoint. For example: schemas endpoint. For example:
/Schemas/urn:ietf:params:scim:schemas:core:2.0:User /Schemas/urn:ietf:params:scim:schemas:core:2.0:User
The contents of each schema returned is described in Section 7 The contents of each schema returned is described in Section 7
[I-D.ietf-scim-core-schema]. An example representation of SCIM [I-D.ietf-scim-core-schema]. An example representation of SCIM
schemas may be found in Section 8.7 [I-D.ietf-scim-core-schema]. schemas may be found in Section 8.7 [I-D.ietf-scim-core-schema].
/ResourceTypes /ResourceTypes
An HTTP GET to this endpoint is used to discover the types of An HTTP GET to this endpoint is used to discover the types of
resources available on a SCIM Service Provider (e.g., Users and resources available on a SCIM service provider (e.g., Users and
Groups). Each resource type defines the endpoints, the core Groups). Each resource type defines the endpoints, the core
schema URI that defines the resource, and any supported schema schema URI that defines the resource, and any supported schema
extensions. The attributes defining a resource type can be found extensions. The attributes defining a resource type can be found
in Section 6 [I-D.ietf-scim-core-schema], and an example in Section 6 [I-D.ietf-scim-core-schema], and an example
representation can be found in Section 8.6 representation can be found in Section 8.6
[I-D.ietf-scim-core-schema]. [I-D.ietf-scim-core-schema].
In cases where a request is for a specific "ResourceType" or In cases where a request is for a specific "ResourceType" or
"Schema", the single JSON object is returned in the same way a single "Schema", the single JSON object is returned in the same way a single
User or Group is retrieved as per Section 3.4.1. When returning User or Group is retrieved as per Section 3.4.1. When returning
skipping to change at page 72, line 43 skipping to change at page 75, line 43
The service provider may choose to implement SCIM ids which are The service provider may choose to implement SCIM ids which are
unique across all resources for all Tenants, but this is not unique across all resources for all Tenants, but this is not
required. required.
The externalId, defined by the client, is required to be unique ONLY The externalId, defined by the client, is required to be unique ONLY
within the resources associated with the associated Tenant. within the resources associated with the associated Tenant.
7. Security Considerations 7. Security Considerations
7.1. TLS Support 7.1. HTTP Considerations
The SCIM Protocol layers on top of Hypertext Transfer Protocol and SCIM Protocol layers on top of Hypertext Transfer Protocol and thus
thus subject to the security considerations of HTTP Section 9 subject to the security considerations of HTTP Section 9 [RFC7230]
[RFC7230] and its related specifications. and its related specifications.
As stated in Section 2.7.1 [RFC7230], a SCIM client MUST NOT generate
the "userinfo" (i.e., username and password) component (and its "@"
delimiter) when an "http" URI reference is generated with a message
as they are now disallowed in HTTP.
7.2. TLS Support Considerations
SCIM resources (e.g., Users and Groups) can contain sensitive SCIM resources (e.g., Users and Groups) can contain sensitive
information. Therefore, SCIM clients and service providers MUST information including passwords. Therefore, SCIM clients and service
implement TLS. Which version(s) ought to be implemented will vary providers MUST require the use of a transport-layer security
over time, and depend on the widespread deployment and known security mechanism when communicating with SCIM service providers. The SCIM
vulnerabilities at the time of implementation. At the time of this service provider MUST support TLS 1.2 [RFC5246] and MAY support
writing, TLS version 1.2 [RFC5246] is the most recent version, but additional transport-layer mechanisms meeting its security
has very limited actual deployment, and might not be readily requirements. When using TLS, the client MUST perform a TLS/SSL
available in implementation toolkits. TLS version 1.0 [RFC5246] is server certificate check, per [RFC6125]. Implementation security
the most widely deployed version, and will give the broadest considerations for TLS can be found in "Recommendations for Secure
interoperability. Use of TLS and DTLS" [RFC7525].
7.2. Disclosure of Sensitive Information in URIs 7.3. Authorization Token Considerations
When using authorization tokens such as those issued by OAuth 2.0
[RFC6749], implementers SHOULD take into account the threats and
countermeasures documented in Section 8 of
[I-D.ietf-oauth-assertions].
7.4. Bearer and Cookie Considerations
Since the possession of a bearer token or cookie MAY authorize the
holder to potentially read, modify, or delete resources, tokens and
cookies MUST contain sufficient entropy to prevent a random guessing
attack, such as described in Section 5.2 of [RFC6750] and
Section 5.1.4.2.2 of [RFC6819].
When using a bearer token that represents an authorization,
As with all SCIM communications, Bearer tokens and HTTP cookies MUST
be exchanged using TLS.
Bearer tokens MUST have a limited lifetime that can be determined
directly or indirectly (e.g., by checking with a validation service)
by the service provider. By expiring tokens, clients are forced to
obtain a new token (which usually involves re-authentication) for
continued authorized access. For example, in OAuth2, a client MAY
use OAuth token refresh to obtain a new bearer token after
authenticating to an authorization server. See Section 6 of
[RFC6749].
As with Bearer tokens, an HTTP cookie SHOULD last no longer than the
lifetime of a browser session. An expiry time should be set that
limits session cookie lifetime as per Section 5.2.1 of [RFC6265].
Implementations supporting OAuth bearer tokens need to factor in
security considerations of this authorization method
[I-D.ietf-oauth-assertions]. Since security is only as good as the
weakest link, implementers also need to consider authentication
choices coupled with OAuth bearer tokens. The security
considerations of the default authentication method for OAuth bearer
tokens, HTTP BASIC, are well documented in
[I-D.ietf-httpauth-basicauth-update], therefore implementers are
encouraged to prefer stronger authentication methods. Designating
the specific methods of authentication and authorization are out-of-
scope for SCIM, however this information is provided as a resource to
implementers.
7.5. Privacy Considerations
7.5.1. Personal Information
The SCIM Core Schema specifications defines attributes that may
contain personally identifying information as well as other sensitive
personal data. The privacy considerations in the Security
Considerations Section of [I-D.ietf-scim-core-schema] MUST be
considered.
7.5.2. Disclosure of Sensitive Information in URIs
As mentioned in Section 9.4 [RFC7231], SCIM clients requesting As mentioned in Section 9.4 [RFC7231], SCIM clients requesting
information using query filters using HTTP GET SHOULD give information using query filters using HTTP GET SHOULD give
consideration to the information content of the filters and whether consideration to the information content of the filters and whether
their exposure in a URI would represent a breach of security or their exposure in a URI would represent a breach of security or
confidentiality through leakage in a web browsers or server logs. confidentiality through leakage in a web browsers or server logs.
This is particularly true for information that is legally considered This is particularly true for information that is legally considered
"personally identifiable information" or is otherwise restricted by "personally identifiable information" or is otherwise restricted by
privacy laws. In these situations to ensure maximum security and privacy laws. In these situations to ensure maximum security and
confidentiality, clients SHOULD query using HTTP POST (see confidentiality, clients SHOULD query using HTTP POST (see
Section 3.4.3 ). Section 3.4.3 ).
Servers that receive HTTP GET requests using filters that contain Servers that receive HTTP GET requests using filters that contain
restricted or confidential information SHOULD respond with HTTP sensitive or confidential personal information SHOULD respond with
status 403 indicating the operation is FORBIDDEN. A detailed error, HTTP status 403 indicating the operation is FORBIDDEN. A "scimType"
"confidential_restricted" may be returned indicating the request must error of "sensitive" may be returned indicating the request must be
be submitted using POST. A non-normative example: submitted using POST. A non-normative example:
HTTP/1.1 403 FORBIDDEN HTTP/1.1 403 FORBIDDEN
{ {
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"], "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"Errors":[ "detail":
{
"description":
"Query filter involving 'name' is restricted or confidential", "Query filter involving 'name' is restricted or confidential",
"error":"confidential_restricted" "scimType": "sensitive",
} "status": "404"
]
} }
7.3. Anonymous Requests 7.6. Anonymous Requests
If a SCIM service provider accepts anonymous requests such as SCIM If a SCIM service provider accepts anonymous requests such as SCIM
resource creation requests (via HTTP POST), appropriate security resource creation requests (via HTTP POST), appropriate security
measures should be put in place to prevent or limit exposure to measures should be put in place to prevent or limit exposure to
attacks. The following counter-measures MAY be used: attacks. The following counter-measures MAY be used:
o Try to authenticate web UI components that forumulate the SCIM o Try to authenticate web UI components that formulate the SCIM
creation request. While the end-user MAY be anonymous, the web creation request. While the end-user MAY be anonymous, the web
user interface component often has its own way to authenticate to user interface component often has its own way to authenticate to
the SCIM service provider (e.g., has an OAuth Client Credential the SCIM service provider (e.g., has an OAuth client credential
[RFC6749]) and the web user interface component may implement its [RFC6749]) and the web user interface component may implement its
own measures (e.g., such as CAPTCHA) to ensure a ligitimate own measures (e.g., such as CAPTCHA) to ensure a legitimate
request is being made. request is being made.
o Limit the number of requests any particular client MAY make in a o Limit the number of requests any particular client MAY make in a
period of time. period of time.
o For User resources, default newly created resource with an o For User resources, default newly created resource with an
"active" setting of "false" and use a secondary confirmation "active" setting of "false" and use a secondary confirmation
process (e.g., email confirmation) to ensure the resource created process (e.g., email confirmation) to ensure the resource created
is real. is real.
7.4. HTTP Considerations 7.7. Secure Storage and Handling of Sensitive Data
As an HTTP based protocol, implementers of SCIM SHOULD consider all
security considerations of the HTTP/1.1 as enumerated in Section 1
[RFC7230]
As stated in Section 2.7.1 [RFC7230], a SCIM client MUST NOT generate
the userinfo (i.e., username and password) component (and its "@"
delimiter) when an "http" URI reference is generated with a message
as they are now disallowed in HTTP.
7.5. Secure Storage and Handling of Sensitive Data
An attacker may obtain valid username/password combinations from the An attacker may obtain valid username/password combinations from the
SCIM service provider's underlying database by gaining access to the SCIM service provider's underlying database by gaining access to the
database and/or launching injection attacks. This could lead to database and/or launching injection attacks. This could lead to
unintended disclosure of username/password combinations. The impact unintended disclosure of username/password combinations. The impact
may extend beyond the domain of the SCIM service provider if the data may extend beyond the domain of the SCIM service provider if the data
was provisioned from other domains. was provisioned from other domains.
Administrators should undertake industry best practices to protect Administrators should undertake industry best practices to protect
the storage of credentials and in particular SHOULD follow the storage of credentials and in particular SHOULD follow
skipping to change at page 75, line 4 skipping to change at page 79, line 11
the storage of credentials and in particular SHOULD follow the storage of credentials and in particular SHOULD follow
recommendations outlines in Section 5.1.4.1 [RFC6819]. These recommendations outlines in Section 5.1.4.1 [RFC6819]. These
recommendations include but are not limited to: recommendations include but are not limited to:
o Provide injection attack counter measures (e.g., by validating all o Provide injection attack counter measures (e.g., by validating all
inputs and parameters), inputs and parameters),
o No cleartext storage of credentials, o No cleartext storage of credentials,
o Store credentials using an encrypted protection mechanism, and o Store credentials using an encrypted protection mechanism, and
o Avoid passwords and consider use of asymmetric cryptography based o Avoid passwords and consider use of asymmetric cryptography based
credentials. credentials.
As outlined in Section 5.1.4.2 [RFC6819], adminitrators SHOULD take As outlined in Section 5.1.4.2 [RFC6819], administrators SHOULD take
counter measures to prevent online attacks on secrets such as: counter measures to prevent online attacks on secrets such as:
o Utilize secure password policy in order to increase user password o Utilize secure password policy in order to increase user password
entrophy to hinder online attacks and password guessing, entropy to hinder online attacks and password guessing,
o Mitigate attacks on passwords by locking respective accounts have o Mitigate attacks on passwords by locking respective accounts have
a number of failed attempts, a number of failed attempts,
o Use "tar pit" techniques by temporarily locking a respective o Use "tar pit" techniques by temporarily locking a respective
account and delaying responses for a certain duration. The account and delaying responses for a certain duration. The
duration may increase with the number of failed attempts, and duration may increase with the number of failed attempts, and
o Use authentication system that use CAPTCHA's and other factors for o Use authentication system that use CAPTCHA's and other factors for
authenticating users further reducing the possibility of automated authenticating users further reducing the possibility of automated
attacks. attacks.
7.6. Case Insensitive Comparison & International Languages Service providers SHOULD define an access control model that
differentiates between individual client applications and their
specific need to access information, and any User self-service rights
to review and update personal profile information. This may include
OAuth 2.0 delegation profiles, that allow client systems to act on
behalf of user's with their permission.
7.8. Case Insensitive Comparison & International Languages
When comparing unicode strings such as in query filters or testing When comparing unicode strings such as in query filters or testing
for uniqueness of usernames and passwords, strings MUST be for uniqueness of usernames and passwords, strings MUST be
appropriately prepared before comparison. See Section 5. appropriately prepared before comparison. See Section 5.
8. IANA Considerations 8. IANA Considerations
8.1. Media Type Registration 8.1. Media Type Registration
To: ietf-types@iana.org To: ietf-types@iana.org
skipping to change at page 76, line 28 skipping to change at page 80, line 42
browsers. browsers.
Additional information: Additional information:
Magic number(s): Magic number(s):
File extension(s): .scim .scm File extension(s): .scim .scm
Macintosh file type code(s): Macintosh file type code(s):
Person & email address to contact for futher information: SCIM Person & email address to contact for further information: SCIM
mailing list "<scim@ietf.org>" mailing list "<scim@ietf.org>"
Intended usage: COMMON* (see restrictions) Intended usage: COMMON* (see restrictions)
Restrictions on usage: For most client types, it is sufficient to Restrictions on usage: For most client types, it is sufficient to
recognize the content as equivalent to "application/json". recognize the content as equivalent to "application/json".
Applications intending to use SCIM protocol SHOULD use the Applications intending to use SCIM protocol SHOULD use the
application/scim+json media type. application/scim+json media type.
Author: Phil Hunt Author: Phil Hunt
skipping to change at page 77, line 32 skipping to change at page 81, line 45
Table 9: SCIM Schema URIs for Data Resources Table 9: SCIM Schema URIs for Data Resources
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-precis-saslprepbis] [I-D.ietf-precis-saslprepbis]
Saint-Andre, P. and A. Melnikov, "Preparation, Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", draft-ietf-precis- Representing Usernames and Passwords", draft-ietf-precis-
saslprepbis-15 (work in progress), April 2015. saslprepbis-16 (work in progress), April 2015.
[I-D.ietf-scim-core-schema] [I-D.ietf-scim-core-schema]
Hunt, P., Grizzle, K., Wahlstroem, E., and C. Mortimore, Hunt, P., Grizzle, K., Wahlstroem, E., and C. Mortimore,
"System for Cross-Domain Identity Management: Core "System for Cross-Domain Identity Management: Core
Schema", draft-ietf-scim-core-schema-17 (work in Schema", draft-ietf-scim-core-schema-18 (work in
progress), March 2015. progress), April 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[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.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", RFC [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", RFC
5789, March 2010. 5789, March 2010.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011.
[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.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June (HTTP/1.1): Message Syntax and Routing", RFC 7230, June
2014. 2014.
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231, June 2014. (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
[RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Conditional Requests", RFC 7232, June 2014.
[RFC7233] Fielding, R., Lafon, Y., and J. Reschke, "Hypertext [RFC7233] Fielding, R., Lafon, Y., and J. Reschke, "Hypertext
Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233,
June 2014. June 2014.
[RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", RFC 7235, June 2014. (HTTP/1.1): Authentication", RFC 7235, June 2014.
[RFC7538] Reschke, J., "The Hypertext Transfer Protocol Status Code [RFC7538] Reschke, J., "The Hypertext Transfer Protocol Status Code
308 (Permanent Redirect)", RFC 7538, April 2015. 308 (Permanent Redirect)", RFC 7538, April 2015.
9.2. Informative References 9.2. Informative References
[I-D.ietf-httpauth-basicauth-update]
Reschke, J., "The 'Basic' HTTP Authentication Scheme",
draft-ietf-httpauth-basicauth-update-07 (work in
progress), February 2015.
[I-D.ietf-oauth-assertions]
Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
"Assertion Framework for OAuth 2.0 Client Authentication
and Authorization Grants", draft-ietf-oauth-assertions-18
(work in progress), October 2014.
[I-D.ietf-oauth-pop-architecture]
Hunt, P., Richer, J., Mills, W., Mishra, P., and H.
Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security
Architecture", draft-ietf-oauth-pop-architecture-01 (work
in progress), March 2015.
[I-D.ietf-precis-framework] [I-D.ietf-precis-framework]
Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
Preparation, Enforcement, and Comparison of Preparation, Enforcement, and Comparison of
Internationalized Strings in Application Protocols", Internationalized Strings in Application Protocols",
draft-ietf-precis-framework-23 (work in progress), draft-ietf-precis-framework-23 (work in progress),
February 2015. February 2015.
[OpenSearch] [OpenSearch]
Clinton, D., "OpenSearch Protocol 1.1, Draft 5", Dec 2005. Clinton, D., "OpenSearch Protocol 1.1, Draft 5", Dec 2005.
[Order-Operations] [Order-Operations]
Wikipedia, "Order of Operations: Programming Languages", Wikipedia, "Order of Operations: Programming Languages",
Apr 2015. Apr 2015.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
6749, October 2012. 6749, October 2012.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750, October 2012. Framework: Bearer Token Usage", RFC 6750, October 2012.
[RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0 [RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0
Threat Model and Security Considerations", RFC 6819, Threat Model and Security Considerations", RFC 6819,
January 2013. January 2013.
[RFC6902] Bryan, P. and M. Nottingham, "JavaScript Object Notation [RFC6902] Bryan, P. and M. Nottingham, "JavaScript Object Notation
(JSON) Patch", RFC 6902, April 2013. (JSON) Patch", RFC 6902, April 2013.
[RFC7486] Farrell, S., Hoffman, P., and M. Thomas, "HTTP Origin-
Bound Authentication (HOBA)", RFC 7486, March 2015.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, May 2015.
[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.
Appendix A. Contributors Appendix A. Contributors
Samuel Erdtman (samuel@erdtman.se) Samuel Erdtman (samuel@erdtman.se)
Patrick Harding (pharding@pingidentity.com) Patrick Harding (pharding@pingidentity.com)
skipping to change at page 83, line 38 skipping to change at page 88, line 38
Updated references to saslprep and precis frameworks Updated references to saslprep and precis frameworks
Draft 15 - PH - Clarifications on returning "path" handling during Draft 15 - PH - Clarifications on returning "path" handling during
PATCH "replace" operations. Updated references. PATCH "replace" operations. Updated references.
Draft 16 - PH - Clarification of SCIM protocol definitions of Draft 16 - PH - Clarification of SCIM protocol definitions of
resources vs messages and general process rules regarding schema resources vs messages and general process rules regarding schema
including validation. including validation.
Draft 17 - PH - Edits based on Gen-ART review
Draft 18 - PH - Edits based on IESG feedback
Clarified use of authentication schemes
Nits and wording clarifications
Corrected definitions of HTTP Status 401/403
Manager corrected in PATCH example operation (consistent with
schema and examples)
Removed editor's note regarding Service Provider unique error
codes
Updated references to SCIM Core Schema and other documents.
Made capitalization of 'client' and 'service provider' terms
consistent (lower case)
Add references to draft-ietf-oauth-assertions-18 and draft-ietf-
httpauth-basicauth-update-07
Authors' Addresses Authors' Addresses
Phil Hunt (editor) Phil Hunt (editor)
Oracle Corporation Oracle Corporation
Email: phil.hunt@yahoo.com Email: phil.hunt@yahoo.com
Kelly Grizzle Kelly Grizzle
SailPoint SailPoint
skipping to change at page 84, line 4 skipping to change at page 89, line 26
Phil Hunt (editor) Phil Hunt (editor)
Oracle Corporation Oracle Corporation
Email: phil.hunt@yahoo.com Email: phil.hunt@yahoo.com
Kelly Grizzle Kelly Grizzle
SailPoint SailPoint
Email: kelly.grizzle@sailpoint.com Email: kelly.grizzle@sailpoint.com
Morteza Ansari Morteza Ansari
Cisco Cisco
Email: morteza.ansari@cisco.com Email: morteza.ansari@cisco.com
Erik Wahlstroem Erik Wahlstroem
Technology Nexus
Email: erik.wahlstrom@nexusgroup.com Email: erik.wahlstrom@nexusgroup.com
Chuck Mortimore Chuck Mortimore
Salesforce.com Salesforce.com
Email: cmortimore@salesforce.com Email: cmortimore@salesforce.com
 End of changes. 67 change blocks. 
184 lines changed or deleted 415 lines changed or added

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