System for Cross-Domain Identity
Management:ProtocolOracle Corporationphil.hunt@yahoo.comSailPointkelly.grizzle@sailpoint.comCiscomorteza.ansari@cisco.comTechnology Nexuserik.wahlstrom@nexusgroup.comSalesforce.comcmortimore@salesforce.comSCIMThe System for Cross-Domain Identity Management (SCIM) specification
is designed to make managing user identity in multi-domain based
applications and services easier using HTTP Protocol. Examples include
but are not limited to enterprise to cloud service providers, and
inter-cloud based scenarios. The specification suite seeks to build upon
experience with existing schemas and deployments, placing specific
emphasis on simplicity of development and integration, while applying
existing authentication, authorization, and privacy models. It's intent
is to reduce the cost and complexity of user management operations by
providing a common user schema and extension model, as well as binding
documents to provide patterns for exchanging this schema using standard
protocols. In essence, make it fast, cheap, and easy to move users in
to, out of, and around the cloud.The SCIM Protocol is an application-level, HTTP protocol for
provisioning and managing identity data on the web and in cross-domain
environments such as enterprise to cloud, or inter-cloud scenarios. The
protocol supports creation, modification, retrieval, and discovery of
core identity resources such as Users and Groups, as well as custom
resources and resource extensions.This document is intended as a guide to SCIM API usage for both
SCIM HTTP service providers and HTTP clients that may provision
information to service providers or retrieve information from
them.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. These
keywords are capitalized when used to unambiguously specify
requirements of the protocol or application features and behavior that
affect the interoperability and security of implementations. When
these words are not capitalized, they are meant in their
natural-language sense.For purposes of readability examples are not URL encoded.
Implementers MUST percent encode URLs as described in Section 2.1 .The SCIM HTTP protocol is described in
terms of a path relative to a Base URI. The Base URI MUST NOT
contain a query string as clients may append additional path
information and query parameters as part of forming the request.
Example: https://example.com/scim/For readability, all examples in this document are expressed
assuming the SCIM service root and the server root are the same.
It is expected that SCIM servers may be deployed using any URI
prefix. For example, a SCIM server might be have a prefix of
https://example.com/, or https://example.com/scim/tenancypath/.
Additionally client may also apply a version number to the server
root prefix (see ).Because SCIM builds on the HTTP protocol, it does not define a scheme
for authentication and authorization. SCIM depends on standard HTTP
authentication schemes. Implementers SHOULD support existing
authentication/authorization schemes. In particular, OAuth2 is RECOMMENDED. Appropriate security 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.All examples show an OAuth2 bearer token
(though it is not required) ; e.g.,The context of the request (i.e. the user for whom data is being
requested) MUST be inferred by service providers.The SCIM protocol specifies well known endpoints and HTTP methods for
managing resources defined in the core schema; i.e., User and Group
resources correspond to /Users and /Groups respectively. Service providers that
support extended resources SHOULD define resource endpoints using the
established convention; pluralize the resource name defined in the
extended schema by appending an 's'. Given there are cases where
resource pluralization is ambiguous; e.g., a resource named Person is legitimately Persons
and People clients SHOULD discover resource
endpoints via the /ResourceTypes
endpoint.Retrieves one or more complete or partial
resources.Depending on the endpoint, creates new resources,
create a search request, or may be used to bulk modify
resources.Modifies a resource by replacing existing
attributes with a specified set of replacement attributes (replace).
PUT MUST NOT be used to create new resources.Modifies a resource with a set of client
specified changes (partial update).Deletes a resource.ResourceEndpointOperationsDescriptionUser/UsersGET, POST, PUT, PATCH, DELETERetrieve, Add, Modify UsersGroup/GroupsGET, POST, PUT, PATCH, DELETERetrieve, Add, Modify GroupsService Provider Config/ServiceProvider ConfigsGETRetrieve service provider's configurationResource Type/ResourceTypesGETRetrieve supported resource typesSchema/SchemasGETRetrieve one or more supported schemas.Bulk/BulkPOSTBulk updates to one or more resourcesSearch[prefix]/.searchPOSTSearch from system root or within a resource endpoint for one or
more resource types using POST.All requests to the service provider are made via HTTP Methods as per
Section 4.3 on a URL derived from the Base
URL. Responses are returned in the body of the HTTP response, formatted
as JSON. Error status codes SHOULD be transmitted via the HTTP status
code of the response (if possible), and SHOULD also be specified in the
body of the response (see ).To create new resources, clients send HTTP POST requests to the
resource endpoint such as: /Users or
/Groups.Attributes in the request body, whose mutability is readOnly, SHALL be ignored.Attributes whose mutability is readWrite,
that are omitted from the request body, MAY be assumed to be not
asserted by the client. The service provider MAY assign a default
value to non-asserted attributes in the final resource representation.
Service providers MAY take into account whether a client has access
to, or understands, all of the resource's attributes when deciding
whether non-asserted attributes SHALL be defaulted. Clients that
intend to override server defaulted attributes, MAY specify null for a single-valued attribute or an empty
array [] for a multi-valued attribute to
clear all values.When the service provider successfully creates the new resource, an
HTTP response SHALL be returned with HTTP status 201
("Created"). The response body SHOULD contain the service provider's
representation of the newly created resource. The URI of the created
resource SHALL included in the HTTP Location
header and in JSON resource representation under the attribute meta.location. Since the server is free to alter
and/or ignore POSTed content, returning the full representation can be
useful to the client, enabling it to correlate the client and server
views of the new resource. If the service provider determines creation of the requested
resource conflicts with existing resources; e.g., a User resource with a duplicate userName, the service provider MUST return an
HTTP Status 409, with scimType error code
of uniqueness as per .Below, in the following example, a client sends a POST request
containing a User to the /Users endpoint.In response to the example request above, the server signals a
successful creation with an HTTP status code 201 (Created) and returns
a representation of the resource created.When adding a resource to a specific endpoint, the meta attribute
resourceType SHALL be set by the HTTP
service provider to the corresponding resource type for the
endpoint. For example, /Users will set
resourceType to User,
and /Groups will set resourceType to Group.Resources are retrieved via opaque, unique URLs or via Query. The
attributes returned are defined in the server's attribute schema (see
Section 10) and
request parameters (see ). By default, resource
attributes returned in a response are those whose schema returned setting is always
or default. To retrieve a known resource, clients send GET requests to the
resource endpoint; e.g., /Users/{id} or
/Groups/{id}, or /Schemas/{id}.If the resource exists the server responds with HTTP Status code
200 (OK) and includes the result in the body of the response.The below example retrieves a single User via the /Users endpoint.The server responds with:The SCIM protocol defines a standard set of query parameters that
can be used to filter, sort, and paginate to return zero or more
resources in a query response. Queries MAY be made against a single
resource or a resource type endpoint (e.g. /Users).
SCIM service providers MAY support additional query parameters not
specified here and SHOULD ignore any query parameters they do not
recognize.Responses MUST be identified using the following URI: urn:scim:api:messages:2.0:ListResponse. The
following attributes are defined for responses:The total number of results returned
by the list or query operation. This may not be equal to the
number of elements in the resources attribute of the list
response if pagination is requested.
REQUIRED.A multi-valued list of complex objects
containing the requested resources. This may be a subset of the
full set of resources if pagination is requested. REQUIRED if
totalResults is non-zero.The 1-based index of the first result
in the current set of list results. REQUIRED when partial
results returned due to pagination.The number of resources returned in a
list response page. REQUIRED when partial results returned due
to pagination.A query that does not return any matches SHALL return success
(HTTP Status 200) with totalResults set
to a value of 0.Queries MAY be performed against a SCIM resource object, a
resource type endpoint, or a SCIM server root. For example: /Users/{id}/Users/GroupsA query against a server root indicates that ALL resources
within the server SHALL be included subject to filtering. A filter
expression using meta.resourceType MAY
be used to restrict results to one or more specific resource types
(to exclude others). For example:If a SCIM service provider determines that too many results
would be returned (e.g. because a client queried a resource type
endpoint or the server base URI), the server SHALL reject the
request by returning an HTTP response with status
400 and json attribute scimType set to
tooMany (see ).When processing query operations across endpoints that include
more than one SCIM resource type (e.g. a query from the server
root endpoint), filters MUST be processed as outlined in . 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.Filtering is an OPTIONAL parameter for SCIM service providers.
Clients MAY discover service provider filter capabilities by
looking at the filter attribute of the
ServiceProviderConfig (see Section 8). Clients MAY
request a subset of resources by specifying the filter query parameter containing a filter
expression. When specified only those resources matching the
filter expression SHALL be returned. The expression language that
is used in the filter parameter supports references to attributes
and literals.Attribute names and attribute operators used in filters are
case insensitive. For example, the following two expressions will
evaluate to the same logical value:The filter parameter MUST contain at least one valid Boolean
expression. Each expression MUST contain an attribute name
followed by an attribute operator and optional value. Multiple
expressions MAY be combined using the two logical operators.
Furthermore expressions can be grouped together using "()".The operators supported in the expression are listed in the
following table.OperatorDescriptionBehavioreqequalThe attribute and operator values must be identical for a
match.nenot equalThe attribute and operator values are not identical.cocontainsThe entire operator value must be a substring of the
attribute value for a match.swstarts withThe entire operator value must be a substring of the
attribute value, starting at the beginning of the attribute
value. This criterion is satisfied if the two strings are
identical.ewends withThe entire operator value must be a substring of the
attribute value, matching at the end of the attribute value.
This criterion is satisfied if the two strings are
identical.prpresent (has value)If the attribute has a non-empty or non-null value, or if it
contains a non-empty node for complex attributes there is a
match. gtgreater thanIf the attribute value is greater than operator value, there
is a match. The actual comparison is dependent on the attribute
type. For string attribute types, this is a lexicographical
comparison and for DateTime types, it is a chronological
comparison. For Integer attributes it is a comparison by numeric
value. Boolean and Binary attributes SHALL cause a failed
response (HTTP Status 400) with scimType of invlaidFiler.gegreater than or equalIf the attribute value is greater than or equal to the
operator value, there is a match. The actual comparison is
dependent on the attribute type. For string attribute types,
this is a lexicographical comparison and for DateTime types, it
is a chronological comparison. For Integer attributes it is a
comparison by numeric value. Boolean and Binary attributes SHALL
cause a failed response (HTTP Status 400) with scimType of
invlaidFiler.ltless thanIf the attribute value is less than operator value, there is
a match. The actual comparison is dependent on the attribute
type. For string attribute types, this is a lexicographical
comparison and for DateTime types, it is a chronological
comparison. For Integer attributes it is a comparison by numeric
value. Boolean and Binary attributes SHALL cause a failed
response (HTTP Status 400) with scimType of invlaidFiler.leless than or equalIf the attribute value is less than or equal to the operator
value, there is a match. The actual comparison is dependent on
the attribute type. For string attribute types, this is a
lexicographical comparison and for DateTime types, it is a
chronological comparison. For Integer attributes it is a
comparison by numeric value. Boolean and Binary attributes SHALL
cause a failed response (HTTP Status 400) with scimType of
invlaidFiler.OperatorDescriptionBehaviorandLogical AndThe filter is only a match if both expressions evaluate to
true.orLogical orThe filter is a match if either expression evaluates to
true.notNot functionThe filter is a match if the expression evaluates to
false.OperatorDescriptionBehavior( )Precedence groupingBoolean expressions may be grouped using parentheses to
change the standard order of operations; i.e., evaluate OR
logical operators before logical AND operators.[ ]Complex attribute filter groupingService providers MAY support complex filters where
expressions MUST be applied to the same value of a parent
attribute specified immediately before the left square bracket
("["). The expression within square brackets ("[" and "]") MUST
be a valid filter expression based upon sub-attributes of the
parent attribute. Nested expressions MAY be used. See examples
below.In the above ABNF, the compValue
(comparison value) rule is built on JSON Data Interchange format
ABNF rules as specified in , DIGIT and ALPHA
are defined per Appendix B.1 of and,
URI is defined per Appendix A of.Filters MUST be evaluated using standard order of operations
. Attribute operators have
the highest precedence, followed by the grouping operator (i.e,
parentheses), followed by the logical AND operator, followed by
the logical OR operator.If the specified attribute in a filter expression is a
multi-valued attribute, the resource MUST match if any of the
instances of the given attribute match the specified criterion;
e.g. if a User has multiple emails values, only one has to match
for the entire User to match. For complex attributes, a fully
qualified Sub-Attribute MUST be specified using standard attribute
notation. For example, to filter by userName the parameter
value is userName and to filter by first name, the parameter value
is name.givenName.Providers MAY support additional filter operations if they
choose. Providers MUST decline to filter results if the specified
filter operation is not recognized and return a HTTP 400 error
with an appropriate human readable response. For example, if a
client specified an unsupported operator named 'regex' the service
provider should specify an error response description identifying
the client error; e.g., 'The operator 'regex' is not
supported.'String type attributes are case insensitive by default unless
the attribute type is defined as case exact. Attribute comparison
operators 'eq', 'co', and 'sw' MUST perform caseIgnore matching
for all string attributes unless the attribute is defined as case
exact. By default all string attributes are case insensitive.Clients MAY query by schema or schema extensions by using a
filter expression including the "schemas" attribute.Sort is OPTIONAL. Sorting allows clients to specify the order
in which resources are returned by specifying a combination of
sortBy and sortOrder URL parameters.The sortBy parameter specifies the
attribute whose value SHALL be used to order the returned
responses. If the sortBy attribute corresponds to a singular
attribute, resources are sorted according to that attribute's
value; if it's a multi-valued attribute, resources are sorted
by the value of the primary attribute (see Section 2.2), if
any, 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 standard attribute notation ; e.g.,
sortBy=name.givenName. For all
attribute types, if there is no data for the specified sortBy value they are sorted via the
sortOrder parameter; i.e., they
are ordered last if ascending and first if descending.The order in which the sortBy
parameter is applied. Allowed values are ascending
and descending. If a value for
sortBy is provided and no sortOrder is specified, the
sortOrder SHALL default to ascending. String type attributes
are case insensitive by default unless the attribute type is
defined as a case exact string. sortOrder
MUST sort according to the attribute type; i.e., for case
insensitive attributes, sort the result using case
insensitive, unicode alphabetic sort order, with no specific
locale implied and for case exact attribute types, sort the
result using case sensitive, Unicode alphabetic sort
order.Pagination parameters can be used together to "page through"
large numbers of resources so as not to overwhelm the client or
service provider. Pagination is not session based hence clients
SHOULD never assume repeatable results. For example, a request for
a list of 10 resources beginning with a startIndex of 1 may return
different results when repeated as a resource in the original
result could be deleted or new ones could be added in-between
requests. Pagination parameters and general behavior are derived
from the OpenSearch Protocol .The following table describes the URL pagination
parameters.ParameterDescriptionDefaultstartIndexThe 1-based index of the first query result. A value less
than 1 SHALL be interpreted as 1.1countNon-negative Integer. Specifies the desired maximum number of
query results per page; e.g., 10. A negative value SHALL be
interpreted as 0. A value of 0 indicates no resource results are to be
returned except for totalResults.None. When specified the service provider MUST not return
more results than specified though MAY return fewer results. If
unspecified, the maximum number of results is set by the service
provider.The following table describes the query response pagination
attributes specified by the service provider.ElementDescriptionitemsPerPageNon-negative Integer. Specifies the number of query results
returned in a query response page; e.g., 10.totalResultsNon-negative Integer. Specifies the total number of results
matching the client query; e.g., 1000.startIndexThe 1-based index of the first result in the current set of
query results; e.g., 1. Given the example above, to continue paging set the
startIndex to 11 and re-fetch; i.e.,
/Users?startIndex=11&count=10The following attributes control which attributes SHALL be
returned with a returned resource. SCIM clients MAY use up to one
of these two OPTIONAL parameters which MUST be supported by SCIM
service providers:A multi-valued list of strings
indicating the names of resource attributes to return in the
response overriding the set of attributes that would be
returned by default. Attribute names MUST be in standard.attribute
notation form. See additional retrieval
query parameters.A multi-valued list of
strings indicating the names of resource attributes to be
removed from the default set of attributes to return. This
parameter SHALL have no effect on attributes whose schema
returned setting is always see Server Schema.
Attribute names MUST be in standard attribute notation form.
See additional retrieval
query parameters. 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 query 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 .Query requests MUST be identified using the following URI:
'urn:scim:api:messages:2.0:SearchRequest'. The following attributes
are defined for query requests:A multi-valued list of strings
indicating the names of resource attributes to return in the
response overriding the set of attributes that would be returned
by default. Attribute names MUST be in standard attribute
notation form. See additional retrieval query
parameters. OPTIONAL.A multi-valued list of strings
indicating the names of resource attributes to be removed from
the default set of attributes to return. This parameter SHALL
have no effect on attributes whose schema returned
setting is always see Server Schema.
Attribute names MUST be in standard attribute notation form. See
additional retrieval query
parameters. OPTIONAL.The filter string used to request a subset
of resources. The filter string MUST be a valid filter expression.
OPTIONAL.A string indicating the attribute whose
value SHALL be used to order the returned responses. The sortBy
attribute MUST be in standard attribute notation form. See
sorting.
OPTIONAL.A string indicating the order in which
the sortBy parameter is applied. Allowed values are "ascending"
and "descending". See sorting. OPTIONAL.An integer indicating the 1-based index
of the first query result. See pagination. OPTIONAL.An integer indicating the desired maximum
number of query results per page. See pagination. OPTIONAL.After receiving a HTTP POST request, a response is returned as
specified in .Resources can be modified in whole or in part via PUT or PATCH,
respectively. Implementers MUST support PUT as specified in Section 4.3. Resources such as Groups may be
very large hence implementers SHOULD support HTTP PATCH to enable partial resource modifications.HTTP PUT is used to perform a full update of a resource's
attributes. Clients that MAY have previously retrieved the entire
resource in advance and revised it, MAY replace the resource using
an HTTP PUT. Because SCIM resource identifiers are typically
assigned by the service provider, HTTP PUT MUST NOT be used to
create new resources.As the operation intent is to replace all attributes, SCIM
clients MAY send all attributes regardless of each attribute's
mutability. The server will apply attribute by attribute replace
according to the following attribute mutability rules: Any values provided SHALL
replace the existing attribute values.If value(s) are already set for the
attribute, the input value(s) MUST match or HTTP status 400
SHOULD be returned with error code mutability.
If the service provider has no existing values, the new value(s)
SHALL be applied.Any values provided (e.g.
meta.resourceType) SHALL be ignored.If an attribute is required, clients
MUST specify the attribute in the PUT request.Attributes whose mutability is readWrite,
that are omitted from the request body, MAY be assumed to be not
asserted by the client. The service provider MAY assume any existing
values are to be cleared or the service provider MAY assign a
default value to the final resource representation. Service
providers MAY take into account whether a client has access to, or
understands, all of the resource's attributes when deciding whether
non-asserted attributes SHALL be removed or defaulted. Clients that
would like to override a server defaults, MAY specify null for a single-valued attribute or an empty
array [] for a multi-valued attribute to
clear all values.Unless otherwise specified a successful PUT operation returns a
200 OK response code and the entire resource within the response
body, enabling the client to correlate the client's and the service
provider's views of the updated resource. Example:HTTP PATCH is an OPTIONAL server function that enables clients to
update one or more attributes of a SCIM resource using a sequence of
operations to add, remove,
or replace values. The general form of
the SCIM patch request is based on JavaScript Object Notation (JSON)
Patch . One difference between SCIM patch
and JSON patch is that SCIM servers do not support array indexing
and may not support all operation
types.The body of an HTTP PATCH request MUST contain one or more patch
operation objects. A patch operation object MUST have exactly one
"op" member, whose value indicates the operation to perform and MAY
be one of add, remove,
or replace. The semantics of each
operation are defined below.Each operation object MUST contain the following schemas URI: urn:scim:api:messages:2.0:PatchOpThe ABNF rules, attrPath, valuePath, and subAttr
are defined in . The valuePath
rule allows specific values of a complex, multi-valued attribute to
be selected. Each operation against an attribute MUST be compatible with the
attribute's mutability and schema as defined in the Attribute Types Section
of. For example, a client MAY NOT modify an attribute that
has mutability readOnly or immutable. However, a client MAY add a value to an immutable
attribute if the attribute had no previous value. An operation that
is not compatibile with an attribute's mutability or schema SHALL
return the appropriate HTTP response status code and a JSON detail
error response as defined in .The attribute notation rules described in apply for describing attribute paths.
For all operations, the value of the schemas
attribute on the service provider's representation of the resource
SHALL be assumed by default. If one of the PATCH operations modifies
the schemas attribute, subsequent
operations SHALL assume the modified state of the schemas attribute. Clients MAY implicitly
modify the schemas attribute by adding
(or replacing) an attribute with its fully qualified name including
schema URN. For example, adding the attribute urn:scim:schemas:extension:enterprise:2.0:User:employeeNumber,
automatically adds the value urn:scim:schemas:extension:enterprise:2.0:User
to the resource's schemas attribute.Each patch operation represents a single action to be applied to
the same SCIM resource specified by the request URI. Operations are
applied sequentially in the order they appear in the array. Each
operation in the sequence is applied to the target resource; the
resulting resource becomes the target of the next operation.
Evaluation continues until all operations are successfully applied
or until an error condition is encountered.For a multi-valued attributes, a patch operation that sets a
value's primary attribute to true, SHALL cause the server to automatically
set primary to false
for any other values in the array as only one value MAY be
primary.A patch request, regardless of the number of operations, SHALL be
treated as atomic. If a single operation encounters an error
condition, the original SCIM resource MUST be restored, and a
failure status SHALL be returned.If a request fails, the server SHALL return an HTTP response
status code and a JSON detail error response as defined in .On successful completion, the server MUST return either a 200 OK
response code and the entire resource (subject to the "attributes"
query parameter - see Additional Retrieval Query
Parameters ) within the response body, or a 204 No Content
response code and the appropriate response headers for a successful
patch request. The server MUST return a 200 OK if the "attributes"
parameter is specified on the request.The add operation is used to add a
new attribute value to an existing resource.The operation MUST contain a value
member whose content specifies the value to be added. The value
MAY be a quoted value OR it may be a JSON object containing the
sub-attributes of the complex attribute specified in the
operation's path.The result of the add operation depends upon what the target
location indicated by path references:
If the target location does not exist, the attribute and
value is added.If the target location specifies a multi-valued attribute,
a new value is added to the attribute.if the target location specifies a single-valued attribute,
the existing value is replaced.If the target location specifies an attribute that does not
exist (has no value), the attribute is added with the new
value.If the target location exists, the value is replaced.If the target location already contains the value
specified, no changes SHOULD be made to the resource and a
success response SHOULD be returned. Unless other operations
change the resource, this operation SHALL NOT change the
modify timestamp of the resource.The "display" Sub-Attribute in this request is optional since
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 the resource and a success response should be returned.
The server responds with either the entire updated Group or no
response body:The remove operation removes the
value at the target location specified by the path.
The operation performs the following functions depending on the
target location specified by path :
If the target location is a single-value attribute, the
attribute and its associated value is removed and the
attribute SHALL be considered unassigned.If the target location is a multi-valued attribute and no
filter is specified, the attribute and all values are removed
and the attribute SHALL be considered unassigned.If the target location is a multi-valued attribute and a
complex filter is specified comparing a value,
the values matched by the filter are removed. If after removal
of the selected values, no other values remain, the
multi-valued attribute SHALL be considered unassigned.If the target location is a complex-multi-valued attribute
and a complex filter is specified based on the attribute's
sub-attributes, the matching records are removed.
Sub-attributes whose values have been removed SHALL be
considered unassigned. If the complex-multi-valued attribute
has no remaining records, the attribute SHALL be considered
unassigned.If an attribute is removed or becomes unassigned and is defined
as a required attribute or a read-only attribute, the server SHALL
return an HTTP response status code and a JSON detail error
response as defined in with a
scimType error of mutability.The following example shows how to remove a member from a
group. As 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 to the resource and a success response
should be returned.Note that server responses have been omitted for the rest of
the PATCH examples.The replace operation replaces the
value at the target location specified by the path.
The operation performs the following functions depending on the
target location specified by path :
If the target location is a single-value attribute, the
attributes value is replaced.If the target location is a multi-valued attribute and no
filter is specified, the attribute and all values are
replaced.If the target location is a multi-valued attribute and a
complex filter is specified comparing a value,
the values matched by the filter are replaced.If the target location is a complex-multi-valued attribute
and a complex filter is specified based on the attribute's
sub-attributes, the matching records are replaced.If the target location is a complex-multi-valued attribute
with a complex filter and a specific sub-attribute (e.g.
addresses[type eq "work"].streetAddress
), the matching sub-attribute of the matching record is
replaced.Clients request resource removal via DELETE. Service providers MAY
choose not to permanently delete the resource, but MUST return a 404
error code for all operations associated with the previously deleted
Id. Service providers MUST also omit the resource from future query
results. In addition the service provider SHOULD NOT consider the
deleted resource in conflict calculation. For example if a User
resource is deleted, a CREATE request for a User resource with the
same userName as the previously deleted resource should not fail with
a 409 error due to userName conflict.In response to a successful delete, the server SHALL respond with
successful HTTP status 204 (No Content). A non-normative example
response:Example: client attempt to retrieve the previously deleted UserServer Response:The SCIM bulk operation is an optional server feature that enables
clients to send a potentially large collection of resource operations
in a single request. The body of a a bulk operation contains a set of
HTTP resource operations using one of the API supported HTTP methods;
i.e., POST, PUT, PATCH or DELETE.Bulk requests are identified using the following URI:
'urn:scim:api:messages:2.0:BulkRequest'. Bulk responses are identified
using the following URI: 'urn:scim:api:messages:2.0:BulkResponse'.
Bulk requests and bulk responses share many attributes. Unless
otherwise specified, each attribute below is present in both bulk
requests and bulk responses.The following Singular Attribute is defined in addition to the
common attributes defined in SCIM core schema.An Integer specifying the number of
errors that the service provider will accept before the operation
is terminated and an error response is returned. OPTIONAL in a
request. Not valid in a response.The following Complex Multi-valued Attribute is defined in addition
to the common attributes defined in core schema.Defines operations within a bulk job.
Each operation corresponds to a single HTTP request against a
resource endpoint. REQUIRED. The HTTP method of the current operation.
Possible values are POST, PUT, PATCH or DELETE. REQUIRED.The transient identifier of a newly
created resource, unique within a bulk request and created by
the client. The bulkId serves as a surrogate resource id
enabling clients to uniquely identify newly created resources
in the Response and cross reference new resources in and
across operations within a bulk request. REQUIRED when method
is POST.The current resource version. Version is
MAY be used if the service provider supports ETags and the
method is PUT, PATCH, or DELETE.The resource's relative path. If the method
is POST the value must specify a resource type endpoint; e.g.,
/Users or /Groups whereas all other method values must specify
the path to a specific resource; e.g.,
/Users/2819c223-7f76-453a-919d-413861904646. REQUIRED in a
request.The resource data as it would appear for a
single POST, PUT or PATCH resource operation. REQUIRED in a
request when method is POST, PUT and PATCH.The resource endpoint URL. REQUIRED in
a response, except in the event of a POST failure.The HTTP response body to the specified
request operation. When indicating a response with an HTTP
status other than a 200 series response, the response body
MUST be included. For normal completion, the server MAY elect
to omit the response body.The HTTP response status code to the
requested operation. When indicating an error, the response attribute MUST contain the
detailed error response as per .If a bulk job is processed successfully the HTTP response code 200
OK MUST be returned, otherwise an appropriate HTTP error code MUST be
returned.The service provider MUST continue performing as many changes as
possible and disregard partial failures. The client MAY override this
behavior by specifying a value for the failOnErrors
attribute. The failOnErrors attribute defines the number of errors
that the service provider should accept before failing the remaining
operations returning the response.To be able to reference a newly created resource the attribute
bulkId MUST be specified when creating new resources. The bulkId is
defined by the client as a surrogate identifier in a POST operation.
The service provider MUST return the same bulkId together with the
newly created resource. The bulkId can then be used by the client to
map the service provider id with the bulkId of the created
resource.A SCIM service provider MAY elect to optimize a sequence operations
received (e.g. to improve processing performance). When doing so, the
service provider MUST ensure the clients intent is preserved and the
same stateful result is achieved as for non-optimized processing. For
example, before a User can be added to a
Group, they must first be created.
Processing these requests out of order, might result in a failure to
add the new User to the Group.The service provider response MUST include the result of all
processed operations. A location attribute
that includes the resource's endpoint MUST be returned for all
operations excluding failed POSTs. The status attribute includes
information about the success or failure of one operation within the
bulk job. The attribute status MUST include the code attribute that
holds the HTTP response code that would have been returned if a single
HTTP request would have been used. If an error occurred the status
MUST also include the description attribute containing a human
readable explanation of the error.The following is an example of a status in a failed operation.The following example shows how to add, update, and remove a user.
The failOnErrors attribute is set to '1' indicating the service
provider should return on the first error. The POST operation's bulkId
value is set to 'qwerty' enabling the client to match the new User
with the returned resource id
'92b725cd-9465-4e7d-8c16-01f8e146b87a'.The service provider returns the following response.The following response is returned if an error occurred when
attempting to create the User 'Alice'. The service provider stops
processing the bulk operation and immediately returns a response to
the client. The response contains the error and any successful results
prior to the error.If the failOnErrors attribute is not specified or the service
provider has not reached the error limit defined by the client the
service provider will continue to process all operations. The
following is an example in which all operations failed.The client can, within one bulk operation, create a new User, a new
Group and add the newly created User to the newly created Group. In
order to add the new User to the Group the client must use the
surrogate id attribute, bulkId, to reference the User. The bulkId
attribute value must be pre-pended with the literal "bulkId:"; e.g.,
if the bulkId is 'qwerty' the value is “bulkId:qwerty”. The service
provider MUST replace the string “bulkId:qwerty” with the permanent
resource id once created.The following example creates a User with the userName 'Alice' and
a Group with the displayName 'Tour Guides' with Alice as a member.The service provider returns the following response.A subsequent request for the 'Tour Guides' Group
('e9e30dba-f08f-4109-8486-d5c6a331660a') returns the following:Extensions that include references to other resources MUST be
handled in the same way by the service provider. The following example
uses the bulkId attribute within the enterprise extension managerId
attribute.The service provider MUST try to resolve circular cross references
between resources in a single bulk job but MAY stop after a failed
attempt and instead return the status code 409 Conflict. The following
example exhibits the potential conflict.If the service provider resolved the above circular references the
following is returned from a subsequent GET request.The service provider MUST define the maximum number of operations
and maximum payload size a client may send in a single request. If
either limits are exceeded the service provider MUST return the HTTP
response code 413 Request Entity Too Large. The returned response MUST
specify the limit exceeded in the body of the error response.The following example the client sent a request exceeding the
service provider's max payload size of 1 megabyte.Servers MUST accept requests and respond with JSON structured
responses using UTF-8 encoding , UTF-8 SHALL
be the default encoding format.Clients using other encodings MUST specify the format in which the
data is submitted via HTTP header Content-Type
as specified in Section 3.1.1.5 and MAY
specify the desired response data format via an HTTP Accept header ( Section
5.3.2 ); e.g., Accept: application/scim+json
or via URI suffix; e.g., Service providers MUST support the accept header Accept: application/scim+json and SHOULD support
header Accept: application/json both of
which specify JSON documents conforming to .
The format defaults to application/scim+json
if no format is specified.Singular attributes are encoded as string name-value-pairs in JSON;
e.g.,Multi-valued attributes in JSON are encoded as arrays; e.g.,Elements with nested elements are represented as objects in JSON;
e.g,For any SCIM operation where a resource representation is returned
(e.g. HTTP GET), the attributes returned are defined as the minimum
attribute set plus default attributes set. The minimum set are those
attributes whose schema have returned set
to always. The default attribute set are
those attributes whose schema have returned
set to default.Clients MAY request a partial resource representation on any
operation that returns a resource within the response by specifying
either of the mutually exclusive URL query parameters attributes OR excludedAtributes
as follows: When specified the default list of
attributes SHALL be overridden and each resource returned MUST
contain the minimum set of resource attributes and any attributes
or sub-attributes explicitly requested by the attributes
parameter. The query parameter attributes value is a comma
separated list of resource attribute names in standard attribute
notation form (e.g. userName, name, emails).When specified, each resource
returned MUST contain the minimal set of resource attributes.
Additionally, the default set of attributes minus those attributes
listed in excludedAttributes are also
returned. The query parameter attributes value is a comma
separated list of resource attribute names in standard attribute
notation form (e.g. userName, name, emails)..Giving the responseAll operations share a common scheme for referencing simple and
complex attributes. In general, attributes are identified by prefixing
the attribute name with its schema URN separated by a ':' character;
e.g., the core User resource attribute 'userName' is identified as
'urn:scim:schemas:core:2.0:User:userName'. Clients MAY omit core
schema attribute URN prefixes though MUST fully qualify extended
attributes with the associated resource URN; e.g., the attribute 'age'
defined in 'urn:scim:schemas:exampleCo:2.0:hr' is fully encoded as
'urn:scim:schemas:exampleCo:2.0:hr:age'. A Complex attributes'
Sub-Attributes are referenced via nested, dot ('.') notation; i.e.,
{urn}:{Attribute name}.{Sub-Attribute name}. For example, the fully
qualified path for a User's givenName is
urn:scim:schemas:core:2.0:User:name.givenName All facets (URN,
attribute and Sub-Attribute name) of the fully encoded Attribute name
are case insensitive.A client MAY use a URL of the form <base-URI>/Me
as a URI alias for the User or other resource associated with the
currently authenticated subject for any SCIM operation. A service
provider MAY respond in ONE of 3 ways: A service provider that does NOT support this feature SHOULD
respond with status 403 (FORBIDDEN).A service provider MAY choose to redirect the client using HTTP
status 308 to the resource associated with the authenticated
subject. The client MAY then repeat the request at the indicated
location.A service provider MAY process the SCIM request directly. In
any response, the HTTP "Location" header MUST be the permanent
location of the aliased resource associated with the authenticated
subject.The SCIM Protocol uses the HTTP status response status codes
defined in Section 6 to indicate
operation success or failure. In addition to returning a HTTP response
code implementers MUST return the errors in the body of the response
in the client requested format containing the error response and, per
the HTTP specification, human-readable explanations. Error responses
are identified using the following schema
URI: urn:scim:api:messages:2.0:Error. The
following attributes are defined for a SCIM error response using a
JSON body:The HTTP status code
(see Section 6). REQUIREDA SCIM detailed
error keyword. See . OPTIONALA detailed, human
readable message. OPTIONALImplementers SHOULD handle the identified HTTP status codes as
described below.StatusApplicabilitySuggested Explanation307 TEMPORARY REDIRECTGET, POST, PUT, PATCH, DELETEThe client is directed to repeat the same HTTP request at the
location identified. The client SHOULD NOT use the location provided
in the response as a permanent reference to the resource and SHOULD
continue to use the original request URI .308 PERMANENT REDIRECTGET, POST, PUT, PATCH, DELETEThe client is directed to repeat the same HTTP request at the
location identified. The client SHOULD use the location provided in
the response as the permanent reference to the resource .400 BAD REQUESTGET, POST, PUT, PATCH, DELETERequest is unparseable, syntactically incorrect, or violates
schema401 UNAUTHORIZEDGET, POST, PUT, PATCH, DELETEAuthorization failure403 FORBIDDENGET, POST, PUT, PATCH, DELETEServer does not support requested operation404 NOT FOUNDGET, PUT, PATCH, DELETESpecified resource (e.g., User) or end-point, does not exist409 CONFLICTPOST, PUT, PATCH, DELETEThe specified version number does not match the resource's latest
version number or a service provider refused to create a new,
duplicate resource412 PRECONDITION FAILEDPUT, PATCH,D ELETEFailed to update as resource {id} changed on the server last
retrieved413 REQUEST ENTITY TOO LARGEPOST{"maxOperations": 1000,"maxPayload": 1048576}500 INTERNAL SERVER ERRORGET, POST, PUT, PATCH, DELETEAn internal error. Implementers SHOULD provide descriptive
debugging advice501 NOT IMPLEMENTEDGET, POST, PUT, PATCH, DELETEService Provider does not support the request operation; e.g.,
PATCHFor HTTP Status 400 (Bad Request) responses, the following detail
error types are defined:scimTypeDescriptionApplicabilityinvalidFilterThe specified filter syntax was invalid (does not comply with
) or the specified attribute and filter
comparison combination is not supported.GET(), POST (Search - ), PATCH (Path Filter - )tooManyThe specified filter yields many more results than the server is
willing calculate or process. For example, a filter such as (userName pr) by itself would return all
entries with a userName and MAY not be
acceptable to the service provider.GET(), POST (Search - )uniquenessOne or more of attribute values is already in use or is
reserved.POST (Create - ), PUT (), PATCH ()mutabilityThe attempted modification is not compatible with the target
attributes mutability or current state (e.g. modification of an
immutable attribute with an existing value).PUT (), PATCH ()invalidSyntaxThe request body message structure was invalid or did not conform
to the request schema.POST (Search - , Create - , Bulk - ),
PUT ()invalidPathThe path attribute was invalid or malformed (see ).PATCH ()noTargetThe specified path did not yield an
attribute or attribute value that could be operated on. This occurs
when the specified path value contains a
filter that yields no match.PATCH ()invalidValueA required value was missing, or the value specified was not
compatible with the operation or attribute type (see Section 2.1
).GET (), POST (Create - , Query - ), PUT (), PATCH ()invalidVersThe specified SCIM protocol version is not supported (see ).GET (), POST (ALL), PUT (), PATCH (), DELETE ()Note that in the table above (), the
applicability table applies to the normal HTTP method but MAY apply
within a SCIM Bulk operation (via HTTP POST).Error example in response to a non-existent GET request.Error example in response to a PUT request.[[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?]]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 identifier is 'v2'. If specified, the version identifier MUST
appear in the URL path immediately preceding the resource endpoint and
conform to the following scheme: the character 'v' followed by the
desired SCIM version number; e.g., a version 'v2' User request is
specified as /v2/Users. When specified service providers MUST perform
the operation using the desired version or reject the request. When
omitted service providers SHOULD perform the operation using the most
recent SCIM protocol version supported by the service provider.The SCIM protocol supports resource versioning via standard HTTP
ETags Section 2.3. Service providers
MAY support weak ETags as the preferred mechanism for performing
conditional retrievals and ensuring clients do not inadvertently
overwrite each others changes, respectively. When supported SCIM ETags
MUST be specified as an HTTP header and SHOULD be specified within the
'version' attribute contained in the resource's 'meta' attribute.Example:The server responds with an ETag in the response header and meta
structure.With the returned ETag, clients MAY choose to retrieve the resource
only if the resource has been modified.Conditional retrieval example using If-None-Match Section 3.2 header:If the resource has not changed the service provider simply returns
an empty body with a 304 "Not Modified" response code.If the service providers supports versioning of resources the
client MAY supply an If-Match Section
3.1 header for PUT and PATCH operations to ensure that the
requested operation succeeds only if the supplied ETag matches the
latest service provider resource; e.g., If-Match:
W/"e180ee84f0671b1"To increase the likelihood that the input and comparison of unicode
usernames and passwords will work in ways that make sense for typical
users throughout the world there are special string preparation and
comparison methods (PRECIS) that MUST be followed for usernames and
passwords. Before comparing or evaluating uniqueness of a userName or password
attribute, service providers MUST use the "PRECIS" profile described in
Sections 4 and 5 respectively of and is based on the "PRECIS"
framework specification .A single service provider may expose the SCIM protocol to multiple
clients. Depending on the nature of the service, the clients may have
authority to access and alter resources initially created by other
clients. Alternatively, clients may expect to access disjoint sets of
resources, and may expect that their resources are inaccessible by other
clients. These scenarios are called "multi-tenancy", where each client
is understood to be or represent a "tenant" of the service provider.
Clients may also be multi-tenanted.The following common cases may occur: All clients share all resources (no tenancy)Each single client creates and accesses a private subset of
resources (1 client:1 Tenant)Sets of clients share sets of resources (M clients:1 Tenant)One client to Multiple Tenants (1 client: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 clients
and service providers interact for: Registering or provisioning TenantsAssociating a subset of clients with a subset of the TenantsIndicating which tenant is associated with the data in a request
or response, or indicating which Tenant is the subject of a
queryThe service provider MAY use the authentication mechanism (Section
2) to determine the identity of the client, and thus infer the
associated Tenant.For implementations where a client 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 client 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
client may explicitly specify a Tenant while being implicitly
associated with a different Tenant.In all of these methods, the {tenant_id} is a unique identifier for
the Tenant as defined by the service provider. A URL prefix: https://www.example.com/Tenants/{tenant_id}/v2/UsersA sub-domain: https://{tenant_id}.example.com/v2/GroupsThe service provider may recognize a {tenant_id} provided by
the client in an HTTP Header as the indicator of the desired
target Tenant.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 client, is required to be unique
ONLY within the resources associated with the associated Tenant.The SCIM Protocol layers on top of Hypertext Transfer Protocol and
thus subject to the security considerations of HTTP Section 9 and its related specifications.SCIM resources (e.g., Users and Groups) can contain sensitive
information. Therefore, SCIM clients and service providers MUST
implement TLS. Which version(s) ought to be implemented will vary over
time, and depend on the widespread deployment and known security
vulnerabilities at the time of implementation. At the time of this
writing, TLS version 1.2 is the most recent
version, but has very limited actual deployment, and might not be
readily available in implementation toolkits. TLS version 1.0 is the most widely deployed version, and will give
the broadest interoperability.As mentioned in ,Section 9.4, SCIM
clients requesting information using query filters using HTTP GET
SHOULD give consideration to the information content of the filters
and whether their exposure in a URI would represent a breach of
security or confidentiality through leakage in a web browsers or
server logs. This is particularly true for information that is legally
considered "personally identifiable information" or is otherwise
restricted by privacy laws. In these situations to ensure maximum
security and confidentiality, clients SHOULD query using HTTP POST
(see ).Servers that receive HTTP GET requests using filters that contain
restricted or confidential information SHOULD respond with HTTP status
403 indicating the operation is FORBIDDEN. A detailed error, confidential_restricted may be returned
indicating the request must be submitted using POST. A non-normative
example: As an HTTP based protocol, implementers of SCIM SHOULD consider all
security considerations of the HTTP/1.1 as enumerated in Section 1As stated in Section 2.7.1, 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.An attacker may obtain valid username/password combinations from
the SCIM service provider's underlying database by gaining access to
the database and/or launching injection attacks. This could lead to
unintended disclosure of username/password combinations. The impact
may extend beyond the domain of the SCIM service provider if the data
was provisioned from other domains.Administrators should undertake industry best practices to protect
the storage of credentials and in particular SHOULD follow
recommendations outlines in Section 5.1.4.1 .
These recommendations include but are not limited to:Provide injection attack counter measures (e.g. by validating
all inputs and parameters),No cleartext storage of credentials,Store credentials using an encrypted protection mechanism,
andAvoid passwords and consider use of asymmetric cryptography
based credentials.As outlined in Section 5.1.4.2,
adminitrators SHOULD take counter measures to prevent online attacks
on secrets such as:Utilize secure password policy in order to increase user
password entrophy to hinder online attacks and password
guessing,Mitigate attacks on passwords by locking respective accounts
have a number of failed attempts,Use "tar pit" techniques by temporarily locking a respective
account and delaying responses for a certain duration. The
duration may increase with the number of failed attempts, andUse authentication system that use CAPTCHA's and other factors
for authenticating users further reducing the possibility of
automated attacks.When comparing unicode strings such as in query filters or testing
for uniqueness of usernames and passwords, strings MUST be
appopriately prepared before comparison. See .ietf-types@iana.orgRegistration of media type
application/scim+jsonapplicationscim+jsonnonenone8bitSee The application/scim+json media type is intended
to identify JSON structure data that conforms to the SCIM protocol
and schema specifications. Older versions of SCIM are known to
informally use application/json.[[this document]]It is
expected that applications that use this type may be special
purpose applications intended for inter-domain provisioning.
Clients may also be applications (e.g. mobile applications) that
need to use SCIM for self-registration of user accounts. SCIM
services may be offered by web applications that offer support for
standards based provisioning or may be a dedicated SCIM service
provider such as a "cloud directory". Content may be treated as
equivalent to application/json type
for the purpose of displaying in web browsers.Magic number(s):File extension(s): .scim .scmMacintosh file type code(s):SCIM
mailing list <scim@ietf.org>COMMON* (see restrictions)For most client types, it is
sufficient to recognize the content as equivalent to application/json. Applications intending to
use SCIM protocol SHOULD use the application/scim+json media
type.Phil HuntIETFAs per the IANA SCIM Schema Registry in , the following registers and
extends the SCIM Schema Registry to define SCIM protocol
request/response JSON schema URN identifier prefix of urn:scim:api:messages:2.0 which is part of the
URN sub-Namespace for SCIM. There is no specific associated resource
type.Schema URINameReferenceurn:scim:api:messages:2.0:ListResponseList/Query ResponseSee urn:scim:api:messages:2.0:SearchRequestPOST Query RequestSee urn:scim:api:messages:2.0:PatchOpPatch OperationSee urn:scim:api:messages:2.0:BulkRequestBulk Operations RequestSee urn:scim:api:messages:2.0:BulkResponseBulk Operations ResponseSee urn:scim:api:messages:2.0:ErrorError ResponseSee Language Subtag RegistryInternet Assigned Numbers Authority
(IANA)OpenSearch Protocol 1.1, Draft 5A9.orgOrder of Operations: Programming LanguagesWikipediaSamuel Erdtman (samuel@erdtman.se)Patrick Harding (pharding@pingidentity.com)The editors would like to acknowledge the contribution and work of
the past draft editors: Trey Drake, UnboundIDChuck Mortimore, SalesforceThe editor would like to thank the participants in the the SCIM
working group for their support of this specification.[[This section to be removed prior to publication as an RFC]]Draft 02 - KG - Addition of schema extensibilityDraft 03 - PH - Revisions based on following tickets: 24 - Add filter negation39 - Clarification on response for DELETE42 - Make root searches optional49 - Add "ew" filter50 - Filters for multi-valued complex attributes51 - Search by Schema53 - Standard use of term client (some was consumer)55 - Redirect support (3xx)56 - Make manager attribute consistent with other $ref attrs57 - Update all "/v1" examples to '/v2"59 - Fix capitalization per IETF editor practices60 - Changed <eref> tags to normal <xref> and
<reference> tagsDraft 04 - PH - Revisions based on the following tickets: 18 - New PATCH command based on JSON Patch (RFC6902)- Provided ABNF specification for filters (used in PATCH)- Updated references to RFC4627 to RFC7159Draft 05 - PH - Revisions based on the following tickets: 03 - Support for excludedAttributes parameter13 - Change client use of Etags from MUST to MAY (correction)23 - Clarifications regarding case exact processing.41 - Add IANA considerations65 - Removed X-HTTP-Method-Override support69 - Added clarifications to intro to align with
draft-nottingham-uri-get-off-my-lawn70 - Remove SCIM_TENANT_ID header72 - Added text to indicate UTF-8 is default and mandatory
encoding format per BCP1874 - Added security considerations for using GET with
confidential attribute filters- corrected error response in JSON PATCH operationDraft 06 - PH - Revisions based on the following tickets and
editorial changes 41 - Revised content types from application/json to
application/scim+json, registered API schemas63 - Revised uri schema prefixes for API json message schemas66 - Updated references for RFC2616 to HTTPbis75 - Added security considerations for International Strings and
"PRECIS" support76 - Clarified handling of PUT (& POST) with regards to
mutability and default values- Corrected version numbers in sec 3.11 API Versioning to v2
(from v1)- Clarified that no filter matches should return success
totalResults=0Draft 07 - PH - Revisions regarding support of detailed errors
(Tickets 37, 46, 67)Draft 08 - PH - Revisions as follows- Added clarification on schemas handling during PATCH
operation- Revised example URN in Attribute Notation section to comply
with IANA namespace rules- Fixed typo in ABNF, attrExpr should be attrExp- Added more security considerations for HTTP and sensitive
data- Revised authentication and authorization sections for greater
clarity.- Replaced the word "search" with "query" for consistency- Clarified sucessful resource creation response- Added clarification on primary value handling in PATCH
(consistent with draft 03)- Revised SCIM Bullk error handling to conform with draft 07
error handling