draft-ietf-scim-api-13.txt   draft-ietf-scim-api-14.txt 
Network Working Group P. Hunt, Ed. Network Working Group P. Hunt, Ed.
Internet-Draft Oracle Internet-Draft Oracle
Intended status: Standards Track K. Grizzle Intended status: Standards Track K. Grizzle
Expires: May 21, 2015 SailPoint Expires: June 20, 2015 SailPoint
M. Ansari M. Ansari
Cisco Cisco
E. Wahlstroem E. Wahlstroem
Nexus Technology Nexus Technology
C. Mortimore C. Mortimore
Salesforce Salesforce
November 17, 2014 December 17, 2014
System for Cross-Domain Identity Management: Protocol System for Cross-Domain Identity Management: Protocol
draft-ietf-scim-api-13 draft-ietf-scim-api-14
Abstract Abstract
The System for Cross-Domain Identity Management (SCIM) specification The System for Cross-Domain Identity Management (SCIM) specification
is an HTTP based protocol that makes managing identities in multi- is an HTTP based protocol that makes managing identities in multi-
domain scenarios easier to support through a standardized services. domain scenarios easier to support through a standardized services.
Examples include but are not limited to enterprise to cloud service Examples include but are not limited to enterprise to cloud service
providers, and inter-cloud based scenarios. The specification suite providers, and inter-cloud based scenarios. The specification suite
seeks to build upon experience with existing schemas and deployments, seeks to build upon experience with existing schemas and deployments,
placing specific emphasis on simplicity of development and placing specific emphasis on simplicity of development and
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 21, 2015. This Internet-Draft will expire on June 20, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3
1.1. Intended Audience . . . . . . . . . . . . . . . . . . . . 3 1.1. Intended Audience . . . . . . . . . . . . . . . . . . . . 3
1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3
1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Authentication and Authorization . . . . . . . . . . . . . . 4 2. Authentication and Authorization . . . . . . . . . . . . . . 4
3. SCIM Protocol . . . . . . . . . . . . . . . . . . . . . . . . 5 3. SCIM Protocol . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Creating Resources . . . . . . . . . . . . . . . . . . . 6 3.1. Creating Resources . . . . . . . . . . . . . . . . . . . 6
3.1.1. Resource Types . . . . . . . . . . . . . . . . . . . 8 3.1.1. Resource Types . . . . . . . . . . . . . . . . . . . 9
3.2. Retrieving Resources . . . . . . . . . . . . . . . . . . 8 3.2. Retrieving Resources . . . . . . . . . . . . . . . . . . 9
3.2.1. Retrieving a known Resource . . . . . . . . . . . . . 9 3.2.1. Retrieving a known Resource . . . . . . . . . . . . . 9
3.2.2. Query Resources . . . . . . . . . . . . . . . . . . . 10 3.2.2. Query Resources . . . . . . . . . . . . . . . . . . . 10
3.2.3. Querying Resources Using HTTP POST . . . . . . . . . 21 3.2.3. Querying Resources Using HTTP POST . . . . . . . . . 21
3.3. Modifying Resources . . . . . . . . . . . . . . . . . . . 24 3.3. Modifying Resources . . . . . . . . . . . . . . . . . . . 24
3.3.1. Replacing with PUT . . . . . . . . . . . . . . . . . 25 3.3.1. Replacing with PUT . . . . . . . . . . . . . . . . . 25
3.3.2. Modifying with PATCH . . . . . . . . . . . . . . . . 27 3.3.2. Modifying with PATCH . . . . . . . . . . . . . . . . 27
3.4. Deleting Resources . . . . . . . . . . . . . . . . . . . 40 3.4. Deleting Resources . . . . . . . . . . . . . . . . . . . 41
3.5. Bulk Operations . . . . . . . . . . . . . . . . . . . . . 41 3.5. Bulk Operations . . . . . . . . . . . . . . . . . . . . . 42
3.5.1. Circular Reference Processing . . . . . . . . . . . . 43 3.5.1. Circular Reference Processing . . . . . . . . . . . . 44
3.5.2. BulkdId Temporary Identifiers . . . . . . . . . . . . 46 3.5.2. BulkdId Temporary Identifiers . . . . . . . . . . . . 47
3.5.3. Response and Error Handling . . . . . . . . . . . . . 50 3.5.3. Response and Error Handling . . . . . . . . . . . . . 51
3.5.4. Maximum Operations . . . . . . . . . . . . . . . . . 56 3.5.4. Maximum Operations . . . . . . . . . . . . . . . . . 57
3.6. Data Input/Output Formats . . . . . . . . . . . . . . . . 57 3.6. Data Input/Output Formats . . . . . . . . . . . . . . . . 58
3.7. Additional Operation Response Parameters . . . . . . . . 58 3.7. Additional Operation Response Parameters . . . . . . . . 59
3.8. Attribute Notation . . . . . . . . . . . . . . . . . . . 59 3.8. Attribute Notation . . . . . . . . . . . . . . . . . . . 60
3.9. "/Me" Authenticated Subject Alias . . . . . . . . . . . . 59 3.9. "/Me" Authenticated Subject Alias . . . . . . . . . . . . 60
3.10. HTTP Status and Error Response Handling . . . . . . . . . 60 3.10. HTTP Status and Error Response Handling . . . . . . . . . 61
3.11. API Versioning . . . . . . . . . . . . . . . . . . . . . 64 3.11. API Versioning . . . . . . . . . . . . . . . . . . . . . 65
3.12. Versioning Resources . . . . . . . . . . . . . . . . . . 64 3.12. Versioning Resources . . . . . . . . . . . . . . . . . . 65
4. Preparation and Comparison of Internationalized Strings . . . 66 4. Service Provider Configuration Endpoints . . . . . . . . . . 67
5. Multi-Tenancy . . . . . . . . . . . . . . . . . . . . . . . . 66 5. Preparation and Comparison of Internationalized Strings . . . 69
5.1. Associating Clients to Tenants . . . . . . . . . . . . . 67 6. Multi-Tenancy . . . . . . . . . . . . . . . . . . . . . . . . 70
5.2. SCIM Identifiers with Multiple Tenants . . . . . . . . . 68 6.1. Associating Clients to Tenants . . . . . . . . . . . . . 70
6. Security Considerations . . . . . . . . . . . . . . . . . . . 68 6.2. SCIM Identifiers with Multiple Tenants . . . . . . . . . 71
6.1. TLS Support . . . . . . . . . . . . . . . . . . . . . . . 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 71
6.2. Disclosure of Sensitive Information in URIs . . . . . . . 68 7.1. TLS Support . . . . . . . . . . . . . . . . . . . . . . . 71
6.3. Anonymous Requests . . . . . . . . . . . . . . . . . . . 69 7.2. Disclosure of Sensitive Information in URIs . . . . . . . 72
6.4. HTTP Considerations . . . . . . . . . . . . . . . . . . . 69 7.3. Anonymous Requests . . . . . . . . . . . . . . . . . . . 72
6.5. Secure Storage and Handling of Sensitive Data . . . . . . 70 7.4. HTTP Considerations . . . . . . . . . . . . . . . . . . . 73
6.6. Case Insensitive Comparision & International Languages . 71 7.5. Secure Storage and Handling of Sensitive Data . . . . . . 73
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 7.6. Case Insensitive Comparision & International Languages . 74
7.1. Media Type Registration . . . . . . . . . . . . . . . . . 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74
7.2. SCIM Message URI Registry . . . . . . . . . . . . . . . . 72 8.1. Media Type Registration . . . . . . . . . . . . . . . . . 74
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 73 8.2. SCIM Message URI Registry . . . . . . . . . . . . . . . . 75
8.1. Normative References . . . . . . . . . . . . . . . . . . 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 76
8.2. Informative References . . . . . . . . . . . . . . . . . 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 76
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 74 9.2. Informative References . . . . . . . . . . . . . . . . . 77
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 74 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 78
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 75 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 78
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 78
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82
1. Introduction and Overview 1. Introduction and Overview
The SCIM Protocol is an application-level, HTTP protocol for The SCIM Protocol is an application-level, HTTP protocol for
provisioning and managing identity data on the web and in cross- provisioning and managing identity data on the web and in cross-
domain environments such as enterprise to cloud, or inter-cloud domain environments such as enterprise to cloud, or inter-cloud
scenarios. The protocol supports creation, modification, retrieval, scenarios. The protocol supports creation, modification, retrieval,
and discovery of core identity resources such as Users and Groups, as and discovery of core identity resources such as Users and Groups, as
well as custom resources and resource extensions. well as custom resources and resource extensions.
skipping to change at page 6, line 17 skipping to change at page 6, line 17
User /Users GET (Section 3.2.1), Retrieve, Add, User /Users GET (Section 3.2.1), Retrieve, Add,
POST (Section 3.1), Modify Users POST (Section 3.1), Modify Users
PUT (Section 3.3.1), PUT (Section 3.3.1),
PATCH (Section 3.3.2), PATCH (Section 3.3.2),
DELETE (Section 3.4) DELETE (Section 3.4)
Group /Groups GET (Section 3.2.1), Retrieve, Add, Group /Groups GET (Section 3.2.1), Retrieve, Add,
POST (Section 3.1), Modify Groups POST (Section 3.1), Modify Groups
PUT (Section 3.3.1), PUT (Section 3.3.1),
PATCH (Section 3.3.2), PATCH (Section 3.3.2),
DELETE (Section 3.4) DELETE (Section 3.4)
Service /ServiceProvider GET (Section 3.2.1) Retrieve service Self /Me GET, POST, PUT, PATCH, Alias for operations
Provider Configs provider's DELETE (Section 3.9) against a resource
mapped to an
authenticated
Subject (e.g. User).
Service /ServiceProvider GET (Section 4) Retrieve service
Provider Config provider's
Config configuration Config configuration
Resource /ResourceTypes GET (Section 3.2.1) Retrieve supported Resource /ResourceTypes GET (Section 4) Retrieve supported
Type resource types Type resource types
Schema /Schemas GET (Section 3.2.1) Retrieve one or more Schema /Schemas GET (Section 4) Retrieve one or more
supported schemas. supported schemas.
Bulk /Bulk POST (Section 3.5) Bulk updates to one Bulk /Bulk POST (Section 3.5) Bulk updates to one
or more resources or more resources
Search [prefix]/.search POST (Section 3.2.3) Search from system Search [prefix]/.search POST (Section 3.2.3) Search from system
root or within a root or within a
resource endpoint resource endpoint
for one or more for one or more
resource types using resource types using
POST. POST.
skipping to change at page 16, line 10 skipping to change at page 16, line 10
| | | MAY be used. See examples below. | | | | MAY be used. See examples below. |
+----------+-------------+------------------------------------------+ +----------+-------------+------------------------------------------+
Table 4: Grouping Operators Table 4: Grouping Operators
SCIM filters MUST conform to the following ABNF rules as per SCIM filters MUST conform to the following ABNF rules as per
[RFC5234] below: [RFC5234] below:
FILTER = attrExp / logExp / valuePath / *1"not" "(" FILTER ")" FILTER = attrExp / logExp / valuePath / *1"not" "(" FILTER ")"
valuePath = attrPath "[" FILTER "]" valuePath = attrPath "[" valFilter "]"
; FILTER uses sub-attribs of a parent attrPath ; FILTER uses sub-attribs of a parent attrPath
ATTRNAME = ALPHA *(nameChar) valFilter = attrExp / logExp / *1"not" "(" valFilter ")"
nameChar = "-" / "_" / DIGIT / ALPHA
attrPath = [URI ":"] ATTRNAME *1subAttr
; SCIM attribute name
; URI is SCIM "schema" URI
subAttr = "." ATTRNAME
; a sub-attribute of a complex attribute
attrExp = (attrPath SP "pr") / attrExp = (attrPath SP "pr") /
(attrPath SP compareOp SP compValue) (attrPath SP compareOp SP compValue)
logExp = FILTER SP ("and" / "or") SP FILTER
compValue = false / null / true / number / string compValue = false / null / true / number / string
; rules from JSON (RFC7159) ; rules from JSON (RFC7159)
compareOp = "eq" / "ne" / "co" / compareOp = "eq" / "ne" / "co" /
"sw" / "ew" / "sw" / "ew" /
"gt" / "lt" / "gt" / "lt" /
"ge" / "le" "ge" / "le"
logExp = FILTER ("and" / "or") FILTER attrPath = [URI ":"] ATTRNAME *1subAttr
; SCIM attribute name
; URI is SCIM "schema" URI
ATTRNAME = ALPHA *(nameChar)
nameChar = "-" / "_" / DIGIT / ALPHA
subAttr = "." ATTRNAME
; a sub-attribute of a complex attribute
Figure 1: ABNF Specification of SCIM Filters Figure 1: ABNF Specification of SCIM Filters
In the above ABNF, the "compValue" (comparison value) rule is built In the above ABNF, the "compValue" (comparison value) rule is built
on JSON Data Interchange format ABNF rules as specified in [RFC7159], on JSON Data Interchange format ABNF rules as specified in [RFC7159],
"DIGIT" and "ALPHA" are defined per Appendix B.1 of [RFC5234] and, "DIGIT" and "ALPHA" are defined per Appendix B.1 of [RFC5234] and,
"URI" is defined per Appendix A of [RFC3986]. "URI" is defined per Appendix A of [RFC3986].
Filters MUST be evaluated using standard order of operations Filters MUST be evaluated using standard order of operations
[Order-Operations]. Attribute operators have the highest precedence, [Order-Operations]. Attribute operators have the highest precedence,
skipping to change at page 18, line 15 skipping to change at page 18, line 15
The following are examples of valid filters. Some attributes (e.g. The following are examples of valid filters. Some attributes (e.g.
rooms and rooms.number) are hypothetical extensions and are not part rooms and rooms.number) are hypothetical extensions and are not part
of SCIM core schema: of SCIM core schema:
filter=userName eq "bjensen" filter=userName eq "bjensen"
filter=name.familyName co "O'Malley" filter=name.familyName co "O'Malley"
filter=userName sw "J" filter=userName sw "J"
filter=urn:ietf:params:scim:schemas:core:2.0:User:userName sw "J"
filter=title pr filter=title pr
filter=meta.lastModified gt "2011-05-13T04:42:34Z" filter=meta.lastModified gt "2011-05-13T04:42:34Z"
filter=meta.lastModified ge "2011-05-13T04:42:34Z" filter=meta.lastModified ge "2011-05-13T04:42:34Z"
filter=meta.lastModified lt "2011-05-13T04:42:34Z" filter=meta.lastModified lt "2011-05-13T04:42:34Z"
filter=meta.lastModified le "2011-05-13T04:42:34Z" filter=meta.lastModified le "2011-05-13T04:42:34Z"
skipping to change at page 18, line 46 skipping to change at page 18, line 48
emails co "example.org") emails co "example.org")
filter=userType eq "Employee" and (emails.type eq "work") filter=userType eq "Employee" and (emails.type eq "work")
filter=userType eq "Employee" and emails[type eq "work" and filter=userType eq "Employee" and emails[type eq "work" and
value co "@example.com"] value co "@example.com"]
filter=emails[type eq "work" and value co "@example.com"] or filter=emails[type eq "work" and value co "@example.com"] or
ims[type eq "xmpp" and value co "@foo.com"] ims[type eq "xmpp" and value co "@foo.com"]
filter=addresses[state eq "CA" and rooms[type eq "bedroom" and
number gt 2]]
Figure 2: Example Filters Figure 2: Example Filters
3.2.2.3. Sorting 3.2.2.3. Sorting
Sort is OPTIONAL. Sorting allows clients to specify the order in Sort is OPTIONAL. Sorting allows clients to specify the order in
which resources are returned by specifying a combination of sortBy which resources are returned by specifying a combination of sortBy
and sortOrder URL parameters. and sortOrder URL parameters.
sortBy: The sortBy parameter specifies the attribute whose value sortBy: The sortBy parameter specifies the attribute whose value
SHALL be used to order the returned responses. If the sortBy SHALL be used to order the returned responses. If the sortBy
skipping to change at page 21, line 18 skipping to change at page 21, line 18
{ {
"totalResults":100, "totalResults":100,
"itemsPerPage":10, "itemsPerPage":10,
"startIndex":1, "startIndex":1,
"schemas":["urn:ietf:params:scim:api:messages:2.0:ListResponse"], "schemas":["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
"Resources":[{ "Resources":[{
... ...
}] }]
} }
Figure 3: ListResponse format for returning multiple resources
Given the example above, to continue paging set the startIndex to 11 Given the example above, to continue paging set the startIndex to 11
and re-fetch; i.e., /Users?startIndex=11&count=10 and re-fetch; i.e., /Users?startIndex=11&count=10
3.2.2.5. Attributes 3.2.2.5. Attributes
The following attributes control which attributes SHALL be returned The following attributes control which attributes SHALL be returned
with a returned resource. SCIM clients MAY use up to one of these with a returned resource. SCIM clients MAY use up to one of these
two OPTIONAL parameters which MUST be supported by SCIM service two OPTIONAL parameters which MUST be supported by SCIM service
providers: providers:
skipping to change at page 23, line 19 skipping to change at page 23, line 19
Host: example.com Host: example.com
Accept: application/scim+json Accept: application/scim+json
Content-Type: application/scim+json Content-Type: application/scim+json
Authorization: Bearer h480djs93hd8 Authorization: Bearer h480djs93hd8
Content-Length: ... Content-Length: ...
{ {
"schemas": ["urn:ietf:params:scim:api:messages:2.0:SearchRequest"], "schemas": ["urn:ietf:params:scim:api:messages:2.0:SearchRequest"],
"attributes": ["displayName", "userName"], "attributes": ["displayName", "userName"],
"filter": "filter":
"(displayName sw \"smith\") and (meta.resourceType eq \"User\")", "displayName sw \"smith\"",
"startIndex": 1, "startIndex": 1,
"count": 10 "count": 10
} }
Figure 3: Example POST Query Request Figure 4: Example POST Query Request
A query response is shown with the first page of results. For A query response is shown with the first page of results. For
brevity reasons, only two matches are shown: one User and one Group. brevity reasons, only two matches are shown: one User and one Group.
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/scim+json Content-Type: application/scim+json
Location: https://example.com/.search Location: https://example.com/.search
{ {
"schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"], "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
"totalResults":100, "totalResults":100,
skipping to change at page 24, line 40 skipping to change at page 24, line 40
"https://example.com/Groups/c8596b90-7539-4f20968d1908", "https://example.com/Groups/c8596b90-7539-4f20968d1908",
"resourceType":"Group", "resourceType":"Group",
"lastModified": ... "lastModified": ...
}, },
"displayName":"Smith Family" "displayName":"Smith Family"
}, },
... ...
] ]
} }
Figure 4: Example POST Query Response Figure 5: Example POST Query Response
3.3. Modifying Resources 3.3. Modifying Resources
Resources can be modified in whole or in part via PUT or PATCH, Resources can be modified in whole or in part via PUT or PATCH,
respectively. Implementers MUST support PUT as specified in respectively. Implementers MUST support PUT as specified in
Section 4.3 [RFC7231]. Resources such as Groups may be very large Section 4.3 [RFC7231]. Resources such as Groups may be very large
hence implementers SHOULD support HTTP PATCH [RFC5789] to enable hence implementers SHOULD support HTTP PATCH [RFC5789] to enable
partial resource modifications. partial resource modifications.
3.3.1. Replacing with PUT 3.3.1. Replacing with PUT
skipping to change at page 28, line 36 skipping to change at page 28, line 36
"display": "Babs Jensen", "display": "Babs Jensen",
"$ref": "https://example.com/v2/Users/2819c223...413861904646", "$ref": "https://example.com/v2/Users/2819c223...413861904646",
"value": "2819c223-7f76-453a-919d-413861904646" "value": "2819c223-7f76-453a-919d-413861904646"
} }
] ]
}, },
... + additional operations if needed ... ... + additional operations if needed ...
] ]
} }
Figure 5: Example JSON body for SCIM PATCH Request Figure 6: Example JSON body for SCIM PATCH Request
A "path" attribute value is a String containing an attribute path A "path" attribute value is a String containing an attribute path
describing the target of the operation. The "path" attribute is describing the target of the operation. The "path" attribute is
OPTIONAL for "add" and "replace" and is REQUIRED for "remove" OPTIONAL for "add" and "replace" and is REQUIRED for "remove"
operations. See relevant operation sections below for details. operations. See relevant operation sections below for details.
The "path" attribute is described by the following ABNF syntax rule: The "path" attribute is described by the following ABNF syntax rule:
PATH = attrPath / valuePath [subAttr] PATH = attrPath / valuePath [subAttr]
Figure 6: SCIM Patch PATH Rule Figure 7: SCIM Patch PATH Rule
The ABNF rules, "attrPath", "valuePath", and "subAttr" are defined in The ABNF rules, "attrPath", "valuePath", and "subAttr" are defined in
Section 3.2.2.2. The "valuePath" rule allows specific values of a Section 3.2.2.2. The "valuePath" rule allows specific values of a
complex, multi-valued attribute to be selected. complex, multi-valued attribute to be selected.
Valid examples of "path" values are as follows: Valid examples of "path" values are as follows:
"path":"members" "path":"members"
"path":"name.familyName" "path":"name.familyName"
"path":"addresses[type eq \"work\"]" "path":"addresses[type eq \"work\"]"
"path":"members[value eq "path":"members[value eq
\"2819c223-7f76-453a-919d-413861904646\"]" \"2819c223-7f76-453a-919d-413861904646\"]"
"path":"members[value eq "path":"members[value eq
\"2819c223-7f76-453a-919d-413861904646\"].displayName" \"2819c223-7f76-453a-919d-413861904646\"].displayName"
Figure 7: Example Path Values Figure 8: Example Path Values
Each operation against an attribute MUST be compatible with the Each operation against an attribute MUST be compatible with the
attribute's mutability and schema as defined in the Attribute Types attribute's mutability and schema as defined in the Attribute Types
Section of [I-D.ietf-scim-core-schema]. For example, a client MUST Section of [I-D.ietf-scim-core-schema]. For example, a client MUST
NOT modify an attribute that has mutability "readOnly" or NOT modify an attribute that has mutability "readOnly" or
"immutable". However, a client MAY "add" a value to an "immutable" "immutable". However, a client MAY "add" a value to an "immutable"
attribute if the attribute had no previous value. An operation that attribute if the attribute had no previous value. An operation that
is not compatibile with an attribute's mutability or schema SHALL is not compatibile with an attribute's mutability or schema SHALL
return the appropriate HTTP response status code and a JSON detail return the appropriate HTTP response status code and a JSON detail
error response as defined in Section 3.10. error response as defined in Section 3.10.
skipping to change at page 32, line 25 skipping to change at page 32, line 25
Host: example.com Host: example.com
Accept: application/scim+json Accept: application/scim+json
Content-Type: application/scim+json Content-Type: application/scim+json
Authorization: Bearer h480djs93hd8 Authorization: Bearer h480djs93hd8
If-Match: W/"a330bc54f0671c9" If-Match: W/"a330bc54f0671c9"
{ {
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations":[{ "Operations":[{
"op":"add", "op":"add",
"value":"{ "value":{
"emails":[ "emails":[
{ {
"value":"babs@jensen.org", "value":"babs@jensen.org",
"type":"home" "type":"home"
} }
], ],
"nickname":"Babs" "nickname":"Babs"
}] }]
} }
skipping to change at page 39, line 5 skipping to change at page 39, line 5
}, },
{ {
"display": "James Smith", "display": "James Smith",
"$ref": "https://example.com/v2/Users/08e1d05d...473d93df9210", "$ref": "https://example.com/v2/Users/08e1d05d...473d93df9210",
"value": "08e1d05d...473d93df9210" "value": "08e1d05d...473d93df9210"
} }
] ]
}] }]
} }
The following example shows how to change a User's entire "work" The following example shows how to change a User's entire "work"
address. address using a "valuePath" filter. Note that by setting "primary"
to "true", the service provider will reset primary to "false" for any
other existing values of "addresses".
PATCH /Users/2819c223-7f76-453a-919d-413861904646 PATCH /Users/2819c223-7f76-453a-919d-413861904646
Host: example.com Host: example.com
Accept: application/scim+json Accept: application/scim+json
Content-Type: application/scim+json Content-Type: application/scim+json
Authorization: Bearer h480djs93hd8 Authorization: Bearer h480djs93hd8
If-Match: W/"a330bc54f0671c9" If-Match: W/"a330bc54f0671c9"
{ {
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
skipping to change at page 39, line 32 skipping to change at page 40, line 4
"streetAddress": "911 Universal City Plaza", "streetAddress": "911 Universal City Plaza",
"locality": "Hollywood", "locality": "Hollywood",
"region": "CA", "region": "CA",
"postalCode": "91608", "postalCode": "91608",
"country": "US", "country": "US",
"formatted": "911 Universal City Plaza\nHollywood, CA 91608 US", "formatted": "911 Universal City Plaza\nHollywood, CA 91608 US",
"primary": true "primary": true
} }
}] }]
} }
The following example shows how to change a specific sub-attribute
The following example shows how to change a User's "work" email "streetAddress" of complex attribute "emails" selected by "valuePath"
address: filter:
PATCH /Users/2819c223-7f76-453a-919d-413861904646 PATCH /Users/2819c223-7f76-453a-919d-413861904646
Host: example.com Host: example.com
Accept: application/scim+json Accept: application/scim+json
Content-Type: application/scim+json Content-Type: application/scim+json
Authorization: Bearer h480djs93hd8 Authorization: Bearer h480djs93hd8
If-Match: W/"a330bc54f0671c9" If-Match: W/"a330bc54f0671c9"
{ {
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [{ "Operations": [{
"op":"replace", "op":"replace",
"path":"emails[type eq \"work\"].value", "path":"addresses[type eq \"work\"].streetAddress",
"value":"bjenson@example.com" "value":"1010 Broadway Ave"
}] }]
} }
The following example shows how to replace one or more attributes of The following example shows how to replace all values of one or more
a User resource. specific attributes of a User resource. Note that other attributes
are unaffected.
PATCH /Users/2819c223-7f76-453a-919d-413861904646 PATCH /Users/2819c223-7f76-453a-919d-413861904646
Host: example.com Host: example.com
Accept: application/scim+json Accept: application/scim+json
Content-Type: application/scim+json Content-Type: application/scim+json
Authorization: Bearer h480djs93hd8 Authorization: Bearer h480djs93hd8
If-Match: W/"a330bc54f0671c9" If-Match: W/"a330bc54f0671c9"
{ {
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
skipping to change at page 60, line 22 skipping to change at page 61, line 22
o A service provider MAY process the SCIM request directly. In any o A service provider MAY process the SCIM request directly. In any
response, the HTTP "Location" header MUST be the permanent response, the HTTP "Location" header MUST be the permanent
location of the aliased resource associated with the authenticated location of the aliased resource associated with the authenticated
subject. subject.
When using the SCIM Create Resource command (HTTP POST) with the When using the SCIM Create Resource command (HTTP POST) with the
"/Me" alias, the desired resourceType being created is at the "/Me" alias, the desired resourceType being created is at the
discretion of the service provider based on the authenticated subject discretion of the service provider based on the authenticated subject
(if not anonymous) making the request and any request body attributes (if not anonymous) making the request and any request body attributes
(e.g. "schemas"). See Section 6.3 for information on security (e.g. "schemas"). See Section 7.3 for information on security
considerations related to this operation. considerations related to this operation.
3.10. HTTP Status and Error Response Handling 3.10. HTTP Status and Error Response Handling
The SCIM Protocol uses the HTTP status response status codes defined The SCIM Protocol uses the HTTP status response status codes defined
in Section 6 [RFC7231] to indicate operation success or failure. In in Section 6 [RFC7231] to indicate operation success or failure. In
addition to returning a HTTP response code implementers MUST return addition to returning a HTTP response code implementers MUST return
the errors in the body of the response in the client requested format the errors in the body of the response in the client requested format
containing the error response and, per the HTTP specification, human- containing the error response and, per the HTTP specification, human-
readable explanations. Error responses are identified using the readable explanations. Error responses are identified using the
skipping to change at page 61, line 28 skipping to change at page 62, line 28
| | | [RFC7238]. | | | | [RFC7238]. |
| 400 BAD | GET, POST, | Request is unparseable, | | 400 BAD | GET, POST, | Request is unparseable, |
| REQUEST | PUT, PATCH, | syntactically incorrect, or | | REQUEST | PUT, PATCH, | syntactically incorrect, or |
| | DELETE | violates schema | | | DELETE | violates schema |
| 401 | GET, POST, | Authorization failure | | 401 | GET, POST, | Authorization failure |
| UNAUTHORIZED | PUT, PATCH, | | | UNAUTHORIZED | PUT, PATCH, | |
| | DELETE | | | | DELETE | |
| 403 | GET, POST, | Server does not support requested | | 403 | GET, POST, | Server does not support requested |
| FORBIDDEN | PUT, PATCH, | operation | | FORBIDDEN | PUT, PATCH, | operation |
| | DELETE | | | | DELETE | |
| 404 NOT | GET, PUT, | Specified resource (e.g., User) or | | 404 NOT | GET, POST, | Specified resource (e.g., User) or |
| FOUND | PATCH, DELETE | end-point, does not exist | | FOUND | PUT, PATCH, | end-point, does not exist |
| | DELETE | |
| 409 CONFLICT | POST, PUT, | The specified version number does | | 409 CONFLICT | POST, PUT, | The specified version number does |
| | PATCH, DELETE | not match the resource's latest | | | PATCH, DELETE | not match the resource's latest |
| | | version number or a service | | | | version number or a service |
| | | provider refused to create a new, | | | | provider refused to create a new, |
| | | duplicate resource | | | | duplicate resource |
| 412 | PUT, PATCH,D | Failed to update as resource {id} | | 412 | PUT, PATCH,D | Failed to update as resource {id} |
| PRECONDITION | ELETE | changed on the server last | | PRECONDITION | ELETE | changed on the server last |
| FAILED | | retrieved | | FAILED | | retrieved |
| 413 REQUEST | POST | {"maxOperations": | | 413 REQUEST | POST | {"maxOperations": |
| ENTITY TOO | | 1000,"maxPayload": 1048576} | | ENTITY TOO | | 1000,"maxPayload": 1048576} |
skipping to change at page 62, line 48 skipping to change at page 63, line 48
| | attribute with an existing | | | | attribute with an existing | |
| | value). | | | | value). | |
| invalidSynta | The request body message | POST (Search - | | invalidSynta | The request body message | POST (Search - |
| x | structure was invalid or did | Section 3.2.2, | | x | structure was invalid or did | Section 3.2.2, |
| | not conform to the request | Create - Section | | | not conform to the request | Create - Section |
| | schema. | 3.1, Bulk - Section | | | schema. | 3.1, Bulk - Section |
| | | 3.5), PUT (Section | | | | 3.5), PUT (Section |
| | | 3.3.1) | | | | 3.3.1) |
| invalidPath | The path attribute was | PATCH (Section | | invalidPath | The path attribute was | PATCH (Section |
| | invalid or malformed (see | 3.3.2) | | | invalid or malformed (see | 3.3.2) |
| | Figure 6). | | | | Figure 7). | |
| noTarget | The specified "path" did not | PATCH (Section | | noTarget | The specified "path" did not | PATCH (Section |
| | yield an attribute or | 3.3.2) | | | yield an attribute or | 3.3.2) |
| | attribute value that could | | | | attribute value that could | |
| | be operated on. This occurs | | | | be operated on. This occurs | |
| | when the specified "path" | | | | when the specified "path" | |
| | value contains a filter that | | | | value contains a filter that | |
| | yields no match. | | | | yields no match. | |
| invalidValue | A required value was | GET (Section | | invalidValue | A required value was | GET (Section |
| | missing, or the value | 3.2.2), POST | | | missing, or the value | 3.2.2), POST |
| | specified was not compatible | (Create - Section | | | specified was not compatible | (Create - Section |
skipping to change at page 66, line 23 skipping to change at page 67, line 23
If the resource has not changed the service provider simply returns If the resource has not changed the service provider simply returns
an empty body with a 304 "Not Modified" response code. an empty body with a 304 "Not Modified" response code.
If the service providers supports versioning of resources the client If the service providers supports versioning of resources the client
MAY supply an If-Match Section 3.1 [RFC7233] header for PUT and PATCH MAY supply an If-Match Section 3.1 [RFC7233] header for PUT and PATCH
operations to ensure that the requested operation succeeds only if operations to ensure that the requested operation succeeds only if
the supplied ETag matches the latest service provider resource; e.g., the supplied ETag matches the latest service provider resource; e.g.,
If-Match: W/"e180ee84f0671b1" If-Match: W/"e180ee84f0671b1"
4. Preparation and Comparison of Internationalized Strings 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].
/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.2.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.
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 unicode To increase the likelihood that the input and comparison of unicode
usernames and passwords will work in ways that make sense for typical usernames and passwords will work in ways that make sense for typical
users throughout the world there are special string preparation and users throughout the world there are special string preparation and
comparison methods (PRECIS) that MUST be followed for usernames and comparison methods (PRECIS) that MUST be followed for usernames and
passwords. Before comparing or evaluating uniqueness of a "userName" passwords. Before comparing or evaluating uniqueness of a "userName"
or "password" attribute, service providers MUST use the "PRECIS" or "password" attribute, service providers MUST use the "PRECIS"
profile described in Sections 4 and 5 respectively of profile described in Sections 4 and 5 respectively of
[I-D.ietf-precis-saslprepbis] and is based on the "PRECIS" framework [I-D.ietf-precis-saslprepbis] and is based on the "PRECIS" framework
specification [I-D.ietf-precis-framework]. specification [I-D.ietf-precis-framework].
5. Multi-Tenancy 6. Multi-Tenancy
A single service provider may expose the SCIM protocol to multiple A single service provider may expose the SCIM protocol to multiple
clients. Depending on the nature of the service, the clients may clients. Depending on the nature of the service, the clients may
have authority to access and alter resources initially created by have authority to access and alter resources initially created by
other clients. Alternatively, clients may expect to access disjoint other clients. Alternatively, clients may expect to access disjoint
sets of resources, and may expect that their resources are sets of resources, and may expect that their resources are
inaccessible by other clients. These scenarios are called "multi- inaccessible by other clients. These scenarios are called "multi-
tenancy", where each client is understood to be or represent a tenancy", where each client is understood to be or represent a
"tenant" of the service provider. Clients may also be multi- "tenant" of the service provider. Clients may also be multi-
tenanted. tenanted.
skipping to change at page 67, line 26 skipping to change at page 70, line 47
The SCIM protocol does not prescribe the mechanisms whereby clients The SCIM protocol does not prescribe the mechanisms whereby clients
and service providers interact for: and service providers interact for:
o Registering or provisioning Tenants o Registering or provisioning Tenants
o Associating a subset of clients with a subset of the 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 o Indicating which tenant is associated with the data in a request
or response, or indicating which Tenant is the subject of a query or response, or indicating which Tenant is the subject of a query
5.1. Associating Clients to Tenants 6.1. Associating Clients to Tenants
The service provider MAY use the authentication mechanism (Section 2) The service provider MAY use the authentication mechanism (Section 2)
to determine the identity of the client, and thus infer the to determine the identity of the client, and thus infer the
associated Tenant. associated Tenant.
For implementations where a client is associated with more than one For implementations where a client is associated with more than one
Tenant, the service provider MAY use one of the following methods for Tenant, the service provider MAY use one of the following methods for
explicit specification of the Tenant. explicit specification of the Tenant.
If any of these methods of allowing the client to explicitly specify If any of these methods of allowing the client to explicitly specify
skipping to change at page 68, line 4 skipping to change at page 71, line 25
client may explicitly specify a Tenant while being implicitly client may explicitly specify a Tenant while being implicitly
associated with a different Tenant. associated with a different Tenant.
In all of these methods, the {tenant_id} is a unique identifier for In all of these methods, the {tenant_id} is a unique identifier for
the Tenant as defined by the service provider. the Tenant as defined by the service provider.
o A URL prefix: "https://www.example.com/Tenants/{tenant_id}/v2/ o A URL prefix: "https://www.example.com/Tenants/{tenant_id}/v2/
Users" Users"
o A sub-domain: "https://{tenant_id}.example.com/v2/Groups" o A sub-domain: "https://{tenant_id}.example.com/v2/Groups"
o The service provider may recognize a {tenant_id} provided by the o The service provider may recognize a {tenant_id} provided by the
client in an HTTP Header as the indicator of the desired target client in an HTTP Header as the indicator of the desired target
Tenant. Tenant.
5.2. SCIM Identifiers with Multiple Tenants 6.2. SCIM Identifiers with Multiple Tenants
Considerations for a Multi-Tenant Implementation: Considerations for a Multi-Tenant Implementation:
The service provider may choose to implement SCIM ids which are The service provider may choose to implement SCIM ids which are
unique across all resources for all Tenants, but this is not unique across all resources for all Tenants, but this is not
required. required.
The externalId, defined by the client, is required to be unique ONLY The externalId, defined by the client, is required to be unique ONLY
within the resources associated with the associated Tenant. within the resources associated with the associated Tenant.
6. Security Considerations 7. Security Considerations
6.1. TLS Support 7.1. TLS Support
The SCIM Protocol layers on top of Hypertext Transfer Protocol and The SCIM Protocol layers on top of Hypertext Transfer Protocol and
thus subject to the security considerations of HTTP Section 9 thus subject to the security considerations of HTTP Section 9
[RFC7230] and its related specifications. [RFC7230] and its related specifications.
SCIM resources (e.g., Users and Groups) can contain sensitive SCIM resources (e.g., Users and Groups) can contain sensitive
information. Therefore, SCIM clients and service providers MUST information. Therefore, SCIM clients and service providers MUST
implement TLS. Which version(s) ought to be implemented will vary implement TLS. Which version(s) ought to be implemented will vary
over time, and depend on the widespread deployment and known security over time, and depend on the widespread deployment and known security
vulnerabilities at the time of implementation. At the time of this vulnerabilities at the time of implementation. At the time of this
writing, TLS version 1.2 [RFC5246] is the most recent version, but writing, TLS version 1.2 [RFC5246] is the most recent version, but
has very limited actual deployment, and might not be readily has very limited actual deployment, and might not be readily
available in implementation toolkits. TLS version 1.0 [RFC5246] is available in implementation toolkits. TLS version 1.0 [RFC5246] is
the most widely deployed version, and will give the broadest the most widely deployed version, and will give the broadest
interoperability. interoperability.
6.2. Disclosure of Sensitive Information in URIs 7.2. Disclosure of Sensitive Information in URIs
As mentioned in ,Section 9.4 [RFC7231], SCIM clients requesting As mentioned in ,Section 9.4 [RFC7231], SCIM clients requesting
information using query filters using HTTP GET SHOULD give information using query filters using HTTP GET SHOULD give
consideration to the information content of the filters and whether consideration to the information content of the filters and whether
their exposure in a URI would represent a breach of security or their exposure in a URI would represent a breach of security or
confidentiality through leakage in a web browsers or server logs. confidentiality through leakage in a web browsers or server logs.
This is particularly true for information that is legally considered This is particularly true for information that is legally considered
"personally identifiable information" or is otherwise restricted by "personally identifiable information" or is otherwise restricted by
privacy laws. In these situations to ensure maximum security and privacy laws. In these situations to ensure maximum security and
confidentiality, clients SHOULD query using HTTP POST (see confidentiality, clients SHOULD query using HTTP POST (see
skipping to change at page 69, line 24 skipping to change at page 72, line 43
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"], "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"Errors":[ "Errors":[
{ {
"description": "description":
"Query filter involving 'name' is restricted or confidential", "Query filter involving 'name' is restricted or confidential",
"error":"confidential_restricted" "error":"confidential_restricted"
} }
] ]
} }
6.3. Anonymous Requests 7.3. Anonymous Requests
If a SCIM service provider accepts anonymous requests such as SCIM If a SCIM service provider accepts anonymous requests such as SCIM
resource creation requests (via HTTP POST), appropriate security resource creation requests (via HTTP POST), appropriate security
measures should be put in place to prevent or limit exposure to measures should be put in place to prevent or limit exposure to
attacks. The following counter-measures MAY be used: attacks. The following counter-measures MAY be used:
o Try to authenticate web UI components that forumulate the SCIM o Try to authenticate web UI components that forumulate the SCIM
creation request. While the end-user MAY be anonymous, the web creation request. While the end-user MAY be anonymous, the web
user interface component often has its own way to authenticate to user interface component often has its own way to authenticate to
the SCIM service provider (e.g. has an OAuth Client Credential the SCIM service provider (e.g. has an OAuth Client Credential
skipping to change at page 69, line 47 skipping to change at page 73, line 21
is being made. is being made.
o Limit the number of requests any particular client MAY make in a o Limit the number of requests any particular client MAY make in a
period of time. period of time.
o For User resources, default newly created resource with an o For User resources, default newly created resource with an
"active" setting of "false" and use a secondary confirmation "active" setting of "false" and use a secondary confirmation
process (e.g. email confirmation) to ensure the resource created process (e.g. email confirmation) to ensure the resource created
is real. is real.
6.4. HTTP Considerations 7.4. HTTP Considerations
As an HTTP based protocol, implementers of SCIM SHOULD consider all As an HTTP based protocol, implementers of SCIM SHOULD consider all
security considerations of the HTTP/1.1 as enumerated in Section 1 security considerations of the HTTP/1.1 as enumerated in Section 1
[RFC7230] [RFC7230]
As stated in Section 2.7.1 [RFC7230], a SCIM client MUST NOT generate As stated in Section 2.7.1 [RFC7230], a SCIM client MUST NOT generate
the userinfo (i.e. username and password) component (and its "@" the userinfo (i.e. username and password) component (and its "@"
delimiter) when an "http" URI reference is generated with a message delimiter) when an "http" URI reference is generated with a message
as they are now disallowed in HTTP. as they are now disallowed in HTTP.
6.5. Secure Storage and Handling of Sensitive Data 7.5. Secure Storage and Handling of Sensitive Data
An attacker may obtain valid username/password combinations from the An attacker may obtain valid username/password combinations from the
SCIM service provider's underlying database by gaining access to the SCIM service provider's underlying database by gaining access to the
database and/or launching injection attacks. This could lead to database and/or launching injection attacks. This could lead to
unintended disclosure of username/password combinations. The impact unintended disclosure of username/password combinations. The impact
may extend beyond the domain of the SCIM service provider if the data may extend beyond the domain of the SCIM service provider if the data
was provisioned from other domains. was provisioned from other domains.
Administrators should undertake industry best practices to protect Administrators should undertake industry best practices to protect
the storage of credentials and in particular SHOULD follow the storage of credentials and in particular SHOULD follow
skipping to change at page 71, line 5 skipping to change at page 74, line 24
a number of failed attempts, a number of failed attempts,
o Use "tar pit" techniques by temporarily locking a respective o Use "tar pit" techniques by temporarily locking a respective
account and delaying responses for a certain duration. The account and delaying responses for a certain duration. The
duration may increase with the number of failed attempts, and duration may increase with the number of failed attempts, and
o Use authentication system that use CAPTCHA's and other factors for o Use authentication system that use CAPTCHA's and other factors for
authenticating users further reducing the possibility of automated authenticating users further reducing the possibility of automated
attacks. attacks.
6.6. Case Insensitive Comparision & International Languages 7.6. Case Insensitive Comparision & International Languages
When comparing unicode strings such as in query filters or testing When comparing unicode strings such as in query filters or testing
for uniqueness of usernames and passwords, strings MUST be for uniqueness of usernames and passwords, strings MUST be
appopriately prepared before comparison. See Section 4. appopriately prepared before comparison. See Section 5.
7. IANA Considerations 8. IANA Considerations
7.1. Media Type Registration 8.1. Media Type Registration
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of media type application/scim+json Subject: Registration of media type application/scim+json
Type name: application Type name: application
Subtype name: scim+json Subtype name: scim+json
Required parameters: none Required parameters: none
Optional parameters: none Optional parameters: none
Encoding considerations: 8bit Encoding considerations: 8bit
Security considerations: See Section 6 Security considerations: See Section 7
Interoperability considerations: The "application/scim+json" media Interoperability considerations: The "application/scim+json" media
type is intended to identify JSON structure data that conforms to type is intended to identify JSON structure data that conforms to
the SCIM protocol and schema specifications. Older versions of the SCIM protocol and schema specifications. Older versions of
SCIM are known to informally use "application/json". SCIM are known to informally use "application/json".
Published specification: [[this document]] Published specification: [[this document]]
Applications that use this media type: It is expected that Applications that use this media type: It is expected that
applications that use this type may be special purpose applications that use this type may be special purpose
skipping to change at page 72, line 23 skipping to change at page 75, line 42
Restrictions on usage: For most client types, it is sufficient to Restrictions on usage: For most client types, it is sufficient to
recognize the content as equivalent to "application/json". recognize the content as equivalent to "application/json".
Applications intending to use SCIM protocol SHOULD use the Applications intending to use SCIM protocol SHOULD use the
application/scim+json media type. application/scim+json media type.
Author: Phil Hunt Author: Phil Hunt
Change controller: IETF Change controller: IETF
7.2. SCIM Message URI Registry 8.2. SCIM Message URI Registry
As per the IANA SCIM Schema Registry in [I-D.ietf-scim-core-schema], As per the IANA SCIM Schema Registry in [I-D.ietf-scim-core-schema],
the following registers and extends the SCIM Schema Registry to the following registers and extends the SCIM Schema Registry to
define SCIM protocol request/response JSON schema URN identifier define SCIM protocol request/response JSON schema URN identifier
prefix of "urn:ietf:params:scim:api:messages:2.0" which is part of 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 the URN sub-Namespace for SCIM. There is no specific associated
resource type. resource type.
+---------------------------------+-----------------+---------------+ +---------------------------------+-----------------+---------------+
| Schema URI | Name | Reference | | Schema URI | Name | Reference |
skipping to change at page 73, line 5 skipping to change at page 76, line 24
| urn:ietf:params:scim:api: | Bulk Operations | See Section | | urn:ietf:params:scim:api: | Bulk Operations | See Section |
| messages:2.0:BulkRequest | Request | 3.5 | | messages:2.0:BulkRequest | Request | 3.5 |
| urn:ietf:params:scim:api: | Bulk Operations | See Section | | urn:ietf:params:scim:api: | Bulk Operations | See Section |
| messages:2.0:BulkResponse | Response | 3.5 | | messages:2.0:BulkResponse | Response | 3.5 |
| urn:ietf:params:scim:api: | Error Response | See Section | | urn:ietf:params:scim:api: | Error Response | See Section |
| messages:2.0:Error | | 3.10 | | messages:2.0:Error | | 3.10 |
+---------------------------------+-----------------+---------------+ +---------------------------------+-----------------+---------------+
Table 9: SCIM Schema URIs for Data Resources Table 9: SCIM Schema URIs for Data Resources
8. References 9. References
8.1. Normative References 9.1. Normative References
[I-D.ietf-precis-saslprepbis] [I-D.ietf-precis-saslprepbis]
Saint-Andre, P. and A. Melnikov, "Preparation, Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", draft-ietf-precis- Representing Usernames and Passwords", draft-ietf-precis-
saslprepbis-09 (work in progress), October 2014. saslprepbis-12 (work in progress), December 2014.
[I-D.ietf-scim-core-schema] [I-D.ietf-scim-core-schema]
Hunt, P., Grizzle, K., Wahlstroem, E., and C. Mortimore, Hunt, P., Grizzle, K., Wahlstroem, E., and C. Mortimore,
"System for Cross-Domain Identity Management: Core "System for Cross-Domain Identity Management: Core
Schema", draft-ietf-scim-core-schema-13 (work in Schema", draft-ietf-scim-core-schema-14 (work in
progress), November 2014. progress), December 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005. 3986, January 2005.
skipping to change at page 74, line 8 skipping to change at page 77, line 28
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231, June 2014. (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
[RFC7233] Fielding, R., Lafon, Y., and J. Reschke, "Hypertext [RFC7233] Fielding, R., Lafon, Y., and J. Reschke, "Hypertext
Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233,
June 2014. June 2014.
[RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", RFC 7235, June 2014. (HTTP/1.1): Authentication", RFC 7235, June 2014.
8.2. Informative References 9.2. Informative References
[I-D.ietf-precis-framework] [I-D.ietf-precis-framework]
Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
Preparation, Enforcement, and Comparison of Preparation, Enforcement, and Comparison of
Internationalized Strings in Application Protocols", Internationalized Strings in Application Protocols",
draft-ietf-precis-framework-19 (work in progress), October draft-ietf-precis-framework-21 (work in progress),
2014. December 2014.
[OpenSearch] [OpenSearch]
Clinton, D., "OpenSearch Protocol 1.1, Draft 5", . Clinton, D., "OpenSearch Protocol 1.1, Draft 5", .
[Order-Operations] [Order-Operations]
Wikipedia, "Order of Operations: Programming Languages", . Wikipedia, "Order of Operations: Programming Languages", .
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
6749, October 2012. 6749, October 2012.
skipping to change at page 78, line 22 skipping to change at page 81, line 44
Remove unused references Remove unused references
Fix normative terms per RFC2119 Fix normative terms per RFC2119
Updated reference to draft-reschke-http-status-308 to RFC7238 Updated reference to draft-reschke-http-status-308 to RFC7238
Draft 13 - PH - Added clarification to error response for improperly Draft 13 - PH - Added clarification to error response for improperly
formated email/phonenumbers formated email/phonenumbers
Draft 14 - PH - Nits and clarifications
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
Authors' Addresses Authors' Addresses
Phil Hunt (editor) Phil Hunt (editor)
Oracle Corporation Oracle Corporation
Email: phil.hunt@yahoo.com Email: phil.hunt@yahoo.com
Kelly Grizzle Kelly Grizzle
SailPoint SailPoint
 End of changes. 55 change blocks. 
102 lines changed or deleted 239 lines changed or added

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