SCIM 1.0 > 1.1 change log

[Trey Drake]

Quick 1.0 > 1.1 API and schema change log 

API Changes

Clarification on resource creation (POST)

  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 a 409 error and

   SHOULD indicate the conflicting attribute(s) in the body of the

   response.

Password clarification on PUT

 PUT performs a full update.  Consumers must retrieve the entire

   Resource and PUT the desired modifications as the operation

   overwrites all previously stored data with the exception of the

   password attribute.  If the password attribute of the User resource

   is unspecified, it should be left in-tact.  Since this performs a

   full update, Consumers MAY send read-only attributes of the retrieved

   resource and Service Provider MUST ignore any read-only attributes

   that are present in the payload of a PUT request.  Unless otherwise

   specified a successful PUT operation returns a 200 OK response code

   and the entire Resource within the response body, enabling the

   Consumer to correlate the Consumer's and Provider's views of the

   updated Resource. 

Clarifications on delete:

3.4.  Deleting Resources

   Consumers 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 MUST 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.

Correction of E-tag usage in examples

i.e., If-Match: W/"a330bc54f0671c9"

Error handling correction for oversized requests

  The Service Provider MUST define the maximum number of operations and

   maximum payload size a Consumer 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 Consumer sent a request exceeding the

   Service Provider's max payload size of 1 megabyte.

   POST /v1/Bulk

   Host: example.com

   Accept: application/json

   Content-Type: application/json

   Authorization: Bearer h480djs93hd8

   Content-Length: 4294967296

   ...

HTTP/1.1 413 Request Entity Too Large

Content-Type: application/json

Location: https://example.com/v1/Bulk/yfCrVJhFIJagAHj8

{

  "Errors":[

    {

      "description":"The size of the bulk operation exceeds the maxPayloadSize (1048576).",

      "code":"413"

    }

  ]

}

E-tag usage clarification (versioning)

  If the Service Providers supports versioning of resources the

   Consumer MUST supply an If-Match 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"

Schema Changes

Multi-valued clarifications

.2.  Multi-valued Attributes

   Multi-valued attributes are unordered lists of attributes.  Each

   attribute MAY contain Sub-Attributes and therefore multi-valued

   attributes may contain Complex Attributes.  The below Sub-Attributes

   are considered normative and when specified SHOULD be used as defined.

External ID clarification

Uniqueness is no longer mandatory

userName clarification

Stability no longer required; i.e., it can change

phoneNumbers syntax

 phoneNumbers  Phone numbers for the User.  The value SHOULD be

      canonicalized by the Service Provider according to format in

      RFC3966 [7] e.g. 'tel:+1-201-555-0123'.  Canonical Type values of

      work, home, mobile, fax, pager and other.

Group display name

now required

The Group members attribute is no longer required

 Service Providers MAY require Consumers to provide a non-empty

      members value based on the "required" sub attribute of the

      "members" attribute in Group Resource Schema.

authenticationSchemes

Should be made publicly accessible; i.e., retrieval should not require consumer authorization