System for Cross-Domain Identity Management: Protocol
draft-ietf-scim-api-18
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7644.
|
|
|---|---|---|---|
| Authors | Phil Hunt , Kelly Grizzle , Morteza Ansari , Erik Wahlstroem , Chuck Mortimore | ||
| Last updated | 2015-05-14 (Latest revision 2015-05-11) | ||
| Replaces | draft-scim-api | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
GENART Last Call review
(of
-16)
by Francis Dupont
Ready w/nits
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Leif Johansson | ||
| Shepherd write-up | Show Last changed 2015-03-17 | ||
| IESG | IESG state | Became RFC 7644 (Proposed Standard) | |
| Consensus boilerplate | Yes | ||
| Telechat date |
(None)
Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass. |
||
| Responsible AD | Barry Leiba | ||
| Send notices to | draft-ietf-scim-api@ietf.org, draft-ietf-scim-api.shepherd@ietf.org, draft-ietf-scim-api.ad@ietf.org, scim-chairs@ietf.org | ||
| IANA | IANA review state | IANA OK - Actions Needed |
draft-ietf-scim-api-18
"
},
{
"location":
"https://example.com/v2/Users/b7c14771-226c-4d05-8860-134711653041",
"method": "PUT",
"version": "W\/\"huJj29dMNgu3WXPD\"",
"status": "200"
},
{
"location":
"https://example.com/v2/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
"method": "PATCH",
"version": "W\/\"huJj29dMNgu3WXPD\"",
"status": "200"
},
{
"location":
"https://example.com/v2/Users/e9025315-6bea-44e1-899c-1e07454e468b",
"method": "DELETE",
"status": "204"
}
]
}
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.
Hunt, et al. Expires November 12, 2015 [Page 58]
Internet-Draft draft-ietf-scim-api May 2015
HTTP/1.1 200 OK
Content-Type: application/scim+json
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:BulkResponse"],
"Operations": [
{
"method": "POST",
"bulkId": "qwerty",
"status": "400",
"response":{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"scimType":"invalidSyntax"
"detail":
"Request is unparsable, syntactically incorrect, or violates schema.",
"status":"400"
}
}
]
}
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.
HTTP/1.1 200 OK
Content-Type: application/scim+json
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:BulkResponse"],
"Operations": [
{
"method": "POST",
"bulkId": "qwerty",
"status": "400",
"response":{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"scimType":"invalidSyntax"
"detail":
"Request is unparsable, syntactically incorrect, or violates schema.",
"status":"400"
}
},
{
"location":
"https://example.com/v2/Users/b7c14771-226c-4d05-8860-134711653041",
Hunt, et al. Expires November 12, 2015 [Page 59]
Internet-Draft draft-ietf-scim-api May 2015
"method": "PUT",
"status": "412",
"response":{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"detail":"Failed to update. Resource changed on the server.",
"status":"412"
}
},
{
"location":
"https://example.com/v2/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
"method": "PATCH",
"status": "412",
"response":{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"detail":"Failed to update. Resource changed on the server.",
"status":"412"
}
},
{
"location":
"https://example.com/v2/Users/e9025315-6bea-44e1-899c-1e07454e468b",
"method": "DELETE",
"status": "404",
"response":{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"detail":"Resource does not exist.",
"status":"404"
}
}
]
}
Hunt, et al. Expires November 12, 2015 [Page 60]
Internet-Draft draft-ietf-scim-api May 2015
HTTP/1.1 200 OK
Content-Type: application/scim+json
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:BulkResponse"],
"Operations": [
{
"location":
"https://example.com/v2/Users/92b725cd-9465-4e7d-8c16-01f8e146b87a",
"method": "POST",
"bulkId": "qwerty",
"version": "W\/\"4weymrEsh5O6cAEK\"",
"status": "201"
},
{
"location":
"https://example.com/v2/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a",
"method": "POST",
"bulkId": "ytrewq",
"version": "W\/\"lha5bbazU3fNvfe5\"",
"status": "201"
}
]
}
3.7.4. Maximum Operations
The service provider MUST define the maximum number of operations and
maximum payload size a client may send in a single request. These
limits MAY be retrieved from the service provider Configuration (see
'bulk' in Section 5 and 8.5 of [I-D.ietf-scim-core-schema]). 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:
POST /v2/Bulk
Host: example.com
Accept: application/scim+json
Content-Type: application/scim+json
Authorization: Bearer h480djs93hd8
Content-Length: 4294967296
...
Hunt, et al. Expires November 12, 2015 [Page 61]
Internet-Draft draft-ietf-scim-api May 2015
In response to the over-sized request, the server responds with the
following error:
HTTP/1.1 413 Request Entity Too Large
Content-Type: application/scim+json
{
"schemas":["urn:ietf:params:scim:api:messages:2.0:Error"],
"status": "413",
"detail":
"The size of the bulk operation exceeds the maxPayloadSize (1048576)."
}
3.8. Data Input/Output Formats
Servers MUST accept requests and respond with JSON structured
responses using UTF-8 encoding [RFC3629], 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 [RFC7231] and MAY specify the desired response data
format via an HTTP "Accept" header ( Section 5.3.2 [RFC7231] ); e.g.,
"Accept: application/scim+json" or via URI suffix; e.g.,
GET /Users/2819c223-7f76-453a-919d-413861904646.scim
Host: example.com
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
[RFC7159]. 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.,
"attribute": "value"
Multi-valued attributes in JSON are encoded as arrays; e.g.,
"attributes": [ "value1", "value2" ]
Elements with nested elements are represented as objects in JSON;
e.g,
"attribute": { "subattribute1": "value1", "subattribute2": "value2" }
Hunt, et al. Expires November 12, 2015 [Page 62]
Internet-Draft draft-ietf-scim-api May 2015
3.9. Additional Operation Response Parameters
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
"excludedAttributes" as follows:
attributes 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 (Section 3.10) form (e.g., userName, name,
emails).
excludedAttributes 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 (Section 3.10) form (e.g., userName, name, emails).
.
GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=userName
Host: example.com
Accept: application/scim+json
Authorization: Bearer h480djs93hd8
Giving the response
Hunt, et al. Expires November 12, 2015 [Page 63]
Internet-Draft draft-ietf-scim-api May 2015
HTTP/1.1 200 OK
Content-Type: application/scim+json
Location:
https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646
ETag: W/"a330bc54f0671c9"
{
"schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
"id":"2819c223-7f76-453a-919d-413861904646",
"userName":"bjensen",
"meta":{
"resourceType": "User",
"created":"2011-08-01T18:29:49.793Z",
"lastModified":"2011-08-01T18:29:49.793Z",
"location":
"https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646",
"version":"W\/\"a330bc54f0671c9\""
}
}
3.10. Attribute Notation
All 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:ietf:params: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:ietf:params:scim:schemas:exampleCo:2.0:hr" is fully encoded as
"urn:ietf:params:scim:schemas:exampleCo:2.0:hr:age". 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:ietf:params: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.
3.11. "/Me" Authenticated Subject Alias
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:
Hunt, et al. Expires November 12, 2015 [Page 64]
Internet-Draft draft-ietf-scim-api May 2015
o A service provider that does NOT support this feature SHOULD
respond with status 403 (FORBIDDEN).
o 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.
o 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.
When using the SCIM Create Resource command (HTTP POST) with the
"/Me" alias, the desired resourceType being created is at the
discretion of the service provider based on the authenticated subject
(if not anonymous) making the request and any request body attributes
(e.g., "schemas"). See Section 7.6 for information on security
considerations related to this operation.
3.12. HTTP Status and Error Response Handling
The SCIM Protocol uses the HTTP status response status codes defined
in Section 6 [RFC7231] 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:ietf:params:scim:api:messages:2.0:Error". The following
attributes are defined for a SCIM error response using a JSON body:
status
The HTTP status code (see Section 6 [RFC7231]) expressed as a JSON
String. REQUIRED
scimType
A SCIM detailed error keyword. See Table 8. OPTIONAL
detail
A detailed, human readable message. OPTIONAL
Implementers SHOULD handle the identified HTTP status codes as
described below.
+--------------+---------------+------------------------------------+
| Status | Applicability | Suggested Explanation |
+--------------+---------------+------------------------------------+
Hunt, et al. Expires November 12, 2015 [Page 65]
Internet-Draft draft-ietf-scim-api May 2015
| 307 | GET, POST, | The client is directed to repeat |
| TEMPORARY | PUT, PATCH, | the same HTTP request at the |
| REDIRECT | DELETE | 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 |
| | | [RFC7231]. |
| 308 | GET, POST, | The client is directed to repeat |
| PERMANENT | PUT, PATCH, | the same HTTP request at the |
| REDIRECT | DELETE | location identified. The client |
| | | SHOULD use the location provided |
| | | in the response as the permanent |
| | | reference to the resource |
| | | [RFC7538]. |
| 400 BAD | GET, POST, | Request is unparsable, |
| REQUEST | PUT, PATCH, | syntactically incorrect, or |
| | DELETE | violates schema |
| 401 | GET, POST, | Authorization failure. The |
| UNAUTHORIZED | PUT, PATCH, | authorization header is invalid or |
| | DELETE | missing. |
| 403 | GET, POST, | Operation is not permitted based |
| FORBIDDEN | PUT, PATCH, | on the supplied authorization. |
| | DELETE | |
| 404 NOT | GET, POST, | Specified resource (e.g., User) or |
| FOUND | PUT, PATCH, | end-point, does not exist |
| | DELETE | |
| 409 CONFLICT | POST, PUT, | The specified version number does |
| | PATCH, DELETE | not match the resource's latest |
| | | version number or a service |
| | | provider refused to create a new, |
| | | duplicate resource |
| 412 | PUT, PATCH,D | Failed to update as resource {id} |
| PRECONDITION | ELETE | changed on the server last |
| FAILED | | retrieved |
| 413 REQUEST | POST | {"maxOperations": |
| ENTITY TOO | | 1000,"maxPayload": 1048576} |
| LARGE | | |
| 500 INTERNAL | GET, POST, | An internal error. Implementers |
| SERVER ERROR | PUT, PATCH, | SHOULD provide descriptive |
| | DELETE | debugging advice |
| 501 NOT | GET, POST, | Service Provider does not support |
| IMPLEMENTED | PUT, PATCH, | the request operation; e.g., PATCH |
| | DELETE | |
+--------------+---------------+------------------------------------+
Table 7: SCIM HTTP Status Code Usage
Hunt, et al. Expires November 12, 2015 [Page 66]
Internet-Draft draft-ietf-scim-api May 2015
For HTTP Status 400 (Bad Request) responses, the following detail
error types are defined:
+--------------+------------------------------+---------------------+
| scimType | Description | Applicability |
+--------------+------------------------------+---------------------+
| invalidFilte | The specified filter syntax | GET(Section 3.4.2), |
| r | was invalid (does not comply | POST (Search - |
| | with Figure 1) or the | Section 3.4.3), |
| | specified attribute and | PATCH (Path Filter |
| | filter comparison | - Section 3.5.2) |
| | combination is not | |
| | supported. | |
| tooMany | The specified filter yields | GET(Section 3.4.2), |
| | many more results than the | POST (Search - |
| | server is willing calculate | Section 3.4.3) |
| | 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. | |
| uniqueness | One or more of attribute | POST (Create - |
| | values is already in use or | Section 3.3), PUT |
| | is reserved. | (Section 3.5.1), |
| | | PATCH (Section |
| | | 3.5.2) |
| mutability | The attempted modification | PUT (Section |
| | is not compatible with the | 3.5.1), PATCH |
| | target attributes mutability | (Section 3.5.2) |
| | or current state (e.g., | |
| | modification of an immutable | |
| | attribute with an existing | |
| | value). | |
| invalidSynta | The request body message | POST (Search - |
| x | structure was invalid or did | Section 3.4.2, |
| | not conform to the request | Create - Section |
| | schema. | 3.3, Bulk - Section |
| | | 3.7), PUT (Section |
| | | 3.5.1) |
| invalidPath | The path attribute was | PATCH (Section |
| | invalid or malformed (see | 3.5.2) |
| | Figure 7). | |
| noTarget | The specified "path" did not | PATCH (Section |
| | yield an attribute or | 3.5.2) |
| | attribute value that could | |
| | be operated on. This occurs | |
Hunt, et al. Expires November 12, 2015 [Page 67]
Internet-Draft draft-ietf-scim-api May 2015
| | when the specified "path" | |
| | value contains a filter that | |
| | yields no match. | |
| invalidValue | A required value was | GET (Section |
| | missing, or the value | 3.4.2), POST |
| | specified was not compatible | (Create - Section |
| | with the operation or | 3.3, Query - |
| | attribute type (see Section | Section 3.4.2), PUT |
| | 2.2 [I-D.ietf-scim-core-sche | (Section 3.5.1), |
| | ma]), or resource schema | PATCH (Section |
| | (see Section 4 [I-D.ietf-sci | 3.5.2) |
| | m-core-schema]). | |
| invalidVers | The specified SCIM protocol | GET (Section |
| | version is not supported | 3.4.2), POST (ALL), |
| | (see Section 3.13). | PUT (Section |
| | | 3.5.1), PATCH |
| | | (Section 3.5.2), |
| | | DELETE (Section |
| | | 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
Note that in the table above (Table 8), 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.
HTTP/1.1 404 NOT FOUND
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"detail":"Resource 2819c223-7f76-453a-919d-413861904646 not found",
"status": "404"
}
Error example in response to a PUT request.
Hunt, et al. Expires November 12, 2015 [Page 68]
Internet-Draft draft-ietf-scim-api May 2015
HTTP/1.1 400 BAD REQUEST
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"scimType":"mutability"
"detail":"Attribute 'id' is readOnly",
"status": "400"
}
3.13. API Versioning
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.
3.14. Versioning Resources
The SCIM protocol supports resource versioning via standard HTTP
ETags Section 2.3 [RFC7232]. 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:
Hunt, et al. Expires November 12, 2015 [Page 69]
Internet-Draft draft-ietf-scim-api May 2015
POST /Users HTTP/1.1
Host: example.com
Content-Type: application/scim+json
Authorization: Bearer h480djs93hd8
Content-Length: ...
{
"schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
"userName":"bjensen",
"externalId":"bjensen",
"name":{
"formatted":"Ms. Barbara J Jensen III",
"familyName":"Jensen",
"givenName":"Barbara"
}
}
The server responds with an ETag in the response header and meta
structure.
HTTP/1.1 201 Created
Content-Type: application/scim+json
Location:
https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646
ETag: W/"e180ee84f0671b1"
{
"schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
"id":"2819c223-7f76-453a-919d-413861904646",
"meta":{
"resourceType":"User",
"created":"2011-08-01T21:32:44.882Z",
"lastModified":"2011-08-01T21:32:44.882Z",
"location":
"https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646",
"version":"W\/\"e180ee84f0671b1\""
},
"name":{
"formatted":"Ms. Barbara J Jensen III",
"familyName":"Jensen",
"givenName":"Barbara"
},
"userName":"bjensen"
}
With the returned ETag, clients MAY choose to retrieve the resource
only if the resource has been modified.
Hunt, et al. Expires November 12, 2015 [Page 70]
Internet-Draft draft-ietf-scim-api May 2015
Conditional retrieval example using If-None-Match Section 3.2
[RFC7233] header:
GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=displayName
Host: example.com
Accept: application/scim+json
Authorization: Bearer h480djs93hd8
If-None-Match: W/"e180ee84f0671b1"
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.2 [RFC7233] 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"
4. Service Provider Configuration Endpoints
SCIM 2 defines 3 endpoints to facilitate discovery of SCIM service
provider features and schema that MAY be retrieved using HTTP GET:
/ServiceProviderConfig
An HTTP GET to this endpoint will return a JSON structure that
describes the SCIM specification features available on a service
provider. This endpoint SHALL return responses with a JSON object
using a "schemas" attribute of
"urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig".
The attributes returned in the JSON object are defined in
Section 5 [I-D.ietf-scim-core-schema]. An example representation
of SCIM service provider configuration may be found in Section 8.5
[I-D.ietf-scim-core-schema].
/Schemas
An HTTP GET to this endpoint is used to retrieve information about
resource schemas supported by a SCIM service provider. An HTTP
GET to the endpoint "/Schemas" SHALL return all supported schemas
in ListResponse format (see Figure 3). Individual schema
definitions can be returned by appending the schema URI to the
schemas endpoint. For example:
/Schemas/urn:ietf:params:scim:schemas:core:2.0:User
The contents of each schema returned is described in Section 7
[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].
Hunt, et al. Expires November 12, 2015 [Page 71]
Internet-Draft draft-ietf-scim-api May 2015
/ResourceTypes
An HTTP GET to this endpoint is used to discover the types of
resources available on a SCIM service provider (e.g., Users and
Groups). Each resource type defines the endpoints, the core
schema URI that defines the resource, and any supported schema
extensions. The attributes defining a resource type can be found
in Section 6 [I-D.ietf-scim-core-schema], and an example
representation can be found in Section 8.6
[I-D.ietf-scim-core-schema].
In cases where a request is for a specific "ResourceType" or
"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
multiple ResourceTypes or Schemas, the message form described by
"urn:ietf:params:scim:api:messages:2.0:ListResponse" (ListResponse)
form SHALL be used as shown in Figure 3 and Figure 9 below. Query
parameters described in section 3.2 such as, sorting, attributes, and
paging SHALL be ignored. If a "filter" is provided, the service
provider SHOULD respond with HTTP Status 403 (FORBIDDEN) to ensure
clients cannot incorrectly assume any matching conditions specified
in a filter are true.
Hunt, et al. Expires November 12, 2015 [Page 72]
Internet-Draft draft-ietf-scim-api May 2015
The following is a non-normative example of an HTTP GET to the
/ResourceTypes endpoint:
{
"totalResults":2,
"itemsPerPage":10,
"startIndex":1,
"schemas":["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
"Resources":[{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"],
"id":"User",
"name":"User",
"endpoint": "/Users",
"description": "User Account",
"schema": "urn:ietf:params:scim:schemas:core:2.0:User",
"schemaExtensions": [{
"schema":
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User",
"required": true
}],
"meta": {
"location":"https://example.com/v2/ResourceTypes/User",
"resourceType": "ResourceType"
}
},
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"],
"id":"Group",
"name":"Group",
"endpoint": "/Groups",
"description": "Group",
"schema": "urn:ietf:params:scim:schemas:core:2.0:Group",
"meta": {
"location":"https://example.com/v2/ResourceTypes/Group",
"resourceType": "ResourceType"
}
}]
}
Figure 9: Example Resource Type JSON Representation
5. Preparation and Comparison of Internationalized Strings
To increase the likelihood that the input and comparison of usernames
and passwords will work in ways that make sense for typical users
throughout the world, there are rules for preparing, enforcing, and
comparing internationalized strings that represent usernames and
passwords. Before comparing or evaluating uniqueness of a "userName"
Hunt, et al. Expires November 12, 2015 [Page 73]
Internet-Draft draft-ietf-scim-api May 2015
or "password" attribute, service providers MUST use the "PRECIS"
profile described in Sections 4 and 5 respectively of
[I-D.ietf-precis-saslprepbis] which is based on the "PRECIS"
framework specification [I-D.ietf-precis-framework].
6. Multi-Tenancy
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:
1. All clients share all resources (no tenancy)
2. Each single client creates and accesses a private subset of
resources (1 client:1 Tenant)
3. Sets of clients share sets of resources (M clients:1 Tenant)
4. 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:
o Registering or provisioning Tenants
o Associating a subset of clients with a subset of the Tenants
o Indicating which tenant is associated with the data in a request
or response, or indicating which Tenant is the subject of a query
6.1. Associating Clients to Tenants
The service provider MAY use the authentication mechanism (Section 2)
to determine the identity of the client, and thus infer the
associated Tenant.
Hunt, et al. Expires November 12, 2015 [Page 74]
Internet-Draft draft-ietf-scim-api May 2015
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.
o A URL prefix: "https://www.example.com/Tenants/{tenant_id}/v2/
Users"
o A sub-domain: "https://{tenant_id}.example.com/v2/Groups"
o The service provider may recognize a {tenant_id} provided by the
client in an HTTP Header as the indicator of the desired target
Tenant.
6.2. SCIM Identifiers with Multiple Tenants
Considerations for a Multi-Tenant Implementation:
The service provider may choose to implement SCIM ids which are
unique across all resources for all Tenants, but this is not
required.
The externalId, defined by the client, is required to be unique ONLY
within the resources associated with the associated Tenant.
7. Security Considerations
7.1. HTTP Considerations
SCIM Protocol layers on top of Hypertext Transfer Protocol and thus
subject to the security considerations of HTTP Section 9 [RFC7230]
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.
Hunt, et al. Expires November 12, 2015 [Page 75]
Internet-Draft draft-ietf-scim-api May 2015
7.2. TLS Support Considerations
SCIM resources (e.g., Users and Groups) can contain sensitive
information including passwords. Therefore, SCIM clients and service
providers MUST require the use of a transport-layer security
mechanism when communicating with SCIM service providers. The SCIM
service provider MUST support TLS 1.2 [RFC5246] and MAY support
additional transport-layer mechanisms meeting its security
requirements. When using TLS, the client MUST perform a TLS/SSL
server certificate check, per [RFC6125]. Implementation security
considerations for TLS can be found in "Recommendations for Secure
Use of TLS and DTLS" [RFC7525].
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
Hunt, et al. Expires November 12, 2015 [Page 76]
Internet-Draft draft-ietf-scim-api May 2015
[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
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
Section 3.4.3 ).
Servers that receive HTTP GET requests using filters that contain
sensitive or confidential personal information SHOULD respond with
HTTP status 403 indicating the operation is FORBIDDEN. A "scimType"
error of "sensitive" may be returned indicating the request must be
submitted using POST. A non-normative example:
Hunt, et al. Expires November 12, 2015 [Page 77]
Internet-Draft draft-ietf-scim-api May 2015
HTTP/1.1 403 FORBIDDEN
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"detail":
"Query filter involving 'name' is restricted or confidential",
"scimType": "sensitive",
"status": "404"
}
7.6. Anonymous Requests
If a SCIM service provider accepts anonymous requests such as SCIM
resource creation requests (via HTTP POST), appropriate security
measures should be put in place to prevent or limit exposure to
attacks. The following counter-measures MAY be used:
o Try to authenticate web UI components that formulate the SCIM
creation request. While the end-user MAY be anonymous, the web
user interface component often has its own way to authenticate to
the SCIM service provider (e.g., has an OAuth client credential
[RFC6749]) and the web user interface component may implement its
own measures (e.g., such as CAPTCHA) to ensure a legitimate
request is being made.
o Limit the number of requests any particular client MAY make in a
period of time.
o For User resources, default newly created resource with an
"active" setting of "false" and use a secondary confirmation
process (e.g., email confirmation) to ensure the resource created
is real.
7.7. Secure Storage and Handling of Sensitive Data
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 [RFC6819]. These
recommendations include but are not limited to:
Hunt, et al. Expires November 12, 2015 [Page 78]
Internet-Draft draft-ietf-scim-api May 2015
o Provide injection attack counter measures (e.g., by validating all
inputs and parameters),
o No cleartext storage of credentials,
o Store credentials using an encrypted protection mechanism, and
o Avoid passwords and consider use of asymmetric cryptography based
credentials.
As outlined in Section 5.1.4.2 [RFC6819], administrators SHOULD take
counter measures to prevent online attacks on secrets such as:
o Utilize secure password policy in order to increase user password
entropy to hinder online attacks and password guessing,
o Mitigate attacks on passwords by locking respective accounts have
a number of failed attempts,
o 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, and
o Use authentication system that use CAPTCHA's and other factors for
authenticating users further reducing the possibility of automated
attacks.
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
for uniqueness of usernames and passwords, strings MUST be
appropriately prepared before comparison. See Section 5.
8. IANA Considerations
8.1. Media Type Registration
To: ietf-types@iana.org
Subject: Registration of media type application/scim+json
Hunt, et al. Expires November 12, 2015 [Page 79]
Internet-Draft draft-ietf-scim-api May 2015
Type name: application
Subtype name: scim+json
Required parameters: none
Optional parameters: none
Encoding considerations: 8bit
Security considerations: See Section 7
Interoperability considerations: 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".
Published specification: [[this document]]
Applications that use this media type: 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.
Additional information:
Magic number(s):
File extension(s): .scim .scm
Macintosh file type code(s):
Person & email address to contact for further information: SCIM
mailing list "<scim@ietf.org>"
Intended usage: COMMON* (see restrictions)
Restrictions on usage: 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.
Hunt, et al. Expires November 12, 2015 [Page 80]
Internet-Draft draft-ietf-scim-api May 2015
Author: Phil Hunt
Change controller: IETF
8.2. SCIM Message URI Registry
As per the IANA SCIM Schema Registry in [I-D.ietf-scim-core-schema],
the following registers and extends the SCIM Schema Registry to
define SCIM protocol request/response JSON schema URN identifier
prefix of "urn:ietf:params:scim:api:messages:2.0" which is part of
the URN sub-Namespace for SCIM. There is no specific associated
resource type.
+---------------------------------+-----------------+---------------+
| Schema URI | Name | Reference |
+---------------------------------+-----------------+---------------+
| urn:ietf:params:scim:api: | List/Query | See Section |
| messages:2.0:ListResponse | Response | 3.4.2 |
| urn:ietf:params:scim:api: | POST Query | See Section |
| messages:2.0:SearchRequest | Request | 3.4.3 |
| urn:ietf:params:scim:api: | Patch Operation | See Section |
| messages:2.0:PatchOp | | 3.5.2 |
| urn:ietf:params:scim:api: | Bulk Operations | See Section |
| messages:2.0:BulkRequest | Request | 3.7 |
| urn:ietf:params:scim:api: | Bulk Operations | See Section |
| messages:2.0:BulkResponse | Response | 3.7 |
| urn:ietf:params:scim:api: | Error Response | See Section |
| messages:2.0:Error | | 3.12 |
+---------------------------------+-----------------+---------------+
Table 9: SCIM Schema URIs for Data Resources
9. References
9.1. Normative References
[I-D.ietf-precis-saslprepbis]
Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", draft-ietf-precis-
saslprepbis-16 (work in progress), April 2015.
[I-D.ietf-scim-core-schema]
Hunt, P., Grizzle, K., Wahlstroem, E., and C. Mortimore,
"System for Cross-Domain Identity Management: Core
Schema", draft-ietf-scim-core-schema-18 (work in
progress), April 2015.
Hunt, et al. Expires November 12, 2015 [Page 81]
Internet-Draft draft-ietf-scim-api May 2015
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", RFC
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
Interchange Format", RFC 7159, March 2014.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June
2014.
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(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
Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233,
June 2014.
[RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", RFC 7235, June 2014.
[RFC7538] Reschke, J., "The Hypertext Transfer Protocol Status Code
308 (Permanent Redirect)", RFC 7538, April 2015.
Hunt, et al. Expires November 12, 2015 [Page 82]
Internet-Draft draft-ietf-scim-api May 2015
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]
Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
Preparation, Enforcement, and Comparison of
Internationalized Strings in Application Protocols",
draft-ietf-precis-framework-23 (work in progress),
February 2015.
[OpenSearch]
Clinton, D., "OpenSearch Protocol 1.1, Draft 5", Dec 2005.
[Order-Operations]
Wikipedia, "Order of Operations: Programming Languages",
Apr 2015.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
6749, October 2012.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750, October 2012.
[RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0
Threat Model and Security Considerations", RFC 6819,
January 2013.
[RFC6902] Bryan, P. and M. Nottingham, "JavaScript Object Notation
(JSON) Patch", RFC 6902, April 2013.
Hunt, et al. Expires November 12, 2015 [Page 83]
Internet-Draft draft-ietf-scim-api May 2015
[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]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", October 2004.
Appendix A. Contributors
Samuel Erdtman (samuel@erdtman.se)
Patrick Harding (pharding@pingidentity.com)
Appendix B. Acknowledgments
The editors would like to acknowledge the contribution and work of
the past draft editors:
Trey Drake, UnboundID
Chuck Mortimore, Salesforce
The editor would like to thank the participants in the the SCIM
working group for their support of this specification.
Appendix C. Change Log
[[This section to be removed prior to publication as an RFC]]
Draft 02 - KG - Addition of schema extensibility
Draft 03 - PH - Revisions based on following tickets:
24 - Add filter negation
39 - Clarification on response for DELETE
42 - Make root searches optional
49 - Add "ew" filter
50 - Filters for multi-valued complex attributes
Hunt, et al. Expires November 12, 2015 [Page 84]
Internet-Draft draft-ietf-scim-api May 2015
51 - Search by Schema
53 - Standard use of term client (some was consumer)
55 - Redirect support (3xx)
56 - Make manager attribute consistent with other $ref attrs
57 - Update all "/v1" examples to '/v2"
59 - Fix capitalization per IETF editor practices
60 - Changed <eref> tags to normal <xref> and <reference> tags
Draft 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 RFC7159
Draft 05 - PH - Revisions based on the following tickets:
03 - Support for excludedAttributes parameter
13 - Change client use of Etags from MUST to MAY (correction)
23 - Clarifications regarding case exact processing.
41 - Add IANA considerations
65 - Removed X-HTTP-Method-Override support
69 - Added clarifications to intro to align with draft-nottingham-
uri-get-off-my-lawn
70 - Remove SCIM_TENANT_ID header
72 - Added text to indicate UTF-8 is default and mandatory
encoding format per BCP18
74 - Added security considerations for using GET with confidential
attribute filters
- corrected error response in JSON PATCH operation
Hunt, et al. Expires November 12, 2015 [Page 85]
Internet-Draft draft-ietf-scim-api May 2015
Draft 06 - PH - Revisions based on the following tickets and
editorial changes
41 - Revised content types from application/json to application/
scim+json, registered API schemas
63 - Revised uri schema prefixes for API json message schemas
66 - Updated references for RFC2616 to HTTPbis
75 - Added security considerations for International Strings and
"PRECIS" support
76 - 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=0
Draft 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
Hunt, et al. Expires November 12, 2015 [Page 86]
Internet-Draft draft-ietf-scim-api May 2015
Draft 09 - PH - Revisions as follows
- Aligned API with new URN namespace per RFC3553 and IETF90
meeting
- Clarified URN usage within patch (what schema urn applies)
- Made 'path' optional in PATCH for Add and Replace
Draft 10 - PH - Revisions as follows
Restructuring of Bulk into sub-sections
General clarifications
Improved Base URI section
Authorization section clarifications
Draft 11 - PH - Revisions as follows
Made mutability processing rules for CREATE more editorially
obvious
Added clarfications and security considerations for Anonymous
operations
Added clarifications to "/Me" for POST requests
Clarified use of bulkids with multiple requests
Corrected JSON parsing issue by adding "Operations" attribute to
PATCH operation
Draft 12 - PH - Editorial NITs
Fix line lengths in artwork to be 72 chars or less
Remove unused references
Fix normative terms per RFC2119
Updated reference to draft-reschke-http-status-308 to RFC7238
Draft 13 - PH - Added clarification to error response for improperly
formated email/phonenumbers
Draft 14 - PH - Nits and clarifications
Hunt, et al. Expires November 12, 2015 [Page 87]
Internet-Draft draft-ietf-scim-api May 2015
Added new Service Provider Discovery section that clarifies use of
ResourceTypes, Schemas, and ServiceProviderConfigs
As Complex attributes cannot support sub-attributes that are
complex, the filter ABNF was corrected to prevent nested
valueFilters (which presumes support for nested Complex
Attributes)
Corrections to ABNF: Added missing space (SP) values to logicExp
ABNF rule. Corrected "not(" to make "not" optional.
Added additional filter example showing full path with schema URI
(to disambiguate duplicate names between schemas)
Missing POST verb added to HTTP errors (table 7) since a POST
endpoint might be undefined or NOT FOUND.
Corrected JSON example in sec 3.3.2.1 (removed extraneous " )
Corrected filter in Figure 3 so that multiple resoruce types can
be returned per the response example in figure 4.
Clarifications and improvements to examples in PATCH replace
operations
Updated references to saslprep and precis frameworks
Draft 15 - PH - Clarifications on returning "path" handling during
PATCH "replace" operations. Updated references.
Draft 16 - PH - Clarification of SCIM protocol definitions of
resources vs messages and general process rules regarding schema
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)
Hunt, et al. Expires November 12, 2015 [Page 88]
Internet-Draft draft-ietf-scim-api May 2015
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
Phil Hunt (editor)
Oracle Corporation
Email: phil.hunt@yahoo.com
Kelly Grizzle
SailPoint
Email: kelly.grizzle@sailpoint.com
Morteza Ansari
Cisco
Email: morteza.ansari@cisco.com
Erik Wahlstroem
Email: erik.wahlstrom@nexusgroup.com
Chuck Mortimore
Salesforce.com
Email: cmortimore@salesforce.com
Hunt, et al. Expires November 12, 2015 [Page 89]