SCIM conference call 4 September 2013

Issue #2 Add pagination capability to plural Resource attributes User Group retrieval could be resource intensive, hence support attribute level pagination

Issue #9 Add ability to mark attributes as unique in the schemas Add ability to mark attributes as unique in ServiceProviderConfig (or unique in Schema?)

Issue #10 Add ability to mark attributes as sensitive in the schemas Add ability to mark attributes as sensitive in ServiceProviderConfig (or sensitive in Schema?) Use this for password

Issue #13 Add a "required" flag in configuration to support etags

Issue #24 Add the negation operator to the Filtering section I'm reading the Filtering section in the API specification and I have some questions because I miss some filter operators. I noticed the priority is not on the filtering now and the specifications states "Providers MAY support additional filter operations if they choose." so It's all fine but what I miss is the way to negate.

Issue #34 Resource Schema Representation should be non-normative The JSON schema representation in "11.6. Resource Schema Representation" doesn't appear to be "normative" as indicated, since it merely provides an example Schema resource for a User. This should be labeled as a "non-normative" example.

Issue #35 Canonical types for Group members should not be READ-ONLY See the thread here: ​ Basically, the canonical types for Group members should be marked as "immutable" instead of read-only since they can be specified when inserting new elements.

Issue #37 Define error response when a server is unwilling to perform a list/query Section of the API document defines how to use a GET operation to list or query resources. In some cases, servers may be unwilling to perform these operations if the results are too large to return. For example, if the client does not specify a startIndex and count the server may be asked to return millions of resources. This could cause server and network performance problems. Recommendation to: 1.Allow servers to respond to list/query requests with an "unwilling to perform" error (maybe a 403 Forbidden status code) 2.Allow servers to publish list/query restrictions in the /ServiceProviderConfig resource. These might be similar to the maxOperations/maxPayloadSize bulk configuration options

Issue #39 Clarification on response body for DELETE Should the resource be returned as part of the response body for a DELETE? Section "3.4 Deleting Resources" only mentions the return codes, but not what should be in the response body.

Issue #42 Consider making server root searches optional In issue #25, the ability to search against the server root was added: Queries MAY be performed against a SCIM: Resource (e.g. /Users/{userid}), Resource Type endpoint (e.g. /Users or /Groups), or Server Root (e.g. /). However, for some service providers it may be difficult to perform a server root query that performs well at scale. See the discussion on the mailing list here:

Issue #46 Clarify error responses and allow non-HTTP error codes The API draft states that requests that result in an error "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." We need to clearly define the format of the error response. Here are a few questions that I have been asked regarding the current error response: 1.Why is this an array of complex objects? How would multiple errors be used? 2.Does the code sub-attribute have to be the HTTP error code? 3.If a service provider wants to transmit a more detailed error code, how would it do this? Does this have to fit into the formatted description or can another sub-attribute be added to the error reponse? We need to answer these questions and tighten up the spec to be more clear.