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/