From leifj@mnt.se Sun Jul 8 07:37:34 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C7821F8567; Sun, 8 Jul 2012 07:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.139 X-Spam-Level: X-Spam-Status: No, score=-3.139 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALPTpTShK1hG; Sun, 8 Jul 2012 07:37:33 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 666A021F8562; Sun, 8 Jul 2012 07:37:33 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q68EbmSQ003431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Jul 2012 16:37:52 +0200 (CEST) Message-ID: <4FF99B3C.1060807@mnt.se> Date: Sun, 08 Jul 2012 16:37:48 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: scim WG , "abf >> \"abfab@ietf.org\"" References: In-Reply-To: X-Enigmail-Version: 1.4.2 X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [scim] Fwd: Fwd: NomCom 2012-13 Call for Volunteers X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 14:37:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -------- Original Message -------- Subject: Fwd: NomCom 2012-13 Call for Volunteers Date: Sat, 7 Jul 2012 14:44:36 -0400 From: Barry Leiba To: app-chairs@tools.ietf.org Please consider posting this to your working group mailing lists. The NomCom process is extremely important to the IETF, and willing volunteers are necessary for the success of the NomCom. Thanks, Barry - ---------- Forwarded message ---------- From: *NomCom Chair* Date: Friday, July 6, 2012 Subject: NomCom 2012-13 Call for Volunteers To: IETF Announcement List > The IETF nominating committee process for 2012-13 has begun. The IETF nominating committee appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. The 10 nominating committee members are selected randomly from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. The details of the operation of the nomcom can be found in RFC 3777. To be eligible, volunteers for the nomcom need to have attended 3 of the past 5 IETF meetings as of the time this announcement goes out. That is, 3 meetings from IETF 79 (Beijing) - IETF 83 (Paris). If you qualify, and if you will not be seeking appointment to any of the open positions that this nomcom will be filling, please consider volunteering. The list of people whose terms end with the March 2013 IETF meeting, and thus the positions for which the nominating committee is responsible for filling, are as follows: IAOC: - -------- Dave Crocker IAB: - -------- Alissa Cooper Joel Halpern David Kessens Danny McPherson Jon Peterson Dave Thaler IESG: - -------- Russ Housley (General Area) Pete Resnick (Applications Area) Ralph Droms (Internet Area) Ronald Bonica (Operations and Management Area) Robert Sparks (Real-Time Applications and Infrastructure Area) Adrian Farrel (Routing Area) Stephen Farrell (Security Area) Wesley Eddy (Transport Area) The primary activity for this nomcom will begin in August 2012 and should be completed in January 2013. The nomcom will be collecting requirements from the community, as well as talking to candidates and obtaining feedback from community members about candidates. There will be regularly scheduled conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. Please volunteer by sending an email before 11:59 pm EDT (UTC - 4 hours) August 5, 2012 as follows: To: mlepinski.ietf@gmail.com Subject: Nomcom 2012-13 Volunteer Please include the following information in the body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // typically what goes in the Company field // in the IETF Registration Form [] // // For confirmation if selected Please expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive a response, please re-send your email with the tag "RESEND:" added to the subject line. If you are not yet sure you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing toward that goal. I will be publishing a more detailed timetable for nomcom activities, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you, Matthew Lepinski mlepinski.ietf@gmail.com nomcom-chair@ietf.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/5mzcACgkQ8Jx8FtbMZnd8mACffOPeYkH9A3qAvDdDNao7jTHn tpIAn2pxB68GShW0DMuGKaRaj8/I2kCb =+Mg9 -----END PGP SIGNATURE----- From leifj@mnt.se Thu Jul 12 05:40:06 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F42321F8829 for ; Thu, 12 Jul 2012 05:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqGntj-JWQK7 for ; Thu, 12 Jul 2012 05:40:05 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 44EE021F8650 for ; Thu, 12 Jul 2012 05:40:05 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q6CCeXNn011221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Jul 2012 14:40:37 +0200 (CEST) Message-ID: <4FFEC5C1.8060609@mnt.se> Date: Thu, 12 Jul 2012 14:40:33 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: scim WG X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [scim] draft agenda for Vancouver X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 12:40:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here is a draft agenda for Vancouver. Please help us fill this in by suggesting things we missed or volunteering to present. - - Agenda bashing and IETF Note Well - - Chairs Introduction to the WG - - SCIM 1.1 overview and document status (volunteers welcome!) - - Technical discussion and open Mic We have 2 hours on Friday morning so make sure not to leave early! For those who are new to the IETF I suggest reading the Tao of the IETF: http://www.ietf.org/tao.html Note that on this our first WG meeting we will try to devote a little bit of time to level-set and introduction but during future meetings we will focus increasingly on resolving technical issues so if you are curious about SCIM this is the time to get involved! Morteza and Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/+xcEACgkQ8Jx8FtbMZnfhwQCfW48IetBbBDb4FqZLsHI1D7vC XgYAoI+39hyFZhDHXV30aoSgIgdHy4Ql =+7V9 -----END PGP SIGNATURE----- From trey.drake@unboundid.com Thu Jul 12 11:54:28 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E79211E80CD for ; Thu, 12 Jul 2012 11:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeE++n4i1oU9 for ; Thu, 12 Jul 2012 11:54:27 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 265D421F85A7 for ; Thu, 12 Jul 2012 11:54:27 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3018445ghb.31 for ; Thu, 12 Jul 2012 11:55:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version :x-mailer:x-gm-message-state; bh=h1SvRC8GHPPUi+of5PapYBZB82irl9sbWOxjJKRqsas=; b=MWSHYWtk9TV32/6ZQjQYhjQP2/j+5MBpCZii/WaNjUF9PYuASqUSYq6vfRtyodlxFx DnMsY60MHJKsoTBaUr2vXQB3ZBnuRGOltcWuJwE15rqplmx3JhuNmF/3dB0YgpD0WJfs IHNVpH7WFN7E3YjrF25hDAcY4NATYhORUpVqslQwFahPvTRH04TwKGJTBL/xcyDrO9fM BdlzhgHNKuj/t45Y8wCgYSWx3YaOA1nG6Rys1yQO3bbCoceG3L0tn3LVX+ba7zEbaomp 8LpjuScVMIOS8L4VPDAKmtpiI3bk9jGBi9s37ES2FD0voB7v16P4x4pxIpVJO60E9B5u NqbA== Received: by 10.60.168.230 with SMTP id zz6mr56176068oeb.11.1342119300582; Thu, 12 Jul 2012 11:55:00 -0700 (PDT) Received: from office-dhcp-222.unboundid.lab (24-155-184-100.static.grandenetworks.net. [24.155.184.100]) by mx.google.com with ESMTPS id i2sm4616300obn.19.2012.07.12.11.54.58 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Jul 2012 11:54:59 -0700 (PDT) From: Trey Drake Content-Type: multipart/mixed; boundary="Apple-Mail=_19FFEAC6-A1D7-4DDC-818F-22E497C6FAE7" Date: Thu, 12 Jul 2012 13:54:57 -0500 Message-Id: <93E72F4B-CFE4-4F43-897C-FB7B0F8B2050@unboundid.com> To: internet-drafts@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQl+rJq7LEmtZAAXmxSnhaH5yP46yQBalrTC16JNQeqf2rxbjn2NNt2HzXq5j6JqiQgnAFli Cc: "scim@ietf.org Management" , "Morteza Ansari \(moransar\)" Subject: [scim] SCIM drafts X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 18:54:28 -0000 --Apple-Mail=_19FFEAC6-A1D7-4DDC-818F-22E497C6FAE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The attached contain the SCIM "1.1" protocol and schema drafts for = consideration by the SCIM working group. Thanks, Trey=20 --Apple-Mail=_19FFEAC6-A1D7-4DDC-818F-22E497C6FAE7 Content-Disposition: attachment; filename=draft-scim-core-schema-01.xml Content-Type: application/xml; name="draft-scim-core-schema-01.xml" Content-Transfer-Encoding: 7bit System for Cross-Domain Identity Management: Core Schema 1.1 Salesforce.com
cmortimore@salesforce.com
Ping Identity
pharding@pingidentity.com
Ping Identity
pmadsen@pingidentity.com
UnboundID
trey.drake@unboundid.com
The System for Cross-Domain Identity Management (SCIM) specification is designed to make managing user identity in cloud based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols. In essence, make it fast, cheap, and easy to move identity in to, out of, and around the cloud. This document provides a platform neutral schema and extension model for representing users and groups in JSON and XML formats. This schema is intended for exchange and use with cloud service providers. Additional binding documents provide a standard REST API, SAML binding, and use cases.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . Throughout this document, values are quoted to indicate that they are to be taken literally. When using these values in protocol messages, the quotes MUST NOT be used as part of the value.
While there are existing standards for describing and exchanging user information, many of these standards can be difficult to implement and/or use; e.g., their wire protocols do not easily traverse firewalls and/or are not easily layered onto existing web protocols. As a result, many cloud providers implement non-standard APIs for managing users within their services. This increases both the cost and complexity associated with organizations adopting products and services from multiple cloud providers as they must perform redundant integration development. Similarly, cloud services providers seeking to interoperate with multiple application marketplaces or cloud identity providers must be redundantly integrated. SCIM seeks to simplify this problem through a simple to implement specification suite that provides a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema via a REST API. It draws inspiration and best practice, building upon existing user APIs and schemas from a wide variety of sources including, but not limited to, existing APIs exposed by cloud providers, PortableContacts, and LDAP directory services. This document provides a platform neutral schema and extension model for representing users and groups in JSON and XML formats. This schema is intended for exchange and use with cloud service providers. Additional binding documents provide a standard REST API, SAML binding, and use cases.
A web application that provides identity information via the SCIM protocol. A website or application that uses the SCIM protocol to manage identity data maintained by the Service Provider. The Service Provider managed artifact containing one or more attributes; e.g., User or Group A Resource attribute that contains 0..1 values; e.g., displayName. A Resource attribute that contains 0..n values; e.g., emails. A Singular or Multi-valued Attribute whose value is a primitive; e.g., String. A Singular or Multi-valued Attribute whose value is a composition of one or more Simple Attributes. A Simple Attribute contained within a Complex Attribute.
SCIM schema provides a minimal core schema for representing users and groups (resources), encompassing common attributes found in many existing deployments and schemas. A resource is a collection of attributes identified by one or more schemas. Minimally, an attribute consists of the attribute name and at least one Simple or Complex value either of which may be Multi-valued. SCIM schema defines the data type, plurality and other distinguishing features of an attribute. Unless otherwise specified all attributes are modifiable by Consumers. Immutable (read-only) attributes SHALL be specified as 'READ-ONLY' within the attribute definition. Additionally, Service Providers MAY choose to make some or all Resource attributes immutable and SHOULD identify those attributes via the associated Resource's schema endpoint. Both XML and JSON formats are defined. Resource and attribute names MUST conform to XML naming rules;i.e., SCIM names MUST be valid XML names and SHOULD be camelCased. When marshalling or extending SCIM resources in XML implementors MUST use the normative, SCIM, XML schema (.xsd). SCIM resources represented in a schema-less format; e.g., JSON, MUST specify schema via the schemas attribute.
Attribute data types are derived from XML schema and unless otherwise specified are optional, modifiable by Consumers, and of type String. The JSON format defines a limited set of data types, hence, where appropriate, alternate JSON representations are defined below. SCIM extensions SHOULD not introduce new data types.
A sequence of characters as defined in section 3.2.1 of the XML Schema Datatypes Specification. A String attribute MAY specify a required data format. Additionally, when Canonical Values are specified Service Providers SHOULD conform to those values if appropriate, but MAY provide alternate String values to represent additional values.
The literal "true" or "false" as specified in section 3.2.2 of the XML Schema Datatypes Specification.
A real number with at least one digit to the left and right of the period as specified in section 3.2.3 of the XML Schema Datatypes Specification. Values represented in JSON MUST conform to the XML constraints above and are represented as a JSON Number.
A Decimal number with no fractional digits as defined in section 3.3.13 of the XML Schema Datatypes Specification. Values represented in JSON MUST conform to the XML constraints above and are represented as a JSON Number.
A dateTime (e.g. 2008-01-23T04:56:22Z) as specified in section 3.2.7 of the XML Schema Datatypes Specification. Values represented in JSON MUST conform to the XML constraints above and are represented as a JSON String.
The attribute value MUST be encoded as a valid xsd:base64Binary value as specified in section 3.2.16 of the XML Schema Datatypes Specification. Values represented in JSON MUST conform to the XML constraints above and are represented as a JSON String.
A Singular or Multi-valued Attribute whose value is a composition of one or more Simple Attributes as specified in section 3.4 XML Schema Datatypes Specification. JSON values are represented as JSON Objects.
Multi-valued attributes are unordered lists of attributes. Each attribute MAY contain Sub-Attributes and therefore multi-valued attributes may contain Complex Attributes. The below Sub-Attributes are considered normative and when specified SHOULD be used as defined. A label indicating the attribute's function; e.g., "work" or "home". A Boolean value indicating the 'primary' or preferred attribute value for this attribute, e.g. the preferred mailing address or primary e-mail address. The primary attribute value 'true' MUST appear no more than once. A human readable name, primarily used for display purposes. READ-ONLY. The operation to perform on the multi-valued attribute during a PATCH request. The only valid value is "delete", which signifies that this instance should be removed from the Resource. The attribute's significant value; e.g., the e-mail address, phone number, etc. Attributes that define a "value" sub-attribute MAY be alternately represented as a collection of primitive types. For example: May also be represented as: When returning multi-valued attributes, Service Providers SHOULD canonicalize the value returned, if appropriate (e.g. for e-mail addresses and URLs). Providers MAY return the same value more than once with different types (e.g. the same e-mail address may used for work and home), but SHOULD NOT return the same (type, value) combination more than once per Attribute, as this complicates processing by the Consumer.
SCIM schema follows an object extension model similar to ObjectClasses used in LDAP. Unlike LDAP there is no inheritance model; all extensions are additive (similar to LDAP Auxiliary Object Classes). Each value indicates additive schema that may exist in a SCIM representation as specified by extensions not defined in this suite. Schema extensions MUST NOT redefine any attributes defined in this specification and SHOULD follow conventions defined in this specification. Each schema extension must identify a URI used to identify the extension. XML MUST use XML namespaces and JSON formats MUST use the "schemas" attribute to distinguish extended resources and attributes.
Each SCIM Resource (Users, Groups, etc.) includes the below common attributes. These attributes MUST be included in all Resources, including any extended Resource types. It is not necessary to specify the schemas attribute if the Resource is fully defined in this document as the core schema is implicitly included. Unique identifier for the SCIM Resource as defined by the Service Provider. Each representation of the Resource MUST include a non-empty id value. This identifier MUST be unique across the Service Provider's entire set of Resources. It MUST be a stable, non-reassignable identifier that does not change when the same Resource is returned in subsequent requests. The value of the id attribute is always issued by the Service Provider and MUST never be specified by the Service Consumer. bulkId: is a reserved keyword and MUST NOT be used in the unique identifier. REQUIRED and READ-ONLY. An identifier for the Resource as defined by the Service Consumer. The externalId may simplify identification of the Resource between Service Consumer and Service provider by allowing the Consumer to refer to the Resource with its own identifier, obviating the need to store a local mapping between the local identifier of the Resource and the identifier used by the Service Provider. Each Resource MAY include a non-empty externalId value. The value of the externalId attribute is always issued be the Service Consumer and can never be specified by the Service Provider. The Service Provider MUST always interpret the externalId as scoped to the Service Consumer's tenant. A complex attribute containing resource metadata. All sub-attributes are OPTIONAL The DateTime the Resource was added to the Service Provider. The attribute MUST be a DateTime. READ-ONLY. The most recent DateTime the details of this Resource were updated at the Service Provider. If this Resource has never been modified since its initial creation, the value MUST be the same as the value of created. The attribute MUST be a DateTime. READ-ONLY. The URI of the Resource being returned. This value MUST be the same as the Location HTTP response header. READ-ONLY. The version of the Resource being returned. This value must be the same as the ETag HTTP response header. READ-ONLY. The names of the attributes to remove from the Resource during a PATCH operation.
SCIM supports resources of different types, with extensible schemas. Each resource MUST be indicated using fully qualified URLs. Where a specific representation has existing support for expressing schema, the traditional convention of that representation MUST be applied. For example, when representing users using XML, XML Namespace should be used. When a representation does not explicitly provide support for indicating a schema, such as JSON, a schemas attribute is used to indicate the version of SCIM schema as well as any schema extensions. The schemas attribute is an array of Strings which allows introspection of the supported schema version for a SCIM representation as well any schema extensions supported by that representation. Each String value must be a unique URI. This specification defines URIs for User, Group, and a standard "enterprise" extension. All representations of SCIM schema MUST include a non-zero value array with value(s) of the URIs supported by that representation. Duplicate values MUST NOT be included. Value order is not specified and MUST not impact behavior. REQUIRED.
SCIM provides a schema for representing Users, identified using the following URI: 'urn:scim:schemas:core:1.0'. The following attributes are defined in addition to those attributes defined in SCIM Core Schema:
Unique identifier for the User, typically used by the user to directly authenticate to the service provider. Often displayed to the user as their unique identifier within the system (as opposed to id or externalId, which are generally opaque and not user-friendly identifiers). Each User MUST include a non-empty userName value. This identifier MUST be unique across the Service Consumer's entire set of Users. REQUIRED. The components of the User's real name. Providers MAY return just the full name as a single string in the formatted sub-attribute, or they MAY return just the individual component attributes using the other sub-attributes, or they MAY return both. If both variants are returned, they SHOULD be describing the same name, with the formatted name indicating how the component attributes should be combined. The full name, including all middle names, titles, and suffixes as appropriate, formatted for display (e.g. Ms. Barbara Jane Jensen, III.). The family name of the User, or "Last Name" in most Western languages (e.g. Jensen given the full name Ms. Barbara Jane Jensen, III.). The given name of the User, or "First Name" in most Western languages (e.g. Barbara given the full name Ms. Barbara Jane Jensen, III.). The middle name(s) of the User (e.g. Jane given the full name Ms. Barbara Jane Jensen, III.). The honorific prefix(es) of the User, or "Title" in most Western languages (e.g. Ms. given the full name Ms. Barbara Jane Jensen, III.). The honorific suffix(es) of the User, or "Suffix" in most Western languages (e.g. III. given the full name Ms. Barbara Jane Jensen, III.). The name of the User, suitable for display to end-users. Each User returned MAY include a non-empty displayName value. The name SHOULD be the full name of the User being described if known (e.g. Babs Jensen or Ms. Barbara J Jensen, III), but MAY be a username or handle, if that is all that is available (e.g. bjensen). The value provided SHOULD be the primary textual label by which this User is normally displayed by the Service Provider when presenting it to end-users. The casual way to address the user in real life, e.g. "Bob" or "Bobby" instead of "Robert". This attribute SHOULD NOT be used to represent a User's username (e.g. bjensen or mpepperidge). A fully qualified URL to a page representing the User's online profile. The user’s title, such as “Vice President.” Used to identify the organization to user relationship. Typical values used might be "Contractor", "Employee", "Intern", "Temp", "External", and "Unknown" but any value may be used. Indicates the User's preferred written or spoken language. Generally used for selecting a localized User interface. Valid values are concatenation of the ISO 639-1 two letter language code, an underscore, and the ISO 3166-1 2 letter country code; e.g., 'en_US' specifies the language English and country US. Used to indicate the User's default location for purposes of localizing items such as currency, date time format, numerical representations, etc. A locale value is a concatenation of the ISO 639-1 two letter language code, an underscore, and the ISO 3166-1 2 letter country code; e.g., 'en_US' specifies the language English and country US. The User's time zone in the "Olson" timezone database format; e.g.,'America/Los_Angeles'. A Boolean value indicating the User's administrative status. The definitive meaning of this attribute is determined by the Service Provider though a value of true infers the User is, for example, able to login while a value of false implies the User's account has been suspended. The User's clear text password. This attribute is intended to be used as a means to specify an initial password when creating a new User or to reset an existing User's password. No accepted standards exist to convey password policies, hence Consumers should expect Service Providers to reject password values. This value MUST never be returned by a Service Provider in any form.
The following multi-valued attributes are defined. E-mail addresses for the User. The value SHOULD be canonicalized by the Service Provider, e.g. bjensen@example.com instead of bjensen@EXAMPLE.COM. Canonical Type values of work, home, and other. Phone numbers for the User. The value SHOULD be canonicalized by the Service Provider according to format in RFC3966 e.g. 'tel:+1-201-555-0123'. Canonical Type values of work, home, mobile, fax, pager and other. Instant messaging address for the User. No official canonicalization rules exist for all instant messaging addresses, but Service Providers SHOULD, when appropriate, remove all whitespace and convert the address to lowercase. Instead of the standard Canonical Values for type, this attribute defines the following Canonical Values to represent currently popular IM services: aim, gtalk, icq, xmpp, msn, skype, qq, and yahoo. URL of a photo of the User. The value SHOULD be a canonicalized URL, and MUST point to an image file (e.g. a GIF, JPEG, or PNG image file) rather than to a web page containing an image. Service Providers MAY return the same image at different sizes, though it is recognized that no standard for describing images of various sizes currently exists. Note that this attribute SHOULD NOT be used to send down arbitrary photos taken by this User, but specifically profile photos of the User suitable for display when describing the User. Instead of the standard Canonical Values for type, this attribute defines the following Canonical Values to represent popular photo sizes: photo, thumbnail. A physical mailing address for this User. Canonical Type Values of work, home, and other. The value attribute is a complex type with the following sub-attributes. All Sub-Attributes are OPTIONAL. The full mailing address, formatted for display or use with a mailing label. This attribute MAY contain newlines. The full street address component, which may include house number, street name, P.O. box, and multi-line extended street address information. This attribute MAY contain newlines. The city or locality component. The state or region component. The zipcode or postal code component. The country name component. When specified the value MUST be in ISO 3166-1 alpha 2 "short" code format; e.g., the United States and Sweden are "US" and "SE", respectively. A list of groups that the user belongs to, either thorough direct membership, nested groups, or dynamically calculated. The values are meant to enable expression of common group or role based access control models, although no explicit authorization model is defined. It is intended that the semantics of group membership and any behavior or authorization granted as a result of membership are defined by the Service Provider. The Canonical types "direct" and "indirect" are defined to describe how the group membership was derived. Direct group membership indicates the User is directly associated with the group and SHOULD indicate that Consumers may modify membership through the Group Resource. Indirect membership indicates User membership is transitive or dynamic and implies that Consumers cannot modify indirect group membership through the Group resource but MAY modify direct group membership through the Group resource which MAY influence indirect memberships. If the SCIM Service Provider exposes a Group resource, the value MUST be the "id" attribute of the corresponding Group resources to which the user belongs. Since this attribute is read-only, group membership changes MUST be applied via the Group Resource. READ-ONLY. A list of entitlements for the User that represent a thing the User has. That is, an entitlement is an additional right to a thing, object or service. No vocabulary or syntax is specified and Service Providers/Consumers are expected to encode sufficient information in the value so as to accurately and without ambiguity determine what the User has access to. This value has NO canonical types though type may be useful as a means to scope entitlements. A list of roles for the User that collectively represent who the User is; e.g., 'Student', "Faculty". No vocabulary or syntax is specified though it is expected that a role value is a String or label representing a collection of entitlements. This value has NO canonical types. A list of certificates issued to the User. Values are Binary and DER encoded x509. This value has NO canonical types.
The following SCIM extension defines attributes commonly used in representing users that belong to, or act on behalf of a business or enterprise. The enterprise user extension is identified using the following URI: 'urn:scim:schemas:extension:enterprise:1.0'. The following Singular Attributes are defined: Numeric or alphanumeric identifier assigned to a person, typically based on order of hire or association with an organization. Identifies the name of a cost center. Identifies the name of an organization. Identifies the name of a division. Identifies the name of a department. The User's manager. A complex type that optionally allows Service Providers to represent organizational hierarchy by referencing the "id" attribute of another User. The id of the SCIM resource representing the User's manager. REQUIRED. The displayName of the User's manager. OPTIONAL and READ-ONLY.
SCIM provides a schema for representing groups, identified using the following URI: 'urn:scim:schemas:core:1.0'. Group resources are meant to enable expression of common Group or role based access control models, although no explicit authorization model is defined. It is intended that the semantics of group membership and any behavior or authorization granted as a result of membership are defined by the Service Provider are considered out of scope for this specification. The following Singular Attribute is defined in addition to the common attributes defined in SCIM Core Schema: A human readable name for the Group. REQUIRED. The following multi-valued attribute is defined in addition to the common attributes defined in SCIM Core Schema: A list of members of the Group. Canonical Types "User" and "Group" are READ-ONLY. The value must be the "id" of a SCIM resource, either a User, or a Group. The intention of the Group type is to allow the Service Provider to support nested Groups. Service Providers MAY require Consumers to provide a non-empty members value based on the "required" sub attribute of the "members" attribute in Group Resource Schema.
SCIM provides a schema for representing the Service Provider's configuration identified using the following URI: 'urn:scim:schemas:core:1.0' The Service Provider Configuration Resource enables a Service Provider to expose its compliance with the SCIM specification in a standardized form as well as provide additional implementation details to Consumers. All attributes are READ-ONLY. The following Singular Attributes are defined in addition to the common attributes defined in Core Schema: An HTTP addressable URL pointing to the Service Provider's human consumable help documentation. A complex type that specifies PATCH configuration options. REQUIRED. Boolean value specifying whether the operation is supported. REQUIRED. A complex type that specifies BULK configuration options. REQUIRED Boolean value specifying whether the operation is supported. REQUIRED. An integer value specifying the maximum number of operations. REQUIRED. An integer value specifying the maximum payload size in bytes. REQUIRED. A complex type that specifies FILTER options. REQUIRED. Boolean value specifying whether the operation is supported. REQUIRED. Integer value specifying the maximum number of Resources returned in a response. REQUIRED. A complex type that specifies Change Password configuration options. REQUIRED. Boolean value specifying whether the operation is supported. REQUIRED. A complex type that specifies Sort configuration options. REQUIRED. Boolean value specifying whether sorting is supported. REQUIRED. A complex type that specifies Etag configuration options. REQUIRED. Boolean value specifying whether the operation is supported. REQUIRED. A complex type that specifies whether the XML data format is supported. REQUIRED. Boolean value specifying whether the operation is supported. REQUIRED. The following multi-valued attribute is defined in addition to the common attributes defined in Core Schema: A complex type that specifies supported Authentication Scheme properties. Instead of the standard Canonical Values for type, this attribute defines the following Canonical Values to represent common schemes: oauth, oauth2, oauthbearertoken, httpbasic, and httpdigest. To enable seamless discovery of configuration, the Service Provider SHOULD, with the appropriate security considerations, make the authenticationSchemes attribute publicly accessible without prior authentication. REQUIRED. The common authentication scheme name; e.g., HTTP Basic. REQUIRED. A description of the Authentication Scheme. REQUIRED. A HTTP addressable URL pointing to the Authentication Scheme's specification. OPTIONAL. A HTTP addressable URL pointing to the Authentication Scheme's usage documentation. OPTIONAL.
The Resource schema specifies the Attribute(s) and meta-data that constitute a Resource. Schema Resources are READ-ONLY and identified using the following URI: 'urn:scim:schemas:core:1.0'. Unlike other core Resources the schema Resource MAY contain a complex object within a Sub-Attribute and all Attributes are REQUIRED unless other specified. The following Singular Attributes are defined: The Resource name. When applicable Service Providers MUST specify the name specified in the core schema specification; e.g., "User" or "Group". The Resource's human readable description. When applicable Service Providers MUST specify the description specified in the core schema specification. The Resource's associated schema URI; e.g., urn:scim:schemas:core:1.0. The Resource's HTTP addressable endpoint relative to the Base URL; e.g., /Users. The following multi-valued attribute is defined: A complex type that specifies the set of Resource attributes. The attribute's name. The attribute's data type; e.g., String. Boolean value indicating the attribute's plurality. String value specifying the child XML element name; e.g., the 'emails' attribute value is 'email', 'phoneNumbers', is 'phoneNumber'. REQUIRED when the multiValued attribute value is true otherwise this attribute MUST be omitted. The attribute's human readable description. When applicable Service Providers MUST specify the description specified in the core schema specification. The attribute's associated schema; e.g., urn:scim:schemas:core:1.0. A Boolean value that specifies if the attribute is mutable. A Boolean value that specifies if the attribute is required. A Boolean value that specifies if the String attribute is case sensitive. The following multi-valued attributes are defined. There are no canonical type values defined and the primary value serves no useful purpose. A list specifying the contained attributes. OPTIONAL. The attribute's name. The attribute's data type; e.g., String. The attribute's human readable description. When applicable Service Providers MUST specify the description specified in the core schema specification. A Boolean value that specifies if the attribute is mutable. A Boolean value that specifies if the attribute is required. A Boolean value that specifies if the String attribute is case sensitive. A collection of canonical values. When applicable Service Providers MUST specify the canonical types specified in the core schema specification; e.g.,"work","home". OPTIONAL.
The following is a non-normative example of the minimal required SCIM representation in JSON format.
The following is a non-normative example of the fully populated SCIM representation in JSON format.
The following is a non-normative example of the fully populated User using the enterprise User extension in JSON format.
The following is a non-normative example of SCIM Group representation in JSON format.
The following is a non-normative example of the SCIM Service Provider Configuration representation in JSON format.
The following is a normative example of the SCIM Resource Schema representation in JSON format.
The following is a non-normative example of the minimal required SCIM User representation in XML format. 2819c223-7f76-453a-919d-413861904646 bjensen@example.com ]]>
The following is a non-normative example of the fully populated SCIM representation in XML format. 2819c223-7f76-453a-919d-413861904646 701984 bjensen@example.com Ms. Babs J Jensen III Jensen Barbara Jane Ms. III Babs Jensen Babs https://login.example.com/bjensen bjensen@example.com work true babs@jensen.com home
100 Universal City Plaza\nHollywood, CA 91608 USA 100 Universal City Plaza Hollywood CA 91608 USA work true
456 Hollywood Blvd\nHollywood, CA 91608 USA 456 Hollywood Blvd San Francisco CA 91608 USA home
555-555-5555 work 555-555-4444 mobile someaimhandle aim https://photos.example.com/profilephoto/72930000000Ccne/F photo https://photos.example.com/profilephoto/72930000000Ccne/T thumbnail Employee Tour Guide en_US en_US America/Los_Angeles true t1meMa$heen e9e30dba-f08f-4109-8486-d5c6a331660a Tour Guides 6d1a1088-3a56-4371-8e3b-6d48d67493ec Employees 5fd998b9-d2bd-479c-991b-6790537608dc US Employees administrator delete users MIIDQzCCAqygAwIBAgICEAAwDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMx EzARBgNVBAgMCkNhbGlmb3JuaWExFDASBgNVBAoMC2V4YW1wbGUuY29tMRQwEgYD VQQDDAtleGFtcGxlLmNvbTAeFw0xMTEwMjIwNjI0MzFaFw0xMjEwMDQwNjI0MzFa MH8xCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRQwEgYDVQQKDAtl eGFtcGxlLmNvbTEhMB8GA1UEAwwYTXMuIEJhcmJhcmEgSiBKZW5zZW4gSUlJMSIw IAYJKoZIhvcNAQkBFhNiamVuc2VuQGV4YW1wbGUuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7Kr+Dcds/JQ5GwejJFcBIP682X3xpjis56AK02bc 1FLgzdLI8auoR+cC9/Vrh5t66HkQIOdA4unHh0AaZ4xL5PhVbXIPMB5vAPKpzz5i PSi8xO8SL7I7SDhcBVJhqVqr3HgllEG6UClDdHO7nkLuwXq8HcISKkbT5WFTVfFZ zidPl8HZ7DhXkZIRtJwBweq4bvm3hM1Os7UQH05ZS6cVDgweKNwdLLrT51ikSQG3 DYrl+ft781UQRIqxgwqCfXEuDiinPh0kkvIi5jivVu1Z9QiwlYEdRbLJ4zJQBmDr SGTMYn4lRc2HgHO4DqB/bnMVorHB0CC6AV1QoFK4GPe1LwIDAQABo3sweTAJBgNV HRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZp Y2F0ZTAdBgNVHQ4EFgQU8pD0U0vsZIsaA16lL8En8bx0F/gwHwYDVR0jBBgwFoAU dGeKitcaF7gnzsNwDx708kqaVt0wDQYJKoZIhvcNAQEFBQADgYEAA81SsFnOdYJt Ng5Tcq+/ByEDrBgnusx0jloUhByPMEVkoMZ3J7j1ZgI8rAbOkNngX8+pKfTiDz1R C4+dx8oU6Za+4NJXUjlL5CvV6BEYb1+QAEJwitTVvxB/A67g42/vzgAtoRUeDov1 +GFiBZ+GNF/cAYKcMtGcrs2i97ZkJMo= 2010-01-23T04:56:22Z 2011-05-13T04:42:34Z W/"a330bc54f0671c9" https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 ]]>
The following is a non-normative example of the fully populated User using the enterprise User extension in XML format. 2819c223-7f76-453a-919d-413861904646 701984 bjensen@example.com Ms. Babs J Jensen III Jensen Barbara Jane Ms. III Babs Jensen Babs https://login.example.com/bjensen Tour Guide Employee en_US en_US America/Los_Angeles true t1meMa$heen bjensen@example.com work true babs@jensen.com/value> home
100 Universal City Plaza\nHollywood, CA 91608 USA 100 Universal City Plaza Hollywood CA 91608 USA work true
456 Hollywood Blvd\nHollywood, CA 91608 USA 456 Hollywood Blvd San Francisco CA 91608 USA
555-555-5555 work 555-555-4444 mobile someaimhandle aim https://photos.example.com/profilephoto/72930000000Ccne/F photo> https://photos.example.com/profilephoto/72930000000Ccne/T thumbnail> Tour Guides 00300000005N2Y6AA Employees 00300000005N34H78 US Employees 00300000005N98YT1 administrator delete users MIIDQzCCAqygAwIBAgICEAAwDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMx EzARBgNVBAgMCkNhbGlmb3JuaWExFDASBgNVBAoMC2V4YW1wbGUuY29tMRQwEgYD VQQDDAtleGFtcGxlLmNvbTAeFw0xMTEwMjIwNjI0MzFaFw0xMjEwMDQwNjI0MzFa MH8xCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRQwEgYDVQQKDAtl eGFtcGxlLmNvbTEhMB8GA1UEAwwYTXMuIEJhcmJhcmEgSiBKZW5zZW4gSUlJMSIw IAYJKoZIhvcNAQkBFhNiamVuc2VuQGV4YW1wbGUuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7Kr+Dcds/JQ5GwejJFcBIP682X3xpjis56AK02bc 1FLgzdLI8auoR+cC9/Vrh5t66HkQIOdA4unHh0AaZ4xL5PhVbXIPMB5vAPKpzz5i PSi8xO8SL7I7SDhcBVJhqVqr3HgllEG6UClDdHO7nkLuwXq8HcISKkbT5WFTVfFZ zidPl8HZ7DhXkZIRtJwBweq4bvm3hM1Os7UQH05ZS6cVDgweKNwdLLrT51ikSQG3 DYrl+ft781UQRIqxgwqCfXEuDiinPh0kkvIi5jivVu1Z9QiwlYEdRbLJ4zJQBmDr SGTMYn4lRc2HgHO4DqB/bnMVorHB0CC6AV1QoFK4GPe1LwIDAQABo3sweTAJBgNV HRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZp Y2F0ZTAdBgNVHQ4EFgQU8pD0U0vsZIsaA16lL8En8bx0F/gwHwYDVR0jBBgwFoAU dGeKitcaF7gnzsNwDx708kqaVt0wDQYJKoZIhvcNAQEFBQADgYEAA81SsFnOdYJt Ng5Tcq+/ByEDrBgnusx0jloUhByPMEVkoMZ3J7j1ZgI8rAbOkNngX8+pKfTiDz1R C4+dx8oU6Za+4NJXUjlL5CvV6BEYb1+QAEJwitTVvxB/A67g42/vzgAtoRUeDov1 +GFiBZ+GNF/cAYKcMtGcrs2i97ZkJMo= 701984 902c246b-6245-4190-8e05-00816be7344a Mandy Pepperidge 4130 Universal Studios Theme Park Tour Operations 2010-01-23T04:56:22Z 2011-05-13T04:42:34Z W/"3694e05e9dff591" https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 ]]>
The following is a non-normative example of a SCIM Group representation in XML format. 2819c223-7f76-453a-919d-413861904646 Tour Guides 902c246b-6245-4190-8e05-00816be7344a Babs Jensen 902c246b-6245-4190-8e05-00816be7344a Mandy Pepperidge ]]>
The SCIM Core schema contains personally identifiable information as well as other sensitive data. Aside from prohibiting password values in a SCIM response this specification does not provide any means or guarantee of confidentiality.
The SCIM Community would like to thank the following people for the work they've done in the research, formulation, drafting, editing, and support of this specification. Morteza Ansari (morteza.ansari@cisco.com) Sidharth Choudhury (schoudhury@salesforce.com) Samuel Erdtman (samuel@erdtman.se) Kelly Grizzle (kelly.grizzle@sailpoint.com) Chris Phillips (cjphillips@gmail.com) Erik Wahlström (erik.wahlstrom@nexussafe.com) Special thanks to Joeseph Smarr, who's excellent work on the Portable Contacts Specification provided a basis for the SCIM schema structure and text. Portable Contacts 1.0 Draft C - Schema Only Plaxo --Apple-Mail=_19FFEAC6-A1D7-4DDC-818F-22E497C6FAE7 Content-Disposition: attachment; filename=draft-scim-core-schema-01.txt Content-Type: text/plain; name="draft-scim-core-schema-01.txt" Content-Transfer-Encoding: quoted-printable Draft C. Mortimore, Ed. Salesforce P. Harding P. Madsen Ping T. Drake UnboundID July 09, 2012 System for Cross-Domain Identity Management: Core Schema 1.1 Abstract The System for Cross-Domain Identity Management (SCIM) specification is designed to make managing user identity in cloud based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols. In essence, make it fast, cheap, and easy to move identity in to, out of, and around the cloud. This document provides a platform neutral schema and extension model for representing users and groups in JSON and XML formats. This schema is intended for exchange and use with cloud service providers. Additional binding documents provide a standard REST API, SAML binding, and use cases. Mortimore, et al. [Page 1] =0C draft-scim-core-schema-01 July 2012 Table of Contents 1. Requirements Notation and Conventions . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 3. SCIM Schema Structure . . . . . . . . . . . . . . . . . . . . 6 3.1. Attribute Data Types . . . . . . . . . . . . . . . . . . . 6 3.2. Multi-valued Attributes . . . . . . . . . . . . . . . . . 7 4. Schema Extension Model . . . . . . . . . . . . . . . . . . . . 9 5. SCIM Core Schema . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Common Schema Attributes . . . . . . . . . . . . . . . . . 10 5.2. "schemas" Attribute . . . . . . . . . . . . . . . . . . . 11 6. SCIM User Schema . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Singular Attributes . . . . . . . . . . . . . . . . . . . 12 6.2. Multi-valued Attributes . . . . . . . . . . . . . . . . . 14 7. SCIM Enterprise User Schema Extension . . . . . . . . . . . . 17 8. SCIM Group Schema . . . . . . . . . . . . . . . . . . . . . . 18 9. Service Provider Configuration Schema . . . . . . . . . . . . 19 10. Resource Schema . . . . . . . . . . . . . . . . . . . . . . . 21 11. JSON Representation . . . . . . . . . . . . . . . . . . . . . 23 11.1. Minimal User Representation . . . . . . . . . . . . . . . 23 11.2. Full User Representation . . . . . . . . . . . . . . . . . 23 11.3. Enterprise User Extension Representation . . . . . . . . . 26 11.4. Group Representation . . . . . . . . . . . . . . . . . . . 29 11.5. Service Provider Configuration Representation . . . . . . 29 11.6. Resource Schema Representation . . . . . . . . . . . . . . 31 12. XML Representation . . . . . . . . . . . . . . . . . . . . . . 36 12.1. Minimal Representation . . . . . . . . . . . . . . . . . . 36 12.2. Full Representation . . . . . . . . . . . . . . . . . . . 36 12.3. Enterprise User Extension Representation . . . . . . . . . 39 12.4. Group Representation . . . . . . . . . . . . . . . . . . . 42 13. Security Considerations . . . . . . . . . . . . . . . . . . . 43 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 44 14. Normative References . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 Mortimore, et al. [Page 2] =0C draft-scim-core-schema-01 July 2012 1. Requirements Notation and Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] . Throughout this document, values are quoted to indicate that they are to be taken literally. When using these values in protocol messages, the quotes MUST NOT be used as part of the value. Mortimore, et al. [Page 3] =0C draft-scim-core-schema-01 July 2012 2. Overview While there are existing standards for describing and exchanging user information, many of these standards can be difficult to implement and/or use; e.g., their wire protocols do not easily traverse firewalls and/or are not easily layered onto existing web protocols. As a result, many cloud providers implement non-standard APIs for managing users within their services. This increases both the cost and complexity associated with organizations adopting products and services from multiple cloud providers as they must perform redundant integration development. Similarly, cloud services providers seeking to interoperate with multiple application marketplaces or cloud identity providers must be redundantly integrated. SCIM seeks to simplify this problem through a simple to implement specification suite that provides a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema via a REST API. It draws inspiration and best practice, building upon existing user APIs and schemas from a wide variety of sources including, but not limited to, existing APIs exposed by cloud providers, PortableContacts, and LDAP directory services. This document provides a platform neutral schema and extension model for representing users and groups in JSON and XML formats. This schema is intended for exchange and use with cloud service providers. Additional binding documents provide a standard REST API, SAML binding, and use cases. 2.1. Definitions Service Provider: A web application that provides identity information via the SCIM protocol. Consumer: A website or application that uses the SCIM protocol to manage identity data maintained by the Service Provider. Resource: The Service Provider managed artifact containing one or more attributes; e.g., User or Group Singular Attribute: A Resource attribute that contains 0..1 values; e.g., displayName. Multi-valued Attribute: A Resource attribute that contains 0..n values; e.g., emails. Mortimore, et al. [Page 4] =0C draft-scim-core-schema-01 July 2012 Simple Attribute: A Singular or Multi-valued Attribute whose value is a primitive; e.g., String. Complex Attribute: A Singular or Multi-valued Attribute whose value is a composition of one or more Simple Attributes. Sub-Attribute: A Simple Attribute contained within a Complex Attribute. Mortimore, et al. [Page 5] =0C draft-scim-core-schema-01 July 2012 3. SCIM Schema Structure SCIM schema provides a minimal core schema for representing users and groups (resources), encompassing common attributes found in many existing deployments and schemas. A resource is a collection of attributes identified by one or more schemas. Minimally, an attribute consists of the attribute name and at least one Simple or Complex value either of which may be Multi- valued. SCIM schema defines the data type, plurality and other distinguishing features of an attribute. Unless otherwise specified all attributes are modifiable by Consumers. Immutable (read-only) attributes SHALL be specified as 'READ-ONLY' within the attribute definition. Additionally, Service Providers MAY choose to make some or all Resource attributes immutable and SHOULD identify those attributes via the associated Resource's schema endpoint (Section 5.2). Both XML and JSON formats are defined. Resource and attribute names MUST conform to XML naming rules;i.e., SCIM names MUST be valid XML names and SHOULD be camelCased. When marshalling or extending SCIM resources in XML implementors MUST use the normative, SCIM, XML schema (.xsd). SCIM resources represented in a schema-less format; e.g., JSON, MUST specify schema via the schemas attribute (Section 5.2). 3.1. Attribute Data Types Attribute data types are derived from XML schema [1] and unless otherwise specified are optional, modifiable by Consumers, and of type String (Section 3.1.1). The JSON format defines a limited set of data types, hence, where appropriate, alternate JSON representations are defined below. SCIM extensions SHOULD not introduce new data types. 3.1.1. String A sequence of characters as defined in section 3.2.1 of the XML Schema Datatypes Specification. A String attribute MAY specify a required data format. Additionally, when Canonical Values are specified Service Providers SHOULD conform to those values if appropriate, but MAY provide alternate String values to represent additional values. 3.1.2. Boolean The literal "true" or "false" as specified in section 3.2.2 of the XML Schema Datatypes Specification. Mortimore, et al. [Page 6] =0C draft-scim-core-schema-01 July 2012 3.1.3. Decimal A real number with at least one digit to the left and right of the period as specified in section 3.2.3 of the XML Schema Datatypes Specification. Values represented in JSON MUST conform to the XML constraints above and are represented as a JSON Number [2]. 3.1.4. Integer A Decimal number with no fractional digits as defined in section 3.3.13 of the XML Schema Datatypes Specification. Values represented in JSON MUST conform to the XML constraints above and are represented as a JSON Number [2]. 3.1.5. DateTime A dateTime (e.g. 2008-01-23T04:56:22Z) as specified in section 3.2.7 of the XML Schema Datatypes Specification. Values represented in JSON MUST conform to the XML constraints above and are represented as a JSON String [2]. 3.1.6. Binary The attribute value MUST be encoded as a valid xsd:base64Binary value as specified in section 3.2.16 of the XML Schema Datatypes Specification. Values represented in JSON MUST conform to the XML constraints above and are represented as a JSON String [2]. 3.1.7. Complex A Singular or Multi-valued Attribute whose value is a composition of one or more Simple Attributes as specified in section 3.4 XML Schema Datatypes Specification. JSON values are represented as JSON Objects [2]. 3.2. Multi-valued Attributes Multi-valued attributes are unordered lists of attributes. Each attribute MAY contain Sub-Attributes and therefore multi-valued attributes may contain Complex Attributes. The below Sub-Attributes are considered normative and when specified SHOULD be used as Mortimore, et al. [Page 7] =0C draft-scim-core-schema-01 July 2012 defined. type A label indicating the attribute's function; e.g., "work" or "home". primary A Boolean value indicating the 'primary' or preferred attribute value for this attribute, e.g. the preferred mailing address or primary e-mail address. The primary attribute value 'true' MUST appear no more than once. display A human readable name, primarily used for display purposes. READ-ONLY. operation The operation to perform on the multi-valued attribute during a PATCH request. The only valid value is "delete", which signifies that this instance should be removed from the Resource. value The attribute's significant value; e.g., the e-mail address, phone number, etc. Attributes that define a "value" sub-attribute MAY be alternately represented as a collection of primitive types. For example: { "emails": [ {"value":"bjensen@example.com"}, {"value":"babs@example.com"} ] } May also be represented as: { "emails": ["bjensen@example.com","babs@example.com"] } When returning multi-valued attributes, Service Providers SHOULD canonicalize the value returned, if appropriate (e.g. for e-mail addresses and URLs). Providers MAY return the same value more than once with different types (e.g. the same e-mail address may used for work and home), but SHOULD NOT return the same (type, value) combination more than once per Attribute, as this complicates processing by the Consumer. Mortimore, et al. [Page 8] =0C draft-scim-core-schema-01 July 2012 4. Schema Extension Model SCIM schema follows an object extension model similar to ObjectClasses used in LDAP. Unlike LDAP there is no inheritance model; all extensions are additive (similar to LDAP Auxiliary Object Classes [3]). Each value indicates additive schema that may exist in a SCIM representation as specified by extensions not defined in this suite. Schema extensions MUST NOT redefine any attributes defined in this specification and SHOULD follow conventions defined in this specification. Each schema extension must identify a URI used to identify the extension. XML MUST use XML namespaces and JSON formats MUST use the "schemas" attribute (Section 5.2) to distinguish extended resources and attributes. Mortimore, et al. [Page 9] =0C draft-scim-core-schema-01 July 2012 5. SCIM Core Schema 5.1. Common Schema Attributes Each SCIM Resource (Users, Groups, etc.) includes the below common attributes. These attributes MUST be included in all Resources, including any extended Resource types. It is not necessary to specify the schemas attribute if the Resource is fully defined in this document as the core schema is implicitly included. id Unique identifier for the SCIM Resource as defined by the Service Provider. Each representation of the Resource MUST include a non- empty id value. This identifier MUST be unique across the Service Provider's entire set of Resources. It MUST be a stable, non- reassignable identifier that does not change when the same Resource is returned in subsequent requests. The value of the id attribute is always issued by the Service Provider and MUST never be specified by the Service Consumer. bulkId: is a reserved keyword and MUST NOT be used in the unique identifier. REQUIRED and READ-ONLY. externalId An identifier for the Resource as defined by the Service Consumer. The externalId may simplify identification of the Resource between Service Consumer and Service provider by allowing the Consumer to refer to the Resource with its own identifier, obviating the need to store a local mapping between the local identifier of the Resource and the identifier used by the Service Provider. Each Resource MAY include a non-empty externalId value. The value of the externalId attribute is always issued be the Service Consumer and can never be specified by the Service Provider. The Service Provider MUST always interpret the externalId as scoped to the Service Consumer's tenant. meta A complex attribute containing resource metadata. All sub- attributes are OPTIONAL created The DateTime the Resource was added to the Service Provider. The attribute MUST be a DateTime. READ-ONLY. lastModified The most recent DateTime the details of this Resource were updated at the Service Provider. If this Resource has never been modified since its initial creation, the value MUST be the same as the value of created. The attribute MUST be a DateTime. READ-ONLY. Mortimore, et al. [Page 10] =0C draft-scim-core-schema-01 July 2012 location The URI of the Resource being returned. This value MUST be the same as the Location HTTP response header. READ-ONLY. version The version of the Resource being returned. This value must be the same as the ETag HTTP response header. READ-ONLY. attributes The names of the attributes to remove from the Resource during a PATCH operation. 5.2. "schemas" Attribute SCIM supports resources of different types, with extensible schemas. Each resource MUST be indicated using fully qualified URLs. Where a specific representation has existing support for expressing schema, the traditional convention of that representation MUST be applied. For example, when representing users using XML, XML Namespace should be used. When a representation does not explicitly provide support for indicating a schema, such as JSON, a schemas attribute is used to indicate the version of SCIM schema as well as any schema extensions. schemas The schemas attribute is an array of Strings which allows introspection of the supported schema version for a SCIM representation as well any schema extensions supported by that representation. Each String value must be a unique URI. This specification defines URIs for User, Group, and a standard "enterprise" extension. All representations of SCIM schema MUST include a non-zero value array with value(s) of the URIs supported by that representation. Duplicate values MUST NOT be included. Value order is not specified and MUST not impact behavior. REQUIRED. Mortimore, et al. [Page 11] =0C draft-scim-core-schema-01 July 2012 6. SCIM User Schema SCIM provides a schema for representing Users, identified using the following URI: 'urn:scim:schemas:core:1.0'. The following attributes are defined in addition to those attributes defined in SCIM Core Schema: 6.1. Singular Attributes userName Unique identifier for the User, typically used by the user to directly authenticate to the service provider. Often displayed to the user as their unique identifier within the system (as opposed to id or externalId, which are generally opaque and not user-friendly identifiers). Each User MUST include a non-empty userName value. This identifier MUST be unique across the Service Consumer's entire set of Users. REQUIRED. name The components of the User's real name. Providers MAY return just the full name as a single string in the formatted sub- attribute, or they MAY return just the individual component attributes using the other sub-attributes, or they MAY return both. If both variants are returned, they SHOULD be describing the same name, with the formatted name indicating how the component attributes should be combined. formatted The full name, including all middle names, titles, and suffixes as appropriate, formatted for display (e.g. Ms. Barbara Jane Jensen, III.). familyName The family name of the User, or "Last Name" in most Western languages (e.g. Jensen given the full name Ms. Barbara Jane Jensen, III.). givenName The given name of the User, or "First Name" in most Western languages (e.g. Barbara given the full name Ms. Barbara Jane Jensen, III.). middleName The middle name(s) of the User (e.g. Jane given the full name Ms. Barbara Jane Jensen, III.). honorificPrefix The honorific prefix(es) of the User, or "Title" in most Western languages (e.g. Ms. given the full name Ms. Barbara Jane Jensen, III.). honorificSuffix The honorific suffix(es) of the User, or "Suffix" in most Western languages (e.g. III. given the full name Ms. Barbara Jane Jensen, III.). Mortimore, et al. [Page 12] =0C draft-scim-core-schema-01 July 2012 displayName The name of the User, suitable for display to end-users. Each User returned MAY include a non-empty displayName value. The name SHOULD be the full name of the User being described if known (e.g. Babs Jensen or Ms. Barbara J Jensen, III), but MAY be a username or handle, if that is all that is available (e.g. bjensen). The value provided SHOULD be the primary textual label by which this User is normally displayed by the Service Provider when presenting it to end-users. nickName The casual way to address the user in real life, e.g. "Bob" or "Bobby" instead of "Robert". This attribute SHOULD NOT be used to represent a User's username (e.g. bjensen or mpepperidge). profileUrl A fully qualified URL to a page representing the User's online profile. title The user's title, such as "Vice President." userType Used to identify the organization to user relationship. Typical values used might be "Contractor", "Employee", "Intern", "Temp", "External", and "Unknown" but any value may be used. preferredLanguage Indicates the User's preferred written or spoken language. Generally used for selecting a localized User interface. Valid values are concatenation of the ISO 639-1 two letter language code [4], an underscore, and the ISO 3166-1 2 letter country code [5]; e.g., 'en_US' specifies the language English and country US. locale Used to indicate the User's default location for purposes of localizing items such as currency, date time format, numerical representations, etc. A locale value is a concatenation of the ISO 639-1 two letter language code [4], an underscore, and the ISO 3166-1 2 letter country code [5]; e.g., 'en_US' specifies the language English and country US. timezone The User's time zone in the "Olson" timezone database format [6]; e.g.,'America/Los_Angeles'. active A Boolean value indicating the User's administrative status. The definitive meaning of this attribute is determined by the Service Provider though a value of true infers the User is, for example, able to login while a value of false implies the User's account has been suspended. Mortimore, et al. [Page 13] =0C draft-scim-core-schema-01 July 2012 password The User's clear text password. This attribute is intended to be used as a means to specify an initial password when creating a new User or to reset an existing User's password. No accepted standards exist to convey password policies, hence Consumers should expect Service Providers to reject password values. This value MUST never be returned by a Service Provider in any form. 6.2. Multi-valued Attributes The following multi-valued attributes are defined. emails E-mail addresses for the User. The value SHOULD be canonicalized by the Service Provider, e.g. bjensen@example.com instead of bjensen@EXAMPLE.COM. Canonical Type values of work, home, and other. phoneNumbers Phone numbers for the User. The value SHOULD be canonicalized by the Service Provider according to format in RFC3966 [7] e.g. 'tel:+1-201-555-0123'. Canonical Type values of work, home, mobile, fax, pager and other. ims Instant messaging address for the User. No official canonicalization rules exist for all instant messaging addresses, but Service Providers SHOULD, when appropriate, remove all whitespace and convert the address to lowercase. Instead of the standard Canonical Values for type, this attribute defines the following Canonical Values to represent currently popular IM services: aim, gtalk, icq, xmpp, msn, skype, qq, and yahoo. photos URL of a photo of the User. The value SHOULD be a canonicalized URL, and MUST point to an image file (e.g. a GIF, JPEG, or PNG image file) rather than to a web page containing an image. Service Providers MAY return the same image at different sizes, though it is recognized that no standard for describing images of various sizes currently exists. Note that this attribute SHOULD NOT be used to send down arbitrary photos taken by this User, but specifically profile photos of the User suitable for display when describing the User. Instead of the standard Canonical Values for type, this attribute defines the following Canonical Values to represent popular photo sizes: photo, thumbnail. addresses A physical mailing address for this User. Canonical Type Values of work, home, and other. The value attribute is a complex type with the following sub-attributes. All Sub-Attributes are OPTIONAL. Mortimore, et al. [Page 14] =0C draft-scim-core-schema-01 July 2012 formatted The full mailing address, formatted for display or use with a mailing label. This attribute MAY contain newlines. streetAddress The full street address component, which may include house number, street name, P.O. box, and multi-line extended street address information. This attribute MAY contain newlines. locality The city or locality component. region The state or region component. postalCode The zipcode or postal code component. country The country name component. When specified the value MUST be in ISO 3166-1 alpha 2 "short" code format [5]; e.g., the United States and Sweden are "US" and "SE", respectively. groups A list of groups that the user belongs to, either thorough direct membership, nested groups, or dynamically calculated. The values are meant to enable expression of common group or role based access control models, although no explicit authorization model is defined. It is intended that the semantics of group membership and any behavior or authorization granted as a result of membership are defined by the Service Provider. The Canonical types "direct" and "indirect" are defined to describe how the group membership was derived. Direct group membership indicates the User is directly associated with the group and SHOULD indicate that Consumers may modify membership through the Group Resource. Indirect membership indicates User membership is transitive or dynamic and implies that Consumers cannot modify indirect group membership through the Group resource but MAY modify direct group membership through the Group resource which MAY influence indirect memberships. If the SCIM Service Provider exposes a Group resource, the value MUST be the "id" attribute of the corresponding Group resources to which the user belongs. Since this attribute is read-only, group membership changes MUST be applied via the Group Resource (Section 8). READ-ONLY. entitlements A list of entitlements for the User that represent a thing the User has. That is, an entitlement is an additional right to a thing, object or service. No vocabulary or syntax is specified and Service Providers/Consumers are expected to encode sufficient information in the value so as to accurately and without ambiguity determine what the User has access to. This value has NO canonical types though type may be useful as a means to scope entitlements. Mortimore, et al. [Page 15] =0C draft-scim-core-schema-01 July 2012 roles A list of roles for the User that collectively represent who the User is; e.g., 'Student', "Faculty". No vocabulary or syntax is specified though it is expected that a role value is a String or label representing a collection of entitlements. This value has NO canonical types. x509Certificates A list of certificates issued to the User. Values are Binary (Section 3.1.6) and DER encoded x509. This value has NO canonical types. Mortimore, et al. [Page 16] =0C draft-scim-core-schema-01 July 2012 7. SCIM Enterprise User Schema Extension The following SCIM extension defines attributes commonly used in representing users that belong to, or act on behalf of a business or enterprise. The enterprise user extension is identified using the following URI: 'urn:scim:schemas:extension:enterprise:1.0'. The following Singular Attributes are defined: employeeNumber Numeric or alphanumeric identifier assigned to a person, typically based on order of hire or association with an organization. costCenter Identifies the name of a cost center. organization Identifies the name of an organization. division Identifies the name of a division. department Identifies the name of a department. manager The User's manager. A complex type that optionally allows Service Providers to represent organizational hierarchy by referencing the "id" attribute of another User. managerId The id of the SCIM resource representing the User's manager. REQUIRED. displayName The displayName of the User's manager. OPTIONAL and READ-ONLY. Mortimore, et al. [Page 17] =0C draft-scim-core-schema-01 July 2012 8. SCIM Group Schema SCIM provides a schema for representing groups, identified using the following URI: 'urn:scim:schemas:core:1.0'. Group resources are meant to enable expression of common Group or role based access control models, although no explicit authorization model is defined. It is intended that the semantics of group membership and any behavior or authorization granted as a result of membership are defined by the Service Provider are considered out of scope for this specification. The following Singular Attribute is defined in addition to the common attributes defined in SCIM Core Schema: displayName A human readable name for the Group. REQUIRED. The following multi-valued attribute is defined in addition to the common attributes defined in SCIM Core Schema: members A list of members of the Group. Canonical Types "User" and "Group" are READ-ONLY. The value must be the "id" of a SCIM resource, either a User, or a Group. The intention of the Group type is to allow the Service Provider to support nested Groups. Service Providers MAY require Consumers to provide a non-empty members value based on the "required" sub attribute of the "members" attribute in Group Resource Schema. Mortimore, et al. [Page 18] =0C draft-scim-core-schema-01 July 2012 9. Service Provider Configuration Schema SCIM provides a schema for representing the Service Provider's configuration identified using the following URI: 'urn:scim:schemas:core:1.0' The Service Provider Configuration Resource enables a Service Provider to expose its compliance with the SCIM specification in a standardized form as well as provide additional implementation details to Consumers. All attributes are READ-ONLY. The following Singular Attributes are defined in addition to the common attributes defined in Core Schema: documentationUrl An HTTP addressable URL pointing to the Service Provider's human consumable help documentation. patch A complex type that specifies PATCH configuration options. REQUIRED. supported Boolean value specifying whether the operation is supported. REQUIRED. bulk A complex type that specifies BULK configuration options. REQUIRED supported Boolean value specifying whether the operation is supported. REQUIRED. maxOperations An integer value specifying the maximum number of operations. REQUIRED. maxPayloadSize An integer value specifying the maximum payload size in bytes. REQUIRED. filter A complex type that specifies FILTER options. REQUIRED. supported Boolean value specifying whether the operation is supported. REQUIRED. maxResults Integer value specifying the maximum number of Resources returned in a response. REQUIRED. changePassword A complex type that specifies Change Password configuration options. REQUIRED. Mortimore, et al. [Page 19] =0C draft-scim-core-schema-01 July 2012 supported Boolean value specifying whether the operation is supported. REQUIRED. sort A complex type that specifies Sort configuration options. REQUIRED. supported Boolean value specifying whether sorting is supported. REQUIRED. etag A complex type that specifies Etag configuration options. REQUIRED. supported Boolean value specifying whether the operation is supported. REQUIRED. xmlDataFormat A complex type that specifies whether the XML data format is supported. REQUIRED. supported Boolean value specifying whether the operation is supported. REQUIRED. The following multi-valued attribute is defined in addition to the common attributes defined in Core Schema: authenticationSchemes A complex type that specifies supported Authentication Scheme properties. Instead of the standard Canonical Values for type, this attribute defines the following Canonical Values to represent common schemes: oauth, oauth2, oauthbearertoken, httpbasic, and httpdigest. To enable seamless discovery of configuration, the Service Provider SHOULD, with the appropriate security considerations, make the authenticationSchemes attribute publicly accessible without prior authentication. REQUIRED. name The common authentication scheme name; e.g., HTTP Basic. REQUIRED. description A description of the Authentication Scheme. REQUIRED. specUrl A HTTP addressable URL pointing to the Authentication Scheme's specification. OPTIONAL. documentationUrl A HTTP addressable URL pointing to the Authentication Scheme's usage documentation. OPTIONAL. Mortimore, et al. [Page 20] =0C draft-scim-core-schema-01 July 2012 10. Resource Schema The Resource schema specifies the Attribute(s) and meta-data that constitute a Resource. Schema Resources are READ-ONLY and identified using the following URI: 'urn:scim:schemas:core:1.0'. Unlike other core Resources the schema Resource MAY contain a complex object within a Sub-Attribute and all Attributes are REQUIRED unless other specified. The following Singular Attributes are defined: name The Resource name. When applicable Service Providers MUST specify the name specified in the core schema specification; e.g., "User" or "Group". description The Resource's human readable description. When applicable Service Providers MUST specify the description specified in the core schema specification. schema The Resource's associated schema URI; e.g., urn:scim:schemas:core:1.0. endpoint The Resource's HTTP addressable endpoint relative to the Base URL; e.g., /Users. The following multi-valued attribute is defined: attributes A complex type that specifies the set of Resource attributes. name The attribute's name. type The attribute's data type; e.g., String. multiValued Boolean value indicating the attribute's plurality. multiValuedAttributeChildName String value specifying the child XML element name; e.g., the 'emails' attribute value is 'email', 'phoneNumbers', is 'phoneNumber'. REQUIRED when the multiValued attribute value is true otherwise this attribute MUST be omitted. description The attribute's human readable description. When applicable Service Providers MUST specify the description specified in the core schema specification. Mortimore, et al. [Page 21] =0C draft-scim-core-schema-01 July 2012 schema The attribute's associated schema; e.g., urn:scim:schemas:core:1.0. readOnly A Boolean value that specifies if the attribute is mutable. required A Boolean value that specifies if the attribute is required. caseExact A Boolean value that specifies if the String attribute is case sensitive. The following multi-valued attributes are defined. There are no canonical type values defined and the primary value serves no useful purpose. subAttributes A list specifying the contained attributes. OPTIONAL. name The attribute's name. type The attribute's data type; e.g., String. description The attribute's human readable description. When applicable Service Providers MUST specify the description specified in the core schema specification. readOnly A Boolean value that specifies if the attribute is mutable. required A Boolean value that specifies if the attribute is required. caseExact A Boolean value that specifies if the String attribute is case sensitive. canonicalValues A collection of canonical values. When applicable Service Providers MUST specify the canonical types specified in the core schema specification; e.g.,"work","home". OPTIONAL. Mortimore, et al. [Page 22] =0C draft-scim-core-schema-01 July 2012 11. JSON Representation 11.1. Minimal User Representation The following is a non-normative example of the minimal required SCIM representation in JSON format. { "schemas": ["urn:scim:schemas:core:1.0"], "id": "2819c223-7f76-453a-919d-413861904646", "userName": "bjensen@example.com" } 11.2. Full User Representation The following is a non-normative example of the fully populated SCIM representation in JSON format. { "schemas": ["urn:scim:schemas:core:1.0"], "id": "2819c223-7f76-453a-919d-413861904646", "externalId": "701984", "userName": "bjensen@example.com", "name": { "formatted": "Ms. Barbara J Jensen III", "familyName": "Jensen", "givenName": "Barbara", "middleName": "Jane", "honorificPrefix": "Ms.", "honorificSuffix": "III" }, "displayName": "Babs Jensen", "nickName": "Babs", "profileUrl": "https://login.example.com/bjensen", "emails": [ { "value": "bjensen@example.com", "type": "work", "primary": true }, { "value": "babs@jensen.org", "type": "home" } ], "addresses": [ Mortimore, et al. [Page 23] =0C draft-scim-core-schema-01 July 2012 { "type": "work", "streetAddress": "100 Universal City Plaza", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "USA", "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA", "primary": true }, { "type": "home", "streetAddress": "456 Hollywood Blvd", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "USA", "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA" } ], "phoneNumbers": [ { "value": "555-555-5555", "type": "work" }, { "value": "555-555-4444", "type": "mobile" } ], "ims": [ { "value": "someaimhandle", "type": "aim" } ], "photos": [ { "value": = "https://photos.example.com/profilephoto/72930000000Ccne/F", "type": "photo" }, { "value": = "https://photos.example.com/profilephoto/72930000000Ccne/T", "type": "thumbnail" } ], "userType": "Employee", "title": "Tour Guide", Mortimore, et al. [Page 24] =0C draft-scim-core-schema-01 July 2012 "preferredLanguage":"en_US", "locale": "en_US", "timezone": "America/Los_Angeles", "active":true, "password":"t1meMa$heen", "groups": [ { "display": "Tour Guides", "value": "00300000005N2Y6AA" }, { "display": "Employees", "value": "00300000005N34H78" }, { "display": "US Employees", "value": "00300000005N98YT1" } ], "x509Certificates": [ { "value": = "MIIDQzCCAqygAwIBAgICEAAwDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMx = EzARBgNVBAgMCkNhbGlmb3JuaWExFDASBgNVBAoMC2V4YW1wbGUuY29tMRQwEgYD = VQQDDAtleGFtcGxlLmNvbTAeFw0xMTEwMjIwNjI0MzFaFw0xMjEwMDQwNjI0MzFa = MH8xCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRQwEgYDVQQKDAtl = eGFtcGxlLmNvbTEhMB8GA1UEAwwYTXMuIEJhcmJhcmEgSiBKZW5zZW4gSUlJMSIw = IAYJKoZIhvcNAQkBFhNiamVuc2VuQGV4YW1wbGUuY29tMIIBIjANBgkqhkiG9w0B = AQEFAAOCAQ8AMIIBCgKCAQEA7Kr+Dcds/JQ5GwejJFcBIP682X3xpjis56AK02bc = 1FLgzdLI8auoR+cC9/Vrh5t66HkQIOdA4unHh0AaZ4xL5PhVbXIPMB5vAPKpzz5i = PSi8xO8SL7I7SDhcBVJhqVqr3HgllEG6UClDdHO7nkLuwXq8HcISKkbT5WFTVfFZ = zidPl8HZ7DhXkZIRtJwBweq4bvm3hM1Os7UQH05ZS6cVDgweKNwdLLrT51ikSQG3 = DYrl+ft781UQRIqxgwqCfXEuDiinPh0kkvIi5jivVu1Z9QiwlYEdRbLJ4zJQBmDr = SGTMYn4lRc2HgHO4DqB/bnMVorHB0CC6AV1QoFK4GPe1LwIDAQABo3sweTAJBgNV = HRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZp = Y2F0ZTAdBgNVHQ4EFgQU8pD0U0vsZIsaA16lL8En8bx0F/gwHwYDVR0jBBgwFoAU = dGeKitcaF7gnzsNwDx708kqaVt0wDQYJKoZIhvcNAQEFBQADgYEAA81SsFnOdYJt = Ng5Tcq+/ByEDrBgnusx0jloUhByPMEVkoMZ3J7j1ZgI8rAbOkNngX8+pKfTiDz1R = C4+dx8oU6Za+4NJXUjlL5CvV6BEYb1+QAEJwitTVvxB/A67g42/vzgAtoRUeDov1 +GFiBZ+GNF/cAYKcMtGcrs2i97ZkJMo=3D" } ], "meta": { "created": "2010-01-23T04:56:22Z", "lastModified": "2011-05-13T04:42:34Z", "version": "W\/\"a330bc54f0671c9\"", "location": = "https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646" } } Mortimore, et al. [Page 25] =0C draft-scim-core-schema-01 July 2012 11.3. Enterprise User Extension Representation The following is a non-normative example of the fully populated User using the enterprise User extension in JSON format. { "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:enterprise:1.0"], "id": "2819c223-7f76-453a-919d-413861904646", "externalId": "701984", "userName": "bjensen@example.com", "name": { "formatted": "Ms. Barbara J Jensen III", "familyName": "Jensen", "givenName": "Barbara", "middleName": "Jane", "honorificPrefix": "Ms.", "honorificSuffix": "III" }, "displayName": "Babs Jensen", "nickName": "Babs", "profileUrl": "https://login.example.com/bjensen", "emails": [ { "value": "bjensen@example.com", "type": "work", "primary": true }, { "value": "babs@jensen.org", "type": "home" } ], "addresses": [ { "streetAddress": "100 Universal City Plaza", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "USA", "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA", "type": "work", "primary": true }, { "streetAddress": "456 Hollywood Blvd", "locality": "Hollywood", "region": "CA", Mortimore, et al. [Page 26] =0C draft-scim-core-schema-01 July 2012 "postalCode": "91608", "country": "USA", "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA", "type": "home" } ], "phoneNumbers": [ { "value": "555-555-5555", "type": "work" }, { "value": "555-555-4444", "type": "mobile" } ], "ims": [ { "value": "someaimhandle", "type": "aim" } ], "photos": [ { "value": = "https://photos.example.com/profilephoto/72930000000Ccne/F", "type": "photo" }, { "value": = "https://photos.example.com/profilephoto/72930000000Ccne/T", "type": "thumbnail" } ], "userType": "Employee", "title": "Tour Guide", "preferredLanguage":"en_US", "locale": "en_US", "timezone": "America/Los_Angeles", "active":true, "password":"t1meMa$heen", "groups": [ { "value": "e9e30dba-f08f-4109-8486-d5c6a331660a", "display": "Tour Guides" }, { "value": "fc348aa8-3835-40eb-a20b-c726e15c55b5", "display": "Employees" }, Mortimore, et al. [Page 27] =0C draft-scim-core-schema-01 July 2012 { "value": "71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7", "display": "US Employees" } ], "x509Certificates": [ { "value": = "MIIDQzCCAqygAwIBAgICEAAwDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMx = EzARBgNVBAgMCkNhbGlmb3JuaWExFDASBgNVBAoMC2V4YW1wbGUuY29tMRQwEgYD = VQQDDAtleGFtcGxlLmNvbTAeFw0xMTEwMjIwNjI0MzFaFw0xMjEwMDQwNjI0MzFa = MH8xCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRQwEgYDVQQKDAtl = eGFtcGxlLmNvbTEhMB8GA1UEAwwYTXMuIEJhcmJhcmEgSiBKZW5zZW4gSUlJMSIw = IAYJKoZIhvcNAQkBFhNiamVuc2VuQGV4YW1wbGUuY29tMIIBIjANBgkqhkiG9w0B = AQEFAAOCAQ8AMIIBCgKCAQEA7Kr+Dcds/JQ5GwejJFcBIP682X3xpjis56AK02bc = 1FLgzdLI8auoR+cC9/Vrh5t66HkQIOdA4unHh0AaZ4xL5PhVbXIPMB5vAPKpzz5i = PSi8xO8SL7I7SDhcBVJhqVqr3HgllEG6UClDdHO7nkLuwXq8HcISKkbT5WFTVfFZ = zidPl8HZ7DhXkZIRtJwBweq4bvm3hM1Os7UQH05ZS6cVDgweKNwdLLrT51ikSQG3 = DYrl+ft781UQRIqxgwqCfXEuDiinPh0kkvIi5jivVu1Z9QiwlYEdRbLJ4zJQBmDr = SGTMYn4lRc2HgHO4DqB/bnMVorHB0CC6AV1QoFK4GPe1LwIDAQABo3sweTAJBgNV = HRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZp = Y2F0ZTAdBgNVHQ4EFgQU8pD0U0vsZIsaA16lL8En8bx0F/gwHwYDVR0jBBgwFoAU = dGeKitcaF7gnzsNwDx708kqaVt0wDQYJKoZIhvcNAQEFBQADgYEAA81SsFnOdYJt = Ng5Tcq+/ByEDrBgnusx0jloUhByPMEVkoMZ3J7j1ZgI8rAbOkNngX8+pKfTiDz1R = C4+dx8oU6Za+4NJXUjlL5CvV6BEYb1+QAEJwitTVvxB/A67g42/vzgAtoRUeDov1 +GFiBZ+GNF/cAYKcMtGcrs2i97ZkJMo=3D" } ], "urn:scim:schemas:extension:enterprise:1.0": { "employeeNumber": "701984", "costCenter": "4130", "organization": "Universal Studios", "division": "Theme Park", "department": "Tour Operations", "manager": { "managerId": "26118915-6090-4610-87e4-49d8ca9f808d", "displayName": "John Smith" } }, "meta": { "created": "2010-01-23T04:56:22Z", "lastModified": "2011-05-13T04:42:34Z", "version": "W\/\"3694e05e9dff591\"", "location": = "https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646" } } Mortimore, et al. [Page 28] =0C draft-scim-core-schema-01 July 2012 11.4. Group Representation The following is a non-normative example of SCIM Group representation in JSON format. { "schemas": ["urn:scim:schemas:core:1.0"], "id": "e9e30dba-f08f-4109-8486-d5c6a331660a", "displayName": "Tour Guides", "members": [ { "value": "2819c223-7f76-453a-919d-413861904646", "display": "Babs Jensen" }, { "value": "902c246b-6245-4190-8e05-00816be7344a", "display": "Mandy Pepperidge" } ] } 11.5. Service Provider Configuration Representation The following is a non-normative example of the SCIM Service Provider Configuration representation in JSON format. Mortimore, et al. [Page 29] =0C draft-scim-core-schema-01 July 2012 { "schemas": ["urn:scim:schemas:core:1.0"], "documentationUrl":"http://example.com/help/scim.html", "patch": { "supported":true }, "bulk": { "supported":true, "maxOperations":1000, "maxPayloadSize":1048576 }, "filter": { "supported":true, "maxResults": 200 }, "changePassword" : { "supported":true }, "sort": { "supported":true }, "etag": { "supported":true }, "xmlDataFormat": { "supported":true }, "authenticationSchemes": [ { "name": "OAuth Bearer Token", "description": "Authentication Scheme using the OAuth Bearer Token = Standard", = "specUrl":"http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-01", "documentationUrl":"http://example.com/help/oauth.html", "type":"oauthbearertoken", "primary": true }, { "name": "HTTP Basic", "description": "Authentication Scheme using the Http Basic = Standard", "specUrl":"http://www.ietf.org/rfc/rfc2617.txt", "documentationUrl":"http://example.com/help/httpBasic.html", "type":"httpbasic" } ] } Mortimore, et al. [Page 30] =0C draft-scim-core-schema-01 July 2012 11.6. Resource Schema Representation The following is a normative example of the SCIM Resource Schema representation in JSON format. { "id":"urn:scim:schemas:core:1.0:User", "name":"User", "description":"Core User", "schema":"urn:scim:schemas:core:1.0", "endpoint":"/Users", "attributes":[ { "name":"id", "type":"string", "multiValued":false, "description":"Unique identifier for the SCIM resource as defined = by the Service Provider. Each representation of the resource MUST = include a non-empty id value. This identifier MUST be unique across the = Service Provider's entire set of resources. It MUST be a stable, = non-reassignable identifier that does not change when the same resource = is returned in subsequent requests. The value of the id attribute is = always issued by the Service Provider and MUST never be specified by the = Service Consumer. REQUIRED.", "schema":"urn:scim:schemas:core:1.0", "readOnly":true, "required":true, "caseExact":false }, { "name":"name", "type":"complex", "multiValued":false, "description":"The components of the user's real name. Providers = MAY return just the full name as a single string in the formatted = sub-attribute, or they MAY return just the individual component = attributes using the other sub-attributes, or they MAY return both. If = both variants are returned, they SHOULD be describing the same name, = with the formatted name indicating how the component attributes should = be combined.", "schema":"urn:scim:schemas:core:1.0", "readOnly":false, "required":false, "caseExact":false, "subAttributes":[ { "name":"formatted", "type":"string", "multiValued":false, "description":"The full name, including all middle names, = titles, and suffixes as appropriate, formatted for display (e.g. Ms. = Barbara J Jensen, III.)." , "readOnly":false, "required":false, "caseExact":false }, { "name":"familyName", "type":"string", "multiValued":false, "description":"The family name of the User, or Last Name in = most Western languages (e.g. Jensen given the full name Ms. Barbara J = Jensen, III.).", "readOnly":false, "required":false, Mortimore, et al. [Page 31] =0C draft-scim-core-schema-01 July 2012 "caseExact":false }, { "name":"givenName", "type":"string", "multiValued":false, "description":"The given name of the User, or First Name in = most Western languages (e.g. Barbara given the full name Ms. Barbara J = Jensen, III.).", "readOnly":false, "required":false, "caseExact":false }, { "name":"middleName", "type":"string", "multiValued":false, "description":"The middle name(s) of the User (e.g. Robert = given the full name Ms. Barbara J Jensen, III.).", "readOnly":false, "required":false, "caseExact":false }, { "name":"honorificPrefix", "type":"string", "multiValued":false, "description":"The honorific prefix(es) of the User, or Title = in most Western languages (e.g. Ms. given the full name Ms. Barbara J = Jensen, III.).", "readOnly":false, "required":false, "caseExact":false }, { "name":"honorificSuffix", "type":"string", "multiValued":false, "description":"The honorific suffix(es) of the User, or Suffix = in most Western languages (e.g. III. given the full name Ms. Barbara J = Jensen, III.).", "readOnly":false, "required":false, "caseExact":false } ] }, { "name":"emails", "type":"complex", "multiValued":true, "multiValuedAttributeChildName":"email", "description":"E-mail addresses for the user. The value SHOULD be = canonicalized by the Service Provider, e.g. bjensen@example.com instead = of bjensen@EXAMPLE.COM. Canonical Type values of work, home, and = other.", "schema":"urn:scim:schemas:core:1.0", "readOnly":false, Mortimore, et al. [Page 32] =0C draft-scim-core-schema-01 July 2012 "required":false, "caseExact":false, "subAttributes":[ { "name":"value", "type":"string", "multiValued":false, "description":"E-mail addresses for the user. The value = SHOULD be canonicalized by the Service Provider, e.g. = bjensen@example.com instead of bjensen@EXAMPLE.COM. Canonical Type = values of work, home, and other.", "readOnly":false, "required":false, "caseExact":false }, { "name":"display", "type":"string", "multiValued":false, "description":"A human readable name, primarily used for = display purposes. READ-ONLY.", "readOnly":true, "required":false, "caseExact":false }, { "name":"type", "type":"string", "multiValued":false, "description":"A label indicating the attribute's function; = e.g., 'work' or 'home'.", "readOnly":false, "required":false, "caseExact":false, "canonicalValues":["work","home","other"] }, { "name":"primary", "type":"boolean", "multiValued":false, "description":"A Boolean value indicating the 'primary' or = preferred attribute value for this attribute, e.g. the preferred mailing = address or primary e-mail address. The primary attribute value 'true' = MUST appear no more than once.", "readOnly":false, "required":false, "caseExact":false } }, { "name":"addresses", "type":"complex", "multiValued":true, "multiValuedAttributeChildName":"address", "description":"A physical mailing address for this User, as = described in (address Element). Canonical Type Values of work, home, and = other. The value attribute is a complex type with the following = sub-attributes.", "schema":"urn:scim:schemas:core:1.0", Mortimore, et al. [Page 33] =0C draft-scim-core-schema-01 July 2012 "readOnly":false, "required":false, "caseExact":false, "subAttributes":[ { "name":"formatted", "type":"string", "multiValued":false, "description":"The full mailing address, formatted for = display or use with a mailing label. This attribute MAY contain = newlines.", "readOnly":false, "required":false, "caseExact":false }, { "name":"streetAddress", "type":"string", "multiValued":false, "description":"The full street address component, which may = include house number, street name, PO BOX, and multi-line extended = street address information. This attribute MAY contain newlines.", "readOnly":false, "required":false, "caseExact":false }, { "name":"locality", "type":"string", "multiValued":false, "description":"The city or locality component.", "readOnly":false, "required":false, "caseExact":false }, { "name":"region", "type":"string", "multiValued":false, "description":"The state or region component.", "readOnly":false, "required":false, "caseExact":false }, { "name":"postalCode", "type":"string", "multiValued":false, "description":"The zipcode or postal code component.", "readOnly":false, "required":false, "caseExact":false Mortimore, et al. [Page 34] =0C draft-scim-core-schema-01 July 2012 }, { "name":"country", "type":"string", "multiValued":false, "description":"The country name component.", "readOnly":false, "required":false, "caseExact":false }, { "name":"type", "type":"string", "multiValued":false, "description":"A label indicating the attribute's function; = e.g., 'work' or 'home'.", "readOnly":false, "required":false, "caseExact":false, "canonicalValues":["work","home","other"] }, ] }, { "name":"employeeNumber", "type":"string", "multiValued":false, "description":"Numeric or alphanumeric identifier assigned to a = person, typically based on order of hire or association with an = organization.", "schema":"urn:scim:schemas:extension:enterprise:1.0", "readOnly":false, "required":false, "caseExact":false } ] } Mortimore, et al. [Page 35] =0C draft-scim-core-schema-01 July 2012 12. XML Representation 12.1. Minimal Representation The following is a non-normative example of the minimal required SCIM User representation in XML format. 2819c223-7f76-453a-919d-413861904646 bjensen@example.com 12.2. Full Representation The following is a non-normative example of the fully populated SCIM representation in XML format. 2819c223-7f76-453a-919d-413861904646 701984 bjensen@example.com Ms. Babs J Jensen III Jensen Barbara Jane Ms. III Babs Jensen Babs https://login.example.com/bjensen bjensen@example.com work true babs@jensen.com home
Mortimore, et al. [Page 36] =0C draft-scim-core-schema-01 July 2012 100 Universal City Plaza\nHollywood, CA 91608 = USA 100 Universal City Plaza Hollywood CA 91608 USA work true
456 Hollywood Blvd\nHollywood, CA 91608 USA 456 Hollywood Blvd San Francisco CA 91608 USA home
555-555-5555 work 555-555-4444 mobile someaimhandle aim = https://photos.example.com/profilephoto/72930000000Ccne/F photo = https://photos.example.com/profilephoto/72930000000Ccne/T thumbnail Employee Tour Guide en_US Mortimore, et al. [Page 37] =0C draft-scim-core-schema-01 July 2012 en_US America/Los_Angeles true t1meMa$heen e9e30dba-f08f-4109-8486-d5c6a331660a Tour Guides 6d1a1088-3a56-4371-8e3b-6d48d67493ec Employees 5fd998b9-d2bd-479c-991b-6790537608dc US Employees administrator delete users MIIDQzCCAqygAwIBAgICEAAwDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMx EzARBgNVBAgMCkNhbGlmb3JuaWExFDASBgNVBAoMC2V4YW1wbGUuY29tMRQwEgYD VQQDDAtleGFtcGxlLmNvbTAeFw0xMTEwMjIwNjI0MzFaFw0xMjEwMDQwNjI0MzFa MH8xCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRQwEgYDVQQKDAtl eGFtcGxlLmNvbTEhMB8GA1UEAwwYTXMuIEJhcmJhcmEgSiBKZW5zZW4gSUlJMSIw IAYJKoZIhvcNAQkBFhNiamVuc2VuQGV4YW1wbGUuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7Kr+Dcds/JQ5GwejJFcBIP682X3xpjis56AK02bc 1FLgzdLI8auoR+cC9/Vrh5t66HkQIOdA4unHh0AaZ4xL5PhVbXIPMB5vAPKpzz5i PSi8xO8SL7I7SDhcBVJhqVqr3HgllEG6UClDdHO7nkLuwXq8HcISKkbT5WFTVfFZ zidPl8HZ7DhXkZIRtJwBweq4bvm3hM1Os7UQH05ZS6cVDgweKNwdLLrT51ikSQG3 DYrl+ft781UQRIqxgwqCfXEuDiinPh0kkvIi5jivVu1Z9QiwlYEdRbLJ4zJQBmDr SGTMYn4lRc2HgHO4DqB/bnMVorHB0CC6AV1QoFK4GPe1LwIDAQABo3sweTAJBgNV HRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZp Y2F0ZTAdBgNVHQ4EFgQU8pD0U0vsZIsaA16lL8En8bx0F/gwHwYDVR0jBBgwFoAU dGeKitcaF7gnzsNwDx708kqaVt0wDQYJKoZIhvcNAQEFBQADgYEAA81SsFnOdYJt Ng5Tcq+/ByEDrBgnusx0jloUhByPMEVkoMZ3J7j1ZgI8rAbOkNngX8+pKfTiDz1R C4+dx8oU6Za+4NJXUjlL5CvV6BEYb1+QAEJwitTVvxB/A67g42/vzgAtoRUeDov1 Mortimore, et al. [Page 38] =0C draft-scim-core-schema-01 July 2012 +GFiBZ+GNF/cAYKcMtGcrs2i97ZkJMo=3D 2010-01-23T04:56:22Z 2011-05-13T04:42:34Z W/"a330bc54f0671c9" = https://example.com/v1/Users/2819c223-7f76-453a-919d-41386190464= 6 12.3. Enterprise User Extension Representation The following is a non-normative example of the fully populated User using the enterprise User extension in XML format. 2819c223-7f76-453a-919d-413861904646 701984 bjensen@example.com Ms. Babs J Jensen III Jensen Barbara Jane Ms. III Babs Jensen Babs https://login.example.com/bjensen Tour Guide Employee en_US en_US America/Los_Angeles true t1meMa$heen bjensen@example.com work true Mortimore, et al. [Page 39] =0C draft-scim-core-schema-01 July 2012 babs@jensen.com/value> home
100 Universal City Plaza\nHollywood, CA 91608 = USA 100 Universal City Plaza Hollywood CA 91608 USA work true
456 Hollywood Blvd\nHollywood, CA 91608 USA 456 Hollywood Blvd San Francisco CA 91608 USA
555-555-5555 work 555-555-4444 mobile someaimhandle aim = https://photos.example.com/profilephoto/72930000000Ccne/F photo> = https://photos.example.com/profilephoto/72930000000Ccne/T Mortimore, et al. [Page 40] =0C draft-scim-core-schema-01 July 2012 thumbnail> Tour Guides 00300000005N2Y6AA Employees 00300000005N34H78 US Employees 00300000005N98YT1 administrator delete users MIIDQzCCAqygAwIBAgICEAAwDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMx EzARBgNVBAgMCkNhbGlmb3JuaWExFDASBgNVBAoMC2V4YW1wbGUuY29tMRQwEgYD VQQDDAtleGFtcGxlLmNvbTAeFw0xMTEwMjIwNjI0MzFaFw0xMjEwMDQwNjI0MzFa MH8xCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRQwEgYDVQQKDAtl eGFtcGxlLmNvbTEhMB8GA1UEAwwYTXMuIEJhcmJhcmEgSiBKZW5zZW4gSUlJMSIw IAYJKoZIhvcNAQkBFhNiamVuc2VuQGV4YW1wbGUuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7Kr+Dcds/JQ5GwejJFcBIP682X3xpjis56AK02bc 1FLgzdLI8auoR+cC9/Vrh5t66HkQIOdA4unHh0AaZ4xL5PhVbXIPMB5vAPKpzz5i PSi8xO8SL7I7SDhcBVJhqVqr3HgllEG6UClDdHO7nkLuwXq8HcISKkbT5WFTVfFZ zidPl8HZ7DhXkZIRtJwBweq4bvm3hM1Os7UQH05ZS6cVDgweKNwdLLrT51ikSQG3 DYrl+ft781UQRIqxgwqCfXEuDiinPh0kkvIi5jivVu1Z9QiwlYEdRbLJ4zJQBmDr SGTMYn4lRc2HgHO4DqB/bnMVorHB0CC6AV1QoFK4GPe1LwIDAQABo3sweTAJBgNV HRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZp Y2F0ZTAdBgNVHQ4EFgQU8pD0U0vsZIsaA16lL8En8bx0F/gwHwYDVR0jBBgwFoAU dGeKitcaF7gnzsNwDx708kqaVt0wDQYJKoZIhvcNAQEFBQADgYEAA81SsFnOdYJt Ng5Tcq+/ByEDrBgnusx0jloUhByPMEVkoMZ3J7j1ZgI8rAbOkNngX8+pKfTiDz1R C4+dx8oU6Za+4NJXUjlL5CvV6BEYb1+QAEJwitTVvxB/A67g42/vzgAtoRUeDov1 +GFiBZ+GNF/cAYKcMtGcrs2i97ZkJMo=3D Mortimore, et al. [Page 41] =0C draft-scim-core-schema-01 July 2012 701984 = 902c246b-6245-4190-8e05-00816be7344a Mandy Pepperidge 4130 Universal Studios Theme Park Tour Operations 2010-01-23T04:56:22Z 2011-05-13T04:42:34Z W/"3694e05e9dff591" = https://example.com/v1/Users/2819c223-7f76-453a-919d-41386190464= 6 12.4. Group Representation The following is a non-normative example of a SCIM Group representation in XML format. 2819c223-7f76-453a-919d-413861904646 Tour Guides 902c246b-6245-4190-8e05-00816be7344a Babs Jensen 902c246b-6245-4190-8e05-00816be7344a Mandy Pepperidge Mortimore, et al. [Page 42] =0C draft-scim-core-schema-01 July 2012 13. Security Considerations The SCIM Core schema contains personally identifiable information as well as other sensitive data. Aside from prohibiting password values in a SCIM response this specification does not provide any means or guarantee of confidentiality. Mortimore, et al. [Page 43] =0C draft-scim-core-schema-01 July 2012 Appendix A. Contributors The SCIM Community would like to thank the following people for the work they've done in the research, formulation, drafting, editing, and support of this specification. Morteza Ansari (morteza.ansari@cisco.com) Sidharth Choudhury (schoudhury@salesforce.com) Samuel Erdtman (samuel@erdtman.se) Kelly Grizzle (kelly.grizzle@sailpoint.com) Chris Phillips (cjphillips@gmail.com) Erik Wahlstroem (erik.wahlstrom@nexussafe.com) Special thanks to Joeseph Smarr, who's excellent work on the Portable Contacts Specification [PortableContacts] provided a basis for the SCIM schema structure and text. Mortimore, et al. [Page 44] =0C draft-scim-core-schema-01 July 2012 14. Normative References [PortableContacts] Smarr, J., "Portable Contacts 1.0 Draft C - Schema Only", August 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [1] [2] [3] [4] [5] [6] [7] Mortimore, et al. [Page 45] =0C draft-scim-core-schema-01 July 2012 Authors' Addresses Chuck Mortimore (editor) Salesforce.com Email: cmortimore@salesforce.com Patrick Harding Ping Identity Email: pharding@pingidentity.com Paul Madsen Ping Identity Email: pmadsen@pingidentity.com Trey Drake UnboundID Email: trey.drake@unboundid.com Mortimore, et al. [Page 46] =0C --Apple-Mail=_19FFEAC6-A1D7-4DDC-818F-22E497C6FAE7 Content-Disposition: attachment; filename=draft-scim-api-01.xml Content-Type: application/xml; name="draft-scim-api-01.xml" Content-Transfer-Encoding: quoted-printable =0A=0A=0A=0A=20=20=20=20=0A=20=20=20=20=0A=20=20=20=20= =0A=20=20=20=20=0A=20=20= =20=20=0A=20=20=20=20=0A=20=20=20=20=20= =20=20=20System=20for=20= Cross-Domain=20Identity=20Management:Protocol=201.1=0A=0A=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= =20=20=20UnboundID=0A= =20=20=20=20=20=20=20=20=20=20=20=20
=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20trey.drake@unboundid.com=0A=20=20=20=20= =20=20=20=20=20=20=20=20
=0A=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=20=20SalesForce=0A=20=20=20=20=20=20=20=20= =20=20=20=20
=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= cmortimore@salesforce.com=0A=20=20=20=20=20=20=20=20=20=20= =20=20
=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= Cisco=0A=20=20=20=20=20=20= =20=20=20=20=20=20
=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20morteza.ansari@cisco.com=0A=20=20=20=20=20=20=20=20=20=20= =20=20
=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= SailPoint=0A=20=20=20= =20=20=20=20=20=20=20=20=20
=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20kelly.grizzle@sailpoint.com=0A=20=20=20=20=20=20= =20=20=20=20=20=20
=0A=20=20=20=20=20=20=20=20=0A=20=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20= =20Technology=20= Nexus=0A=20=20=20=20=20=20=20=20=20=20=20=20
=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= erik.wahlstrom@nexussafe.com=0A=20=20=20=20=20=20=20=20=20= =20=20=20
=0A=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20= =20=20=20=20=0A=20= =20=20=20=20=20=20=20SCIM=0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20The=20System=20for=20Cross-Domain=20= Identity=20Management=20(SCIM)=20specification=20is=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20designed=20to=20make=20managing=20user=20= identity=20in=20cloud=20based=20applications=20and=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20services=20easier.=20The=20specification=20= suite=20seeks=20to=20build=20upon=20experience=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20with=20existing=20schemas=20and=20deployments,=20= placing=20specific=20emphasis=20on=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20simplicity=20of=20development=20and=20integration,=20while=20= applying=20existing=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= authentication,=20authorization,=20and=20privacy=20models.=20It's=20= intent=20is=20to=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= reduce=20the=20cost=20and=20complexity=20of=20user=20management=20= operations=20by=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= providing=20a=20common=20user=20schema=20and=20extension=20model,=20as=20= well=20as=20binding=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= documents=20to=20provide=20patterns=20for=20exchanging=20this=20schema=20= using=20standard=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= protocols.=20In=20essence,=20make=20it=20fast,=20cheap,=20and=20easy=20= to=20move=20users=20in=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= to,=20out=20of,=20and=20around=20the=20cloud.=0A=20=20=20=20=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20= =0A=0A=0A=20=20=20=20=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20The=20SCIM=20= Protocol=20is=20an=20application-level,=20REST=20protocol=20for=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20provisioning=20and=20managing=20= identity=20data=20on=20the=20web.=20The=20protocol=20supports=20= creation,=20modification,=20retrieval,=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20and=20discovery=20of=20core=20identity=20Resources;=20= i.e.,=20Users=20and=20Groups,=20as=20well=20as=20custom=20Resource=20= extensions.=0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20This=20= document=20is=20intended=20as=20a=20guide=20to=20SCIM=20API=20usage=20= for=20both=20identity=20Service=20Providers=20and=20Consumers.=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20key=20words=20= "MUST",=20"MUST=20NOT",=20"REQUIRED",=20"SHALL",=20"SHALL=20NOT",=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20"SHOULD",=20= "SHOULD=20NOT",=20"RECOMMENDED",=20"MAY",=20and=20"OPTIONAL"=20in=20this=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20document=20= are=20to=20be=20interpreted=20as=20described=20in=20[RFC2119].=0A=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20These=20keywords=20= are=20capitalized=20when=20used=20to=20unambiguously=20specify=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20requirements=20of=20= the=20protocol=20or=20application=20features=20and=20behavior=20that=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20affect=20the=20= interoperability=20and=20security=20of=20implementations.=20When=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20these=20words=20= are=20not=20capitalized,=20they=20are=20meant=20in=20their=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20natural-language=20= sense.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20For=20purposes=20of=20readability=20= examples=20are=20not=20URL=20encoded.=20Implementers=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20MUST=20percent=20encode=20URLs=20= as=20described=20in=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20RFC3896=202.1=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20.=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20SCIM=20REST=20API=20is=20always=20relative=20to=20a=20Base=20= URL.=20The=20Base=20URL=20MUST=20NOT=20contain=20a=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20query=20string=20as=20= Consumers=20may=20append=20additional=20path=20information=20and=20query=20= parameters=20as=20part=20of=20forming=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20the=20request.=20Example:=20= https://example.com/scim/v1/=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=0A=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20The=20SCIM=20protocol=20does=20not=20= define=20a=20scheme=20for=20authentication=20and=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20authorization=20therefore=20implementers=20are=20= free=20to=20choose=20mechanisms=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20appropriate=20to=20their=20use=20cases.=20The=20choice=20of=20= authentication=20mechanism=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20will=20impact=20interoperability.=20It=20is=20RECOMMENDED=20that=20= clients=20be=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= implemented=20in=20such=20a=20way=20that=20new=20authentication=20= schemes=20can=20be=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= deployed.=20Implementers=20SHOULD=20support=20existing=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20authentication/authorization=20schemes.=20= In=20particular,=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20OAuth2=20Bearer=20= Token=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20is=20RECOMMENDED.=20Appropriate=20= security=20considerations=20of=20the=20selected=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20authentication=20and=20authorization=20schemes=20= SHOULD=20be=20taken.=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Because=20this=20protocol=20uses=20HTTP=20response=20status=20codes=20as=20= the=20primary=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20means=20= of=20reporting=20the=20result=20of=20a=20request,=20servers=20are=20= advised=20to=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20respond=20= to=20unauthorized=20or=20unauthenticated=20requests=20using=20the=20401=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20response=20code=20in=20= accordance=20with=20section=2010.4.2=20of=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20RFC2616=0A=20=20=20=20= =20=20=20=20=20=20=20=20.=0A=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20All=20examples=20assume=20OAuth2=20bearer=20= token;=20e.g.,=0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20The=20context=20of=20the=20request=20(i.e.=20the=20user=20= for=20whom=20data=20is=20being=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20requested)=20MUST=20be=20inferred=20by=20Service=20Providers.=0A=20= =20=20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20= =0A=0A=20=20=20=20=20=20=20=20= http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15=0A=0A=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= The=20SCIM=20protocol=20specifies=20well=20known=20endpoints=20and=20= HTTP=20methods=20for=20managing=20Resources=20defined=20in=20the=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20core=20schema;=20i.e.,=20User=20= and=20Group=20Resources=20correspond=20to=20/Users=20and=20/Groups=20= respectively.=20=20Service=20Providers=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20that=20support=20extended=20Resources=20SHOULD=20define=20= Resource=20endpoints=20using=20the=20established=20convention;=20= pluralize=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20the=20= Resource=20name=20defined=20in=20the=20extended=20schema=20by=20= appending=20an=20's'.=20=20Given=20there=20are=20cases=20where=20= Resource=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20pluralization=20= is=20ambiguous;=20e.g.,=20a=20Resource=20named=20'person'=20is=20= legitimately=20'persons'=20and=20'people'=20Consumers=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20SHOULD=20discover=20Resource=20endpoints=20= via=20the=20Schema=20Sub-Attribute=20'endpoint'.=0A=20=20=20=20=20=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Retrieves=20a=20complete=20or=20partial=20Resource.=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20Create=20new=20= Resource=20or=20bulk=20modify=20Resources.=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Modifies=20a=20Resource=20with=20a=20complete,=20= Consumer=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= specified=20Resource=20(replace).=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Modifies=20a=20Resource=20with=20a=20set=20of=20= Consumer=20specified=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20changes=20(partial=20update).=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Deletes=20a=20Resource.=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=0A= =0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20Resource=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20Endpoint=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20Operations=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Description=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20User=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= /Users=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20GET,=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20POST,=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20PUT,=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20PATCH,=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20DELETE=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20Retrieve/Add/Modify=20Users=0A=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20Group=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20/Groups=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20GET,=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20POST,=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20PUT,=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20PATCH,=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20DELETE=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20Retrieve/Add/Modify=20Groups=0A=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20Service=20Provider=20= Configuration=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= /ServiceProviderConfigs=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= GET=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20Retrieve=20the=20Service=20Provider's=20= Configuration=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Schema=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= /Schemas=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20GET=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20Retrieve=20a=20Resource's=20Schema=0A=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20Bulk=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20/Bulk=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20POST=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20Bulk=20modify=20Resources=0A=0A=20=20=20= =20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20All=20= requests=20to=20the=20Service=20Provider=20are=20made=20via=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20HTTP=20= operations=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20on=20a=20URL=20derived=20= from=20the=20Base=20URL.=20Responses=20are=20returned=20in=20the=20body=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20of=20the=20HTTP=20= response,=20formatted=20as=20JSON=20or=20XML,=20depending=20on=20what=20= is=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20requested.=20= Response=20and=20error=20codes=20SHOULD=20be=20transmitted=20via=20the=20= HTTP=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20status=20code=20= of=20the=20response=20(if=20possible),=20and=20SHOULD=20also=20be=20= specified=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20in=20the=20= body=20of=20the=20response.=0A=20=20=20=20=20=20=20=20=20=20=20=20=0A= =0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20To=20create=20new=20Resources,=20clients=20= send=20POST=20requests=20to=20the=20Resource=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20endpoint;=20i.e.,=20/Users=20or=20= /Groups.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20Successful=20Resource=20= creation=20is=20indicated=20with=20a=20201=20("Created")=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20response=20code.=20Upon=20= successful=20creation,=20the=20response=20body=20MUST=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20contain=20the=20newly=20= created=20Resource.=20Since=20the=20server=20is=20free=20to=20alter=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20and/or=20ignore=20= POSTed=20content,=20returning=20the=20full=20representation=20can=20be=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20useful=20to=20= the=20client,=20enabling=20it=20to=20correlate=20the=20client=20and=20= server=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= views=20of=20the=20new=20Resource.=0A=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20When=20a=20Resource=20is=20created,=20its=20= URI=20must=20be=20returned=20in=20the=20response=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20Location=20header.=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20If=20the=20Service=20Provider=20determines=20creation=20of=20the=20= requested=20Resource=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20conflicts=20with=20existing=20resources;=20e.g.,=20a=20User=20= Resource=20with=20a=20duplicate=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20userName,=20the=20Service=20Provider=20MUST=20= return=20a=20409=20error=20and=20SHOULD=20indicate=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20the=20conflicting=20attribute(s)=20= in=20the=20body=20of=20the=20response.=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Below,=20the=20client=20sends=20a=20POST=20request=20containing=20a=20= User=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20= server=20signals=20a=20successful=20creation=20with=20a=20status=20code=20= of=20201.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= The=20response=20includes=20a=20Location=20header=20indicating=20the=20= User=20URI,=20and=20a=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20representation=20of=20that=20User=20in=20the=20body=20of=20the=20= response.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Users=20and=20Group=20= Resources=20are=20retrieved=20via=20opaque,=20unique=20URLs=20or=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20via=20Query.=20= Service=20Providers=20MAY=20choose=20to=20respond=20with=20a=20sub-set=20= of=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Resource=20attributes,=20though=20MUST=20minimally=20return=20the=20= Resource=20id=20and=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20meta=20attributes.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20To=20retrieve=20a=20known=20Resource,=20clients=20send=20GET=20= requests=20to=20the=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20Resource=20endpoint;=20e.g.,=20/Users/{id}=20or=20= /Groups/{id}.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= If=20the=20Resource=20exists=20the=20server=20responds=20with=20a=20= status=20code=20of=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20200=20and=20includes=20the=20result=20in=20the=20body=20= of=20the=20response.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20The=20below=20example=20retrieves=20a=20single=20User=20via=20= the=20/Users=20endpoint.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20The=20server=20responds=20with:=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20SCIM=20defines=20a=20standard=20= set=20of=20operations=20that=20can=20be=20used=20to=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20filter,=20sort,=20and=20= paginate=20response=20results.=20The=20operations=20are=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20specified=20by=20= adding=20query=20parameters=20to=20the=20Resource's=20endpoint.=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Service=20= Providers=20MAY=20support=20additional=20query=20parameters=20not=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= specified=20here,=20and=20Providers=20SHOULD=20ignore=20any=20query=20= parameters=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20they=20don't=20recognize.=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20The=20below=20example=20returns=20the=20= userName=20for=20all=20Users:=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20Filtering=20is=20OPTIONAL.=20= Consumers=20may=20request=20a=20subset=20of=20Resources=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20by=20= specifying=20the=20'filter'=20URL=20query=20parameter=20containing=20a=20= filter=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20expression.=20When=20specified=20only=20those=20= Resources=20matching=20the=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20filter=20expression=20SHALL=20be=20= returned.=20The=20expression=20language=20that=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20is=20used=20= in=20the=20filter=20parameter=20supports=20references=20to=20attributes=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20and=20literals.=20The=20literal=20values=20can=20be=20strings=20= enclosed=20in=20double=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20quotes,=20numbers,=20date=20times=20= enclosed=20in=20double=20quotes,=20and=20Boolean=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20values;=20= i.e.,=20true=20or=20false.=20=20String=20literals=20MUST=20be=20valid=20= JSON=20= strings.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20The=20attribute=20name=20and=20= attribute=20operator=20are=20case=20insensitive.=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20For=20= example,=20the=20following=20two=20expressions=20will=20evaluate=20to=20= the=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20same=20logical=20value:=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20filter=20parameter=20= MUST=20contain=20at=20least=20one=20valid=20Boolean=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= expression.=20Each=20expression=20MUST=20contain=20an=20attribute=20name=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20followed=20by=20an=20attribute=20operator=20and=20optional=20= value.=20Multiple=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20expressions=20MAY=20be=20combined=20using=20= the=20two=20logical=20operators.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Furthermore=20expressions=20= can=20be=20grouped=20together=20using=20"()".=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20= operators=20supported=20in=20the=20expression=20are=20listed=20in=20the=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20following=20table.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Operator=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Description=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Behavior=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20eq=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= equal=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20The=20attribute=20and=20operator=20values=20= must=20be=20identical=20for=20a=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20match.=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20co=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20contains=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= The=20entire=20operator=20value=20must=20be=20a=20substring=20of=20= the=20attribute=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20value=20for=20a=20match.=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20sw=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20starts=20with=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= The=20entire=20operator=20value=20must=20be=20a=20substring=20of=20= the=20attribute=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20value,=20starting=20at=20the=20= beginning=20of=20the=20attribute=20value.=20This=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= criterion=20is=20satisfied=20if=20the=20two=20strings=20are=20identical.=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20pr=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20present=20(has=20= value)=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20If=20the=20attribute=20has=20a=20non-empty=20= value,=20or=20if=20it=20contains=20a=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20non-empty=20= node=20for=20complex=20attributes=20there=20is=20a=20match.=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20gt=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20greater=20than=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= If=20the=20attribute=20value=20is=20greater=20than=20operator=20= value,=20there=20is=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20a=20match.=20The=20actual=20= comparison=20is=20dependent=20on=20the=20attribute=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= type.=20For=20string=20attribute=20types,=20this=20is=20a=20= lexicographical=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20comparison=20and=20for=20DateTime=20= types,=20it=20is=20a=20chronological=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20comparison.=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20ge=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20greater=20than=20= or=20equal=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20If=20the=20attribute=20value=20is=20= greater=20than=20or=20equal=20to=20the=20operator=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= value,=20there=20is=20a=20match.=20The=20actual=20comparison=20is=20= dependent=20on=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20the=20attribute=20type.=20For=20= string=20attribute=20types,=20this=20is=20a=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= lexicographical=20comparison=20and=20for=20DateTime=20types,=20it=20is=20= a=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20chronological=20comparison.=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20lt=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20less=20than=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20If=20= the=20attribute=20value=20is=20less=20than=20operator=20value,=20there=20= is=20a=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20match.=20The=20actual=20comparison=20is=20= dependent=20on=20the=20attribute=20type.=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20For=20= string=20attribute=20types,=20this=20is=20a=20lexicographical=20= comparison=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20and=20for=20DateTime=20types,=20it=20= is=20a=20chronological=20comparison.=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= le=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20less=20than=20or=20equal=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20If=20= the=20attribute=20value=20is=20less=20than=20or=20equal=20to=20the=20= operator=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20value,=20there=20is=20a=20match.=20The=20= actual=20comparison=20is=20dependent=20on=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20the=20= attribute=20type.=20For=20string=20attribute=20types,=20this=20is=20a=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20lexicographical=20comparison=20and=20for=20DateTime=20= types,=20it=20is=20a=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20chronological=20comparison.=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Operator=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Description=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Behavior=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20and=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Logical=20And=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20The=20filter=20is=20only=20a=20match=20= if=20both=20expressions=20evaluate=20to=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20true.=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20or=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Logical=20or=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20The=20filter=20is=20a=20match=20if=20either=20expression=20= evaluates=20to=20true.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Operator=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Description=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Behavior=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20()=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Precedence=20grouping=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20Boolean=20expressions=20may=20= be=20grouped=20using=20parentheses=20to=20change=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= the=20standard=20order=20of=20operations;=20i.e.,=20evaluate=20OR=20= logical=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20operators=20before=20logical=20AND=20= operators.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Filters=20= MUST=20be=20evaluated=20using=20standard=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20order=20of=20operations=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= .=20=20Attribute=20operators=20have=20the=20highest=20precedence,=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20followed=20by=20the=20grouping=20operator=20(i.e,=20= parentheses),=20followed=20by=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20the=20logical=20AND=20= operator,=20followed=20by=20the=20logical=20OR=20operator.=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20If=20the=20specified=20attribute=20in=20a=20filter=20expression=20= is=20a=20multi-valued=20attribute,=20the=20Resource=20MUST=20match=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20if=20any=20of=20the=20instances=20of=20the=20given=20attribute=20= match=20the=20specified=20criterion;=20e.g.=20if=20a=20User=20has=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20multiple=20emails=20values,=20only=20one=20has=20to=20match=20for=20= the=20entire=20User=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20to=20match.=20For=20complex=20= attributes,=20a=20fully=20qualified=20Sub-Attribute=20MUST=20be=20= specified=20using=20standard=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20attribute=20= notation.=20=20For=20example,=20to=20filter=20by=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= userName=20the=20parameter=20value=20is=20userName=20and=20to=20filter=20= by=20first=20name,=20the=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20parameter=20value=20is=20= name.givenName.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20Providers=20MAY=20support=20additional=20= filter=20operations=20if=20they=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20choose.=20Providers=20MUST=20= decline=20to=20filter=20results=20if=20the=20specified=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20filter=20= operation=20is=20not=20recognized=20and=20return=20a=20HTTP=20400=20= error=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20with=20an=20appropriate=20human=20readable=20response.=20= For=20example,=20if=20a=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20Consumer=20specified=20an=20= unsupported=20operator=20named=20'regex'=20the=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Service=20= Provider=20should=20specify=20an=20error=20response=20description=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20identifying=20the=20Consumer=20error;=20e.g.,=20'The=20operator=20= 'regex'=20is=20not=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20supported.'=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20String=20= type=20attributes=20are=20case=20insensitive=20by=20default=20unless=20= the=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20attribute=20type=20is=20defined=20as=20a=20caseExact=20= string.=20Attribute=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20operators=20'eq',=20'co',=20and=20'sw'=20= MUST=20perform=20caseIgnore=20matching=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20for=20all=20string=20= attributes=20unless=20the=20attribute=20is=20defined=20as=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= caseExact.=20By=20default=20all=20string=20attributes=20are=20= caseIgnore.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20Examples:=0A=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Sort=20is=20OPTIONAL.=20= Sorting=20allows=20Consumers=20to=20specify=20the=20order=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20in=20= which=20Resources=20are=20returned=20by=20specifying=20a=20combination=20= of=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20sortBy=20and=20sortOrder=20URL=20parameters.=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20The=20sortBy=20parameter=20specifies=20the=20attribute=20whose=20= value=20SHALL=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20be=20used=20to=20order=20the=20= returned=20responses.=20If=20the=20sortBy=20attribute=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20corresponds=20to=20a=20Singular=20Attribute,=20Resources=20are=20= sorted=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20according=20to=20that=20attribute's=20= value;=20if=20it's=20a=20Multi-valued=20Attribute,=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Resources=20are=20sorted=20by=20the=20value=20of=20the=20primary=20= attribute,=20if=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20any,=20or=20else=20the=20first=20= value=20in=20the=20list,=20if=20any.=20If=20the=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= attribute=20is=20complex=20the=20attribute=20name=20must=20be=20a=20path=20= to=20a=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20Sub-Attribute=20in=20standard=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20attribute=20notation=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= ;=20e.g.,=20sortBy=3Dname.givenName.=20For=20all=20attribute=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20types,=20if=20there=20is=20no=20data=20for=20the=20specified=20= sortBy=20value=20they=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20are=20sorted=20via=20the=20= 'sortOrder'=20parameter;=20i.e.,=20they=20are=20ordered=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20last=20if=20ascending=20and=20first=20if=20descending.=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= The=20order=20in=20which=20the=20sortBy=20parameter=20is=20applied.=20= Allowed=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20values=20are=20"ascending"=20and=20= "descending".=20If=20a=20value=20for=20sortBy=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20is=20= provided=20and=20no=20sortOrder=20is=20specified,=20the=20sortOrder=20= SHALL=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20default=20to=20ascending.=20=20String=20= type=20attributes=20are=20case=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20insensitive=20by=20= default=20unless=20the=20attribute=20type=20is=20defined=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20as=20a=20caseExact=20string.=20sortOrder=20MUST=20sort=20according=20= to=20the=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20attribute=20type;=20i.e.,=20for=20= caseIgnore=20attributes,=20sort=20the=20result=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= using=20case=20insensitive,=20Unicode=20alphabetic=20sort=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20order,=20with=20no=20specific=20locale=20implied=20and=20for=20= caseExact=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20attribute=20types,=20sort=20the=20= result=20using=20case=20sensitive,=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Unicode=20= alphabetic=20sort=20order.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20Pagination=20parameters=20can=20be=20used=20= together=20to=20"page=20through"=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20large=20numbers=20of=20= Resources=20so=20as=20not=20to=20overwhelm=20the=20Consumer=20or=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20Service=20Provider.=20Pagination=20is=20not=20session=20based=20hence=20= Consumers=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20SHOULD=20never=20assume=20repeatable=20results.=20= For=20example,=20a=20request=20for=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20a=20list=20of=2010=20= Resources=20beginning=20with=20a=20startIndex=20of=201=20may=20return=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20different=20results=20when=20repeated=20as=20a=20Resource=20in=20= the=20original=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20result=20could=20be=20deleted=20or=20new=20= ones=20could=20be=20added=20in-between=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20requests.=20= Pagination=20parameters=20and=20general=20behavior=20are=20derived=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20from=20the=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20OpenSearch=20Protocol=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20.=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= The=20following=20table=20describes=20the=20URL=20pagination=20= parameters.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Parameter=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Description=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Default=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20startIndex=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= The=201-based=20index=20of=20the=20first=20search=20result.=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=201=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20count=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Non-negative=20Integer.=20Specifies=20the=20desired=20maximum=20= number=20of=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20search=20results=20per=20page;=20= e.g.,=2010.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20None.=20When=20specified=20= the=20Service=20Provider=20MUST=20not=20return=20more=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20results=20than=20specified=20though=20MAY=20return=20fewer=20results.=20= If=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20unspecified,=20the=20maximum=20number=20of=20= results=20is=20set=20by=20the=20Service=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Provider.=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20The=20following=20table=20describes=20= the=20query=20response=20pagination=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20attributes=20specified=20= by=20the=20Service=20Provider.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Element=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20Description=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20itemsPerPage=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20Non-negative=20Integer.=20Specifies=20the=20number=20of=20= search=20results=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20returned=20in=20a=20query=20= response=20page;=20e.g.,=2010.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= totalResults=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20Non-negative=20Integer.=20Specifies=20= the=20total=20number=20of=20results=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20matching=20= the=20Consumer=20query;=20e.g.,=201000.=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= startIndex=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20The=201-based=20index=20of=20the=20= first=20result=20in=20the=20current=20set=20of=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= search=20results;=20e.g.,=201.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20For=20example,=20to=20retrieve=20the=20first=2010=20Users=20set=20the=20= startIndex=20to=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=201=20and=20the=20count=20to=2010.=0A=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20Given=20the=20example=20above,=20to=20continue=20= paging=20set=20the=20startIndex=20to=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=2011=20and=20re-fetch;=20= i.e.,=20/Users?startIndex=3D11&count=3D10=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20Resources=20can=20be=20modified=20in=20= whole=20or=20in=20part=20via=20PUT=20or=20PATCH,=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20respectively.=20Implementers=20MUST=20= support=20PUT=20as=20specified=20in=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= RFC2616=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20.=20= Resources=20such=20as=20Groups=20may=20be=20very=20large=20hence=20= implementers=20SHOULD=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20support=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20PATCH=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20to=20enable=20partial=20= resource=20modifications.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20PUT=20performs=20a=20full=20update.=20Consumers=20must=20= retrieve=20the=20entire=20Resource=20=0A=09=09=09and=20PUT=20the=20= desired=20modifications=20as=20the=20operation=20overwrites=20all=20= previously=20stored=20data=20=0A=09=09=09with=20the=20exception=20of=20= the=20password=20attribute.=20If=20the=20password=20attribute=20=0A=09=09= =09of=20the=20User=20resource=20is=20unspecified,=20it=20should=20be=20= left=20in-tact.=0A=09=09=09Since=20this=20performs=20a=20full=20update,=20= Consumers=20MAY=20send=20read-only=20attributes=20=0A=09=09=09of=20the=20= retrieved=20resource=20and=20Service=20Provider=20MUST=20ignore=20any=20= read-only=20attributes=20=0A=09=09=09that=20are=20present=20in=20the=20= payload=20of=20a=20PUT=20request.=20Unless=20otherwise=20specified=20a=20= successful=20=0A=09=09=09PUT=20operation=20returns=20a=20200=20OK=20= response=20code=20and=20the=20entire=20Resource=20within=20the=20=0A=09=09= =09response=20body,=20enabling=20the=20Consumer=20to=20correlate=20the=20= Consumer's=20and=20Provider's=20views=20of=20the=20updated=20Resource.=0A= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Example:=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20The=20service=20responds=20with=20the=20entire,=20= updated=20User=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20PATCH=20is=20OPTIONAL.=20= =20PATCH=20enables=20consumers=20to=20send=20only=20those=20attributes=20= requiring=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20modification,=20reducing=20network=20and=20processing=20= overhead.=20Attributes=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20may=20be=20deleted,=20replaced,=20merged,=20or=20= added=20in=20a=20single=20request.=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20The=20body=20of=20a=20PATCH=20request=20MUST=20= contain=20a=20partial=20Resource=20with=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20the=20desired=20modifications.=20=20= The=20server=20MUST=20return=20either=20a=20200=20OK=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20response=20code=20= and=20the=20entire=20Resource=20(subject=20to=20the=20"attributes"=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20query=20= parameter=20-=20see=20Additional=20Retrieval=20Query=20= Parameters)=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20within=20the=20response=20body,=20or=20a=20204=20No=20= Content=20response=20code=20and=20the=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20appropriate=20response=20headers=20= for=20a=20successful=20PATCH=20request.=20=20The=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20server=20MUST=20return=20= a=20200=20OK=20if=20the=20"attributes"=20parameter=20is=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20specified=20on=20= the=20request.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= The=20server=20MUST=20process=20a=20PATCH=20request=20by=20first=20= removing=20any=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20attributes=20specified=20in=20the=20meta.attributes=20= Sub-Attribute=20(if=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20present)=20and=20then=20merging=20the=20attributes=20= in=20the=20PATCH=20request=20body=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20into=20the=20Resource.=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20meta.attributes=20= Sub-Attribute=20MAY=20contain=20a=20list=20of=20attributes=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20to=20be=20= removed=20from=20the=20Resource.=20=20If=20the=20PATCH=20request=20body=20= contains=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20an=20attribute=20that=20is=20present=20in=20the=20= meta.attributes=20list,=20the=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20attribute=20on=20the=20Resource=20is=20= replaced=20with=20the=20value=20from=20the=20PATCH=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20body.=20=20If=20the=20= attribute=20is=20complex=20the=20attribute=20name=20must=20be=20a=20path=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= to=20a=20Sub-Attribute=20in=20standard=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20attribute=20= notation;=20e.g.,=20name.givenName.=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20Attributes=20that=20exist=20in=20the=20= PATCH=20request=20body=20but=20not=20in=20the=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20meta.attributes=20= Sub-Attribute=20will=20be=20either=20be=20updated=20or=20added=20to=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20the=20= Resource=20according=20to=20the=20following=20rules.=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Singular=20attributes=20= in=20the=20PATCH=20request=20body=20replace=20the=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20attribute=20= on=20the=20Resource.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20Complex=20Sub-Attribute=20values=20in=20the=20PATCH=20request=20= body=20are=20merged=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20into=20the=20complex=20attribute=20on=20= the=20Resource.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20An=20attribute=20value=20in=20the=20PATCH=20request=20body=20is=20= added=20to=20the=20value=20collection=20if=20the=20value=20does=20not=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20exist=20and=20merged=20if=20a=20matching=20value=20is=20present.=20= Values=20are=20matched=20by=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20comparing=20the=20value=20= Sub-Attribute=20from=20the=20PATCH=20request=20body=20to=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20the=20= value=20Sub-Attribute=20of=20the=20Resource.=20=20Attributes=20that=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20do=20not=20have=20a=20value=20Sub-Attribute;=20e.g.,=20addresses,=20= or=20do=20not=20have=20unique=20value=20Sub-Attributes=20cannot=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= be=20matched=20and=20must=20instead=20be=20deleted=20then=20added.=0A=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20Specific=20values=20can=20be=20removed=20from=20a=20Resource=20by=20= adding=20an=20"operation"=20Sub-Attribute=20with=20the=20value=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= "delete"=20to=20the=20attribute=20in=20the=20PATCH=20request=20body.=20=20= As=20with=20adding/updating=20attribute=20value=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20collections,=20= the=20value=20to=20delete=20is=20determined=20by=20comparing=20the=20= value=20Sub-Attribute=20from=20the=20PATCH=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20request=20body=20= to=20the=20value=20Sub-Attribute=20of=20the=20Resource.=20=20Attributes=20= that=20do=20not=20have=20a=20value=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Sub-Attribute=20or=20= that=20have=20a=20non-unique=20value=20Sub-Attribute=20are=20matched=20= by=20comparing=20all=20Sub-Attribute=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20values=20from=20the=20= PATCH=20request=20body=20to=20the=20Sub-Attribute=20values=20of=20the=20= Resource.=20A=20delete=20operation=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20is=20ignored=20if=20the=20= attribute's=20name=20is=20in=20the=20meta.attributes=20list.=20=20If=20= the=20requested=20value=20to=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20delete=20does=20not=20match=20= a=20unique=20value=20on=20the=20Resource=20the=20server=20MAY=20return=20= a=20HTTP=20400=20error.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=0A=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20The=20following=20example=20shows=20how=20to=20= add=20a=20member=20to=20a=20group:=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20The=20"display"=20Sub-Attribute=20= in=20this=20request=20is=20optional=20since=20the=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20value=20attribute=20= uniquely=20identifies=20the=20user=20to=20be=20added.=20=20If=20the=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= user=20was=20already=20a=20member=20of=20this=20group,=20no=20changes=20= should=20be=20made=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20to=20the=20Resource=20and=20a=20success=20response=20= should=20be=20returned.=20=20The=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20server=20responds=20with=20either=20the=20= entire=20updated=20Group=20or=20no=20response=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20body:=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20The=20following=20example=20shows=20= how=20to=20remove=20a=20member=20from=20a=20group.=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20As=20with=20the=20= previous=20example,=20the=20"display"=20Sub-Attribute=20is=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20optional.=20=20= If=20the=20user=20was=20not=20a=20member=20of=20this=20group,=20no=20= changes=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20should=20be=20made=20to=20the=20Resource=20and=20a=20success=20= response=20should=20be=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20returned.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20Note=20that=20server=20responses=20have=20been=20= omitted=20for=20the=20rest=20of=20the=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20PATCH=20examples.=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20The=20following=20example=20shows=20how=20to=20remove=20all=20= members=20from=20a=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20group:=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20= following=20example=20shows=20how=20to=20replace=20all=20of=20the=20= members=20of=20a=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20group=20with=20a=20different=20members=20list:=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20following=20= example=20shows=20how=20to=20add=20a=20member=20to=20and=20remove=20a=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= member=20from=20a=20Group=20in=20a=20single=20request:=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20The=20following=20example=20shows=20= how=20to=20change=20a=20User's=20primary=20email.=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20If=20the=20User=20= already=20has=20the=20email=20address,=20it=20is=20made=20the=20primary=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= address=20and=20the=20current=20primary=20address=20(if=20present)=20is=20= made=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20non-primary.=20=20If=20the=20User=20does=20not=20already=20have=20= the=20email=20address,=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20it=20is=20added=20and=20made=20the=20primary=20= address.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20The=20following=20example=20shows=20how=20to=20change=20= a=20User's=20address.=20=20Since=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20address=20does=20not=20have=20a=20value=20= Sub-Attribute,=20the=20existing=20address=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20must=20be=20removed=20and=20= the=20modified=20address=20added.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20The=20following=20example=20shows=20how=20to=20change=20= a=20User's=20nickname:=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20The=20following=20example=20shows=20how=20to=20remove=20a=20User's=20= nickname:=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20following=20= example=20shows=20how=20to=20change=20a=20User's=20familyName.=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20This=20= only=20updates=20the=20familyName=20and=20formatted=20on=20the=20"name"=20= complex=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20attribute.=20Any=20other=20name=20Sub-Attributes=20on=20the=20= Resource=20remain=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20unchanged.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20The=20following=20example=20shows=20how=20to=20remove=20a=20= complex=20Sub-Attribute=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20and=20an=20extended=20schema=20attribute=20from=20= a=20User.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Consumers=20request=20= Resource=20removal=20via=20DELETE.=20Service=20Providers=20MAY=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20choose=20not=20to=20= permanently=20delete=20the=20Resource,=20but=20MUST=20return=20a=20404=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20error=20code=20= for=20all=20operations=20associated=20with=20the=20previously=20deleted=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Id.=20= Service=20Providers=20MUST=20also=20omit=20the=20Resource=20from=20= future=20query=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20results.=20In=20addition=20the=20Service=20Provider=20MUST=20not=20= consider=20the=20deleted=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20resource=20in=20conflict=20calculation.=20For=20example=20if=20= a=20User=20resource=20is=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20deleted,=20a=20CREATE=20request=20for=20a=20User=20resource=20= with=20the=20same=20userName=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20as=20the=20previously=20deleted=20resource=20should=20= not=20fail=20with=20a=20409=20error=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20due=20to=20userName=20conflict.=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20Server=20Response:=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=0A=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20Example:=20Consumer=20attempt=20to=20retrieve=20the=20previously=20= deleted=20User=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20Server=20Response:=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20Bulk=20is=20OPTIONAL.=20The=20bulk=20operation=20enables=20= Consumers=20to=20send=20a=20potentially=20large=20collection=20of=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Resource=20= operations=20in=20a=20single=20request.=20=20The=20body=20of=20a=20a=20= bulk=20operation=20contains=20a=20set=20of=20HTTP=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20Resource=20operations=20using=20= one=20of=20the=20API=20supported=20HTTP=20methods;=20i.e.,=20POST,=20= PUT,=20PATCH=20or=20DELETE.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20following=20= Singular=20Attribute=20is=20defined=20in=20addition=20to=20the=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20common=20attributes=20= defined=20in=20SCIM=20core=20schema.=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20An=20= Integer=20specifying=20the=20number=20of=20errors=20that=20the=20Service=20= Provider=20will=20accept=20before=20the=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20operation=20is=20= terminated=20and=20an=20error=20response=20is=20returned.=20OPTIONAL.=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20The=20following=20Complex=20= Multi-valued=20Attribute=20is=20defined=20in=20addition=20to=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20the=20common=20= attributes=20defined=20in=20core=20schema.=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Defines=20= operations=20within=20a=20bulk=20job.=20Each=20operation=20corresponds=20= to=20a=20single=20HTTP=20request=20against=20a=20Resource=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= endpoint.=20REQUIRED.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= The=20HTTP=20method=20of=20the=20current=20operation.=20Possible=20= values=20are=20POST,=20PUT,=20PATCH=20or=20DELETE.=20REQUIRED.=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20The=20transient=20identifier=20of=20a=20= newly=20created=20Resource,=20unique=20within=20a=20bulk=20request=20and=20= created=20by=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20the=20Consumer.=20The=20= bulkId=20serves=20as=20a=20surrogate=20Resource=20id=20enabling=20= Consumers=20to=20uniquely=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20identify=20= newly=20created=20Resources=20in=20the=20Response=20and=20cross=20= reference=20new=20Resources=20in=20and=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= across=20operations=20within=20a=20bulk=20request.=20=20REQUIRED=20when=20= method=20is=20POST.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20= current=20Resource=20version.=20Version=20is=20REQUIRED=20if=20the=20= Service=20Provider=20supports=20ETags=20and=20the=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20method=20is=20PUT,=20DELETE,=20or=20PATCH.=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20The=20Resource's=20relative=20path.=20=20If=20the=20= method=20is=20POST=20the=20value=20must=20specify=20a=20Resource=20type=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20endpoint;=20e.g.,=20/Users=20or=20= /Groups=20whereas=20all=20other=20method=20values=20must=20specify=20the=20= path=20to=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20a=20specific=20Resource;=20= e.g.,=20/Users/2819c223-7f76-453a-919d-413861904646.=20=20REQUIRED=20in=20= a=20request.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20Resource=20= data=20as=20it=20would=20appear=20for=20a=20single=20POST,=20PUT=20or=20= PATCH=20Resource=20operation.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= REQUIRED=20in=20a=20request=20when=20method=20is=20POST,=20PUT=20and=20= PATCH.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20= Resource=20endpoint=20URL.=20REQUIRED=20in=20a=20response,=20except=20in=20= the=20event=20of=20a=20POST=20failure.=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20A=20complex=20type=20that=20contains=20information=20about=20the=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20success=20or=20failure=20of=20one=20= operation=20within=20the=20bulk=20job.=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= REQUIRED=20in=20a=20response.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= The=20HTTP=20response=20code=20that=20would=20have=20been=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20returned=20if=20a=20a=20single=20HTTP=20= request=20would=20have=20been=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20used.=20REQUIRED.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20A=20human=20readable=20error=20message.=20= REQUIRED=20when=20an=20error=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20occurred.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20If=20a=20= bulk=20job=20is=20processed=20successfully=20the=20HTTP=20response=20= code=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20200=20= OK=20MUST=20be=20returned,=20otherwise=20an=20appropriate=20HTTP=20error=20= code=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20MUST=20= be=20returned.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20The=20Service=20Provider=20MUST=20= continue=20performing=20as=20many=20changes=20as=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20possible=20and=20disregard=20partial=20= failures.=20The=20Consumer=20MAY=20override=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20this=20behavior=20by=20specifying=20a=20= value=20for=20failOnErrors=20attribute.=20The=20failOnErrors=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20attribute=20defines=20= the=20number=20of=20errors=20that=20the=20Service=20Provider=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20should=20accept=20before=20= failing=20the=20remaining=20operations=20returning=20the=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20response.=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20To=20be=20able=20to=20reference=20a=20newly=20created=20Resource=20= the=20attribute=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20bulkId=20MUST=20be=20specified=20when=20creating=20new=20Resources.=20= The=20bulkId=20is=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20defined=20by=20the=20Consumer=20as=20a=20surrogate=20identifier=20= in=20a=20POST=20operation.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20The=20Service=20Provider=20MUST=20return=20the=20same=20= bulkId=20together=20with=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20the=20newly=20created=20Resource.=20The=20bulkId=20can=20= then=20be=20used=20by=20the=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20Consumer=20to=20map=20the=20Service=20Provider=20id=20= with=20the=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= bulkId=20of=20the=20created=20Resource.=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20There=20= can=20be=20more=20then=20one=20operation=20per=20Resource=20in=20each=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20bulk=20job.=20= The=20Service=20Consumer=20MUST=20take=20notice=20of=20the=20unordered=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20structure=20= of=20JSON=20and=20the=20Service=20Provider=20can=20process=20operations=20= in=20any=20order.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20For=20example,=20if=20the=20Service=20Consumer=20sends=20two=20PUT=20= operations=20in=20one=20request,=20the=20outcome=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20is=20non-deterministic.=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20The=20Service=20Provider=20response=20MUST=20include=20the=20= result=20of=20all=20processed=20operations.=20A=20location=20attribute=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20that=20= includes=20the=20Resource's=20end=20point=20MUST=20be=20returned=20for=20= all=20operations=20excluding=20failed=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20POSTs.=20The=20status=20attribute=20includes=20= information=20about=20the=20success=20or=20failure=20of=20one=20= operation=20within=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20the=20bulk=20job.=20=20The=20attribute=20status=20MUST=20include=20= the=20code=20attribute=20that=20holds=20the=20HTTP=20response=20code=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20that=20would=20= have=20been=20returned=20if=20a=20single=20HTTP=20request=20would=20have=20= been=20used.=20If=20an=20error=20occurred=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20the=20status=20MUST=20also=20include=20the=20= description=20attribute=20containing=20a=20human=20readable=20= explanation=20of=20the=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20error.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20= following=20is=20an=20example=20of=20a=20status=20in=20a=20failed=20= operation.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20The=20following=20example=20shows=20how=20to=20= add,=20update,=20and=20remove=20a=20user.=20The=20failOnErrors=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20attribute=20is=20set=20= to=20'1'=20indicating=20the=20Service=20Provider=20should=20return=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20on=20the=20first=20= error.=20The=20POST=20operation's=20bulkId=20value=20is=20set=20to=20= 'qwerty'=20enabling=20the=20Consumer=20to=20match=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20the=20new=20User=20with=20the=20= returned=20Resource=20id=20'92b725cd-9465-4e7d-8c16-01f8e146b87a'.=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20Service=20= Provider=20returns=20the=20following=20response.=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20The=20following=20response=20is=20returned=20if=20an=20error=20= occurred=20when=20attempting=20to=20create=20the=20User=20'Alice'.=20The=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Service=20= Provider=20stops=20processing=20the=20bulk=20operation=20and=20= immediately=20returns=20a=20response=20to=20the=20Consumer.=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20response=20= contains=20the=20error=20and=20any=20successful=20results=20prior=20to=20= the=20error.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20If=20the=20= failOnErrors=20attribute=20is=20not=20specified=20or=20the=20Service=20= Provider=20has=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20not=20reached=20the=20error=20limit=20defined=20by=20the=20Consumer=20= the=20Service=20Provider=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20will=20continue=20to=20process=20all=20operations.=20The=20= following=20is=20an=20example=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20in=20which=20all=20operations=20failed.=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20The=20Consumer=20can,=20within=20one=20bulk=20= operation,=20create=20a=20new=20User,=20a=20new=20Group=20and=20add=20= the=20newly=20created=20User=20to=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20the=20newly=20created=20Group.=20=20In=20order=20to=20= add=20the=20new=20User=20to=20the=20Group=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20the=20Consumer=20must=20use=20the=20= surrogate=20id=20attribute,=20bulkId,=20to=20reference=20the=20User.=20= The=20bulkId=20attribute=20value=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20must=20be=20pre-pended=20with=20the=20literal=20= "bulkId:";=20e.g.,=20if=20the=20bulkId=20is=20'qwerty'=20the=20value=20= is=20=20=E2=80=9CbulkId:qwerty=E2=80=9D.=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20The=20Service=20Provider=20MUST=20replace=20= the=20string=20=E2=80=9CbulkId:qwerty=E2=80=9D=20with=20the=20permanent=20= Resource=20id=20once=20created.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20following=20= example=20creates=20a=20User=20with=20the=20userName=20'Alice'=20and=20a=20= Group=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20with=20= the=20displayName=20'Tour=20Guides'=20with=20Alice=20as=20a=20member.=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20Service=20= Provider=20returns=20the=20following=20response.=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20A=20subsequent=20request=20for=20the=20'Tour=20Guides'=20= Group=20('e9e30dba-f08f-4109-8486-d5c6a331660a')=20returns=20the=20= following:=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20Extensions=20that=20include=20references=20to=20other=20Resources=20= MUST=20be=20handled=20in=20the=20same=20way=20by=20the=20Service=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Provider.=20The=20= following=20example=20uses=20the=20bulkId=20attribute=20within=20the=20= enterprise=20extension=20managerId=20attribute.=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=20=20=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20The=20Service=20Provider=20MUST=20try=20to=20resolve=20= circular=20cross=20references=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20between=20Resources=20in=20a=20single=20bulk=20job=20= but=20MAY=20stop=20after=20a=20failed=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20attempt=20and=20instead=20return=20the=20= status=20code=20409=20Conflict.=20The=20following=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20example=20exhibits=20the=20= potential=20conflict.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20If=20the=20Service=20= Provider=20resolved=20the=20above=20circular=20references=20the=20= following=20is=20returned=20from=20a=20subsequent=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20GET=20request.=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20= Service=20Provider=20MUST=20define=20the=20maximum=20number=20of=20= operations=20and=20maximum=20payload=20size=20a=20Consumer=20may=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20send=20in=20a=20= single=20request.=20=20If=20either=20limits=20are=20exceeded=20the=20= Service=20Provider=20MUST=20return=20the=20HTTP=20response=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20code=20413=20Request=20= Entity=20Too=20Large.=20The=20returned=20response=20MUST=20specify=20the=20= limit=20exceeded=20in=20the=20body=20of=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20the=20error=20response.=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= The=20following=20example=20the=20Consumer=20sent=20a=20request=20= exceeding=20the=20Service=20Provider's=20max=20payload=20size=20of=201=20= megabyte.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20= =20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Consumers=20MUST=20specify=20the=20format=20in=20which=20the=20data=20is=20= submitted=20via=20the=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20HTTP=20= header=20content-type=20and=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20MAY=20specify=20the=20desired=20response=20data=20= format=20via=20an=20HTTP=20Accept=20Header;=20e.g.,"Accept:=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20application/json"=20or=20= via=20URI=20suffix;=20e.g.,=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Service=20Providers=20MUST=20support=20the=20Accept=20Headers=20"Accept:=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= application/json"=20for=20JSON=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20and,=20if=20= supported,=20"Accept:=20application/xml"=20for=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20XML.=20The=20format=20defaults=20= to=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20JSON=20= if=20no=20format=20is=20specified.=20The=20data=20structure=20returned=20= is=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= equivalent=20in=20both=20formats;=20the=20only=20difference=20is=20in=20= the=20encoding=20of=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20the=20data.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Singular=20attributes=20= are=20encoded=20as=20string=20name-value-pairs=20in=20JSON;=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20e.g.,=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20
=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20
=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20and=20elements=20in=20XML;=20e.g.,=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20
=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20value=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20]]>=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20
=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Multi-valued=20= attributes=20in=20JSON=20are=20encoded=20as=20arrays;=20e.g.,=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20
=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20and=20repeated=20tags=20= in=20XML;=20e.g.,=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20value1=0Avalue2=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20]]>=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20Elements=20with=20nested=20elements=20are=20= represented=20as=20objects=20in=20JSON;=20e.g,=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20
=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20
=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20and=20= repeated=20tags=20in=20XML;=20e.g.,=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20= value1=0A=20=20= value2=0A=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20]]>=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20
=0A=20=20=20=20=20=20=20=20=20=20= =20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20Consumers=20MAY=20request=20a=20partial=20= Resource=20representation=20on=20any=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20operation=20that=20returns=20a=20Resource=20= within=20the=20response=20by=20specifying=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20the=20URL=20query=20parameter=20= 'attributes'.=20When=20specified,=20each=20Resource=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20returned=20MUST=20contain=20the=20= minimal=20set=20of=20Resource=20attributes=20and,=20MUST=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20contain=20no=20other=20= attributes=20or=20Sub-Attributes=20than=20those=20explicitly=20= requested.=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20The=20query=20parameter=20attributes=20value=20is=20a=20comma=20= separated=20list=20of=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20Resource=20attribute=20names=20in=20standard,=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20attribute=20= notation=20form=20(e.g.=20userName,=20name,=20emails).=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Giving=20= the=20response=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= All=20operations=20share=20a=20common=20scheme=20for=20referencing=20= simple=20and=20complex=20=20attributes.=20=20In=20general,=20attributes=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20are=20= identified=20by=20prefixing=20the=20attribute=20name=20with=20its=20= schema=20URN=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= separated=20by=20a=20':'=20character;=20e.g.,=20the=20core=20User=20= Resource=20attribute=20'userName'=20is=20identified=20as=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= 'urn:scim:schemas:core:1.0:userName'.=20=20Consumers=20MAY=20omit=20core=20= schema=20attribute=20URN=20prefixes=20though=20MUST=20fully=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20qualify=20extended=20= attributes=20with=20the=20associated=20Resource=20URN;=20e.g.,=20the=20= attribute=20'age'=20defined=20in=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20'urn:hr:schemas:user'=20is=20fully=20encoded=20as=20= 'urn:hr:schemas:user:age'.=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20A=20Complex=20attributes'=20Sub-Attributes=20are=20= referenced=20via=20nested,=20dot=20('.')=20notation;=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20i.e.,=20{urn}:{Attribute=20= name}.{Sub-Attribute=20name}.=20=20For=20example,=20the=20fully=20= qualified=20path=20for=20a=20User's=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20givenName=20is=20= urn:scim:schemas:core:1.0:name.givenName=0A=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20All=20facets=20(URN,=20attribute=20and=20= Sub-Attribute=20name)=20of=20the=20fully=20encoded=20Attribute=20name=20= are=20case=20insensitive.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=0A=20=20=20= =20=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20The=20SCIM=20Protocol=20uses=20= the=20response=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20status=20= codes=20defined=20in=20HTTP=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20to=20indicate=20operation=20success=20or=20failure.=20In=20= addition=20to=20returning=20a=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20HTTP=20response=20code=20implementers=20MUST=20return=20= the=20errors=20in=20the=20body=20of=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20the=20response=20in=20the=20client=20requested=20= format=20containing=20the=20error=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20response=20and,=20per=20the=20HTTP=20specification,=20= human-readable=20explanations.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20Implementers=20SHOULD=20handle=20the=20identified=20= errors=20as=20described=20below.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20Code=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Applicability=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20Suggested=20= Explanation=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20400=20BAD=20REQUEST=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20GET,POST,PUT,PATCH,DELETE=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Request=20is=20= unparseable,=20syntactically=20incorrect,=20or=20violates=20schema=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20401=20= UNAUTHORIZED=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20GET,POST,PUT,PATCH,DELETE=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20Authorization=20failure=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20403=20FORBIDDEN=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= GET,POST,PUT,PATCH,DELETE=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20Server=20does=20not=20support=20requested=20= operation=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20404=20NOT=20FOUND=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20GET,PUT,PATCH,DELETE=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20Specified=20resource;=20e.g.,=20User,=20= does=20not=20exist=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20409=20CONFLICT=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20POST,=20PUT,PATCH,DELETE=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20specified=20version=20= number=20does=20not=20match=20the=20resource's=20latest=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20version=20= number=20or=20a=20Service=20Provider=20refused=20to=20create=20a=20new,=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= duplicate=20resource=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20412=20PRECONDITION=20FAILED=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20PUT,PATCH,DELETE=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20Failed=20to=20update=20as=20= Resource=20{id}=20changed=20on=20the=20server=20last=20retrieved=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20413=20REQUEST=20= ENTITY=20TOO=20LARGE=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20POST=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20{"maxOperations":=201000,"maxPayload":=201048576}=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20500=20= INTERNAL=20SERVER=20ERROR=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20GET,POST,PUT,PATCH,DELETE=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20An=20internal=20error.=20= Implementers=20SHOULD=20provide=20descriptive=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20debugging=20advice=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20501=20NOT=20= IMPLEMENTED=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20GET,POST,PUT,PATCH,DELETE=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20Service=20Provider=20does=20not=20support=20= the=20request=20operation;=20e.g.,=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20PATCH=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20Error=20example=20in=20response=20to=20a=20non-existent=20GET=20= request.=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20The=20Base=20URL=20MAY=20be=20appended=20with=20= a=20version=20identifier=20as=20a=20separate=20segment=20in=20the=20URL=20= path.=20=20At=20this=20time=20the=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20only=20valid=20identifier=20is=20'v1'.=20=20If=20= specified,=20the=20version=20identifier=20MUST=20appear=20in=20the=20URL=20= path=20immediately=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20preceding=20the=20Resource=20endpoint=20and=20conform=20to=20the=20= following=20scheme:=20the=20character=20'v'=20followed=20by=20the=20= desired=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= SCIM=20version=20number;=20e.g.,=20a=20version=20'v1'=20User=20request=20= is=20specified=20as=20/v1/Users.=20=20When=20specified=20Service=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Providers=20MUST=20= perform=20the=20operation=20using=20the=20desired=20version=20or=20= reject=20the=20request.=20=20When=20omitted=20Service=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20Providers=20SHOULD=20perform=20= the=20operation=20using=20the=20most=20recent=20API=20supported=20by=20= the=20Service=20Provider.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20API=20= supports=20resource=20versioning=20via=20standard,=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20HTTP=20= ETags.=20Service=20providers=20MAY=20support=20weak=20ETags=20as=20= the=20preferred=20mechanism=20for=20performing=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20conditional=20retrievals=20and=20= ensuring=20Consumers=20do=20not=20inadvertently=20overwrite=20each=20= others=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= changes,=20respectively.=20When=20supported=20SCIM=20ETags=20MUST=20be=20= specified=20as=20an=20HTTP=20header=20and=20SHOULD=20be=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20specified=20within=20the=20= 'version'=20attribute=20contained=20in=20the=20Resource's=20'meta'=20= attribute.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Example:=0A=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20= server=20responds=20with=20an=20ETag=20in=20the=20response=20header=20= and=20meta=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= structure.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20With=20the=20returned=20ETag,=20Consumers=20MAY=20= choose=20to=20retrieve=20the=20Resource=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20only=20if=20the=20Resource=20has=20been=20= modified.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Conditional=20retrieval=20= example=20using=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20If-None-Match=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20header:=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20If=20the=20Resource=20has=20not=20changed=20the=20Service=20= Provider=20simply=20returns=20an=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20empty=20body=20with=20a=20304=20"Not=20Modified"=20= response=20code.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20If=20the=20Service=20Providers=20= supports=20versioning=20of=20resources=20=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20the=20Consumer=20MUST=20supply=20an=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20If-Match=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= header=20for=20PUT=20and=20PATCH=20operations=20to=20ensure=20that=20the=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20requested=20= operation=20succeeds=20only=20if=20the=20supplied=20ETag=20matches=20the=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20latest=20= Service=20Provider=20Resource;=20e.g.,=20If-Match:=20W/"e180ee84f0671b1"=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20In=20recognition=20that=20some=20clients,=20= servers=20and=20firewalls=20prevent=20PUT,=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20PATCH=20and=20DELETE=20operations=20a=20= client=20MAY=20override=20the=20POST=20operation=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20by=20specifying=20the=20custom=20= header=20"X-HTTP-Method-Override"=20with=20the=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20desired=20PUT,=20PATCH,=20DELETE=20= operation.=20For=20example:=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20The=20SCIM=20Protocol=20is=20based=20= on=20HTTP=20and=20thus=20subject=20to=20the=20security=20considerations=20= found=20in=20Section=2015=20of=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20[R= FC2616].=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20SCIM=20= Resources=20(e.g.,=20Users=20and=20Groups)=20can=20contain=20sensitive=20= information.=20=20Therefore,=20SCIM=20Consumers=20and=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20Service=20Providers=20MUST=20implement=20= TLS.=20=20Which=20version(s)=20ought=20to=20be=20implemented=20will=20= vary=20over=20time,=20and=20depend=20on=20the=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20widespread=20deployment=20and=20known=20security=20= vulnerabilities=20at=20the=20time=20of=20implementation.=20=20At=20the=20= time=20of=20this=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= writing,=20TLS=20version=201.2=20[RFC5246]=20is=20the=20= most=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20recent=20version,=20= but=20has=20very=20limited=20actual=20deployment,=20and=20might=20not=20= be=20readily=20available=20in=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20implementation=20toolkits.=20=20TLS=20version=201.0=20[RFC2246]=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20is=20the=20most=20widely=20= deployed=20version,=20and=20will=20give=20the=20broadest=20= interoperability.=0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Samuel=20= Erdtman=20(samuel@erdtman.se)=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20Patrick=20Harding=20= (pharding@pingidentity.com)=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20The=20= editor=20would=20like=20to=20thank=20the=20participants=20in=20the=20the=20= SCIM=20working=20group=20for=20their=20support=20of=20this=20= specification.=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20= =0A=0A= --Apple-Mail=_19FFEAC6-A1D7-4DDC-818F-22E497C6FAE7 Content-Disposition: attachment; filename=draft-scim-api-01.txt Content-Type: text/plain; name="draft-scim-api-01.txt" Content-Transfer-Encoding: quoted-printable DRAFT T. Drake, Ed. UnboundID C. Mortimore SalesForce M. Ansari Cisco K. Grizzle SailPoint E. Wahlstroem Technology Nexus July 09, 2012 System for Cross-Domain Identity Management:Protocol 1.1 Abstract The System for Cross-Domain Identity Management (SCIM) specification is designed to make managing user identity in cloud based applications and services easier. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. It's intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols. In essence, make it fast, cheap, and easy to move users in to, out of, and around the cloud. Drake, et al. [Page 1] =0C draft-scim-api-01 July 2012 Table of Contents 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 1.1. Intended Audience . . . . . . . . . . . . . . . . . . . . 3 1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 3 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 2. Authentication and Authorization . . . . . . . . . . . . . . . 4 3. API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Creating Resources . . . . . . . . . . . . . . . . . . . . 6 3.2. Retrieving Resources . . . . . . . . . . . . . . . . . . . 8 3.2.1. Retrieving a known Resource . . . . . . . . . . . . . 8 3.2.2. List/Query Resources . . . . . . . . . . . . . . . . . 9 3.3. Modifying Resources . . . . . . . . . . . . . . . . . . . 16 3.3.1. Modifying with PUT . . . . . . . . . . . . . . . . . . 16 3.3.2. Modifying with PATCH . . . . . . . . . . . . . . . . . 18 3.4. Deleting Resources . . . . . . . . . . . . . . . . . . . . 26 3.5. Bulk . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.6. Data Input/Output Formats . . . . . . . . . . . . . . . . 42 3.7. Additional retrieval query parameters . . . . . . . . . . 43 3.8. Attribute Notation . . . . . . . . . . . . . . . . . . . . 43 3.9. HTTP Response Codes . . . . . . . . . . . . . . . . . . . 44 3.10. API Versioning . . . . . . . . . . . . . . . . . . . . . . 45 3.11. Versioning Resources . . . . . . . . . . . . . . . . . . . 46 3.12. HTTP Method Overloading . . . . . . . . . . . . . . . . . 47 4. Security Considerations . . . . . . . . . . . . . . . . . . . 49 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 50 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 Drake, et al. [Page 2] =0C draft-scim-api-01 July 2012 1. Introduction and Overview The SCIM Protocol is an application-level, REST protocol for provisioning and managing identity data on the web. The protocol supports creation, modification, retrieval, and discovery of core identity Resources; i.e., Users and Groups, as well as custom Resource extensions. 1.1. Intended Audience This document is intended as a guide to SCIM API usage for both identity Service Providers and Consumers. 1.2. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. These keywords are capitalized when used to unambiguously specify requirements of the protocol or application features and behavior that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense. For purposes of readability examples are not URL encoded. Implementers MUST percent encode URLs as described in RFC3896 2.1. 1.3. Definitions Base URL: The SCIM REST API is always relative to a Base URL. The Base URL MUST NOT contain a query string as Consumers may append additional path information and query parameters as part of forming the request. Example: https://example.com/scim/v1/ Drake, et al. [Page 3] =0C draft-scim-api-01 July 2012 2. Authentication and Authorization The SCIM protocol does not define a scheme for authentication and authorization therefore implementers are free to choose mechanisms appropriate to their use cases. The choice of authentication mechanism will impact interoperability. It is RECOMMENDED that clients be implemented in such a way that new authentication schemes can be deployed. Implementers SHOULD support existing authentication/authorization schemes. In particular, OAuth2 Bearer Token [1] is RECOMMENDED. Appropriate security considerations of the selected authentication and authorization schemes SHOULD be taken. Because this protocol uses HTTP response status codes as the primary means of reporting the result of a request, servers are advised to respond to unauthorized or unauthenticated requests using the 401 response code in accordance with section 10.4.2 of RFC2616. All examples assume OAuth2 bearer token; e.g., GET /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1 Host: example.com Authorization: Bearer h480djs93hd8 The context of the request (i.e. the user for whom data is being requested) MUST be inferred by Service Providers. Drake, et al. [Page 4] =0C draft-scim-api-01 July 2012 3. API The SCIM protocol specifies well known endpoints and HTTP methods for managing Resources defined in the core schema; i.e., User and Group Resources correspond to /Users and /Groups respectively. Service Providers that support extended Resources SHOULD define Resource endpoints using the established convention; pluralize the Resource name defined in the extended schema by appending an 's'. Given there are cases where Resource pluralization is ambiguous; e.g., a Resource named 'person' is legitimately 'persons' and 'people' Consumers SHOULD discover Resource endpoints via the Schema Sub-Attribute 'endpoint'. GET Retrieves a complete or partial Resource. POST Create new Resource or bulk modify Resources. PUT Modifies a Resource with a complete, Consumer specified Resource (replace). PATCH Modifies a Resource with a set of Consumer specified changes (partial update). DELETE Deletes a Resource. +------------+--------------------+---------------+-----------------+ | Resource | Endpoint | Operations | Description | +------------+--------------------+---------------+-----------------+ | User | /Users | GET | Retrieve/Add/Mo | | | | (Section 3.2. | dify Users | | | | 1), POST | | | | | (Section 3.1 | | | | | ),PUT | | | | | (Section 3. | | | | | 3.1), PATCH | | | | | (Section 3 | | | | | .3.2), DELETE | | | | | (Section | | | | | 3.4) | | | | | | | Drake, et al. [Page 5] =0C draft-scim-api-01 July 2012 | Group | /Groups | GET | Retrieve/Add/Mo | | | | (Section 3.2. | dify Groups | | | | 1), POST | | | | | (Section 3.1 | | | | | ),PUT | | | | | (Section 3. | | | | | 3.1), PATCH | | | | | (Section 3 | | | | | .3.2), DELETE | | | | | (Section | | | | | 3.4) | | | | | | | | Service | /ServiceProviderCo | GET | Retrieve the | | Provider | nfigs | (Section 3.2. | Service | | Configurat | | 1) | Provider's | | ion | | | Configuration | | | | | | | Schema | /Schemas | GET | Retrieve a | | | | (Section 3.2. | Resource's | | | | 1) | Schema | | | | | | | Bulk | /Bulk | POST | Bulk modify | | | | (Section 3.5) | Resources | +------------+--------------------+---------------+-----------------+ Table 1: Defined endpoints All requests to the Service Provider are made via HTTP operations on a URL derived from the Base URL. Responses are returned in the body of the HTTP response, formatted as JSON or XML, depending on what is requested. Response and error codes SHOULD be transmitted via the HTTP status code of the response (if possible), and SHOULD also be specified in the body of the response. 3.1. Creating Resources To create new Resources, clients send POST requests to the Resource endpoint; i.e., /Users or /Groups. Successful Resource creation is indicated with a 201 ("Created") response code. Upon successful creation, the response body MUST contain the newly created Resource. Since the server is free to alter and/or ignore POSTed content, returning the full representation can be useful to the client, enabling it to correlate the client and server views of the new Resource. When a Resource is created, its URI must be returned in the response Location header. If the Service Provider determines creation of the requested Resource Drake, et al. [Page 6] =0C draft-scim-api-01 July 2012 conflicts with existing resources; e.g., a User Resource with a duplicate userName, the Service Provider MUST return a 409 error and SHOULD indicate the conflicting attribute(s) in the body of the response. Below, the client sends a POST request containing a User POST /Users HTTP/1.1 Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 Content-Length: ... { "schemas":["urn:scim:schemas:core:1.0"], "userName":"bjensen", "externalId":"bjensen", "name":{ "formatted":"Ms. Barbara J Jensen III", "familyName":"Jensen", "givenName":"Barbara" } } The server signals a successful creation with a status code of 201. The response includes a Location header indicating the User URI, and a representation of that User in the body of the response. Drake, et al. [Page 7] =0C draft-scim-api-01 July 2012 HTTP/1.1 201 Created Content-Type: application/json Location: = https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 ETag: W/"e180ee84f0671b1" { "schemas":["urn:scim:schemas:core:1.0"], "id":"2819c223-7f76-453a-919d-413861904646", "externalId":"bjensen", "meta":{ "created":"2011-08-01T21:32:44.882Z", "lastModified":"2011-08-01T21:32:44.882Z", = "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904= 646", "version":"W\/\"e180ee84f0671b1\"" }, "name":{ "formatted":"Ms. Barbara J Jensen III", "familyName":"Jensen", "givenName":"Barbara" }, "userName":"bjensen" } 3.2. Retrieving Resources Users and Group Resources are retrieved via opaque, unique URLs or via Query. Service Providers MAY choose to respond with a sub-set of Resource attributes, though MUST minimally return the Resource id and meta attributes. 3.2.1. Retrieving a known Resource To retrieve a known Resource, clients send GET requests to the Resource endpoint; e.g., /Users/{id} or /Groups/{id}. If the Resource exists the server responds with a status code of 200 and includes the result in the body of the response. The below example retrieves a single User via the /Users endpoint. GET /Users/2819c223-7f76-453a-919d-413861904646 Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 Drake, et al. [Page 8] =0C draft-scim-api-01 July 2012 The server responds with: HTTP/1.1 200 OK Content-Type: application/json Location: = https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 ETag: W/"f250dd84f0671c3" { "schemas":["urn:scim:schemas:core:1.0"], "id":"2819c223-7f76-453a-919d-413861904646, "externalId":"bjensen", "meta":{ "created":"2011-08-01T18:29:49.793Z", "lastModified":"2011-08-01T18:29:49.793Z", = "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904= 646", "version":"W\/\"f250dd84f0671c3\"" }, "name":{ "formatted":"Ms. Barbara J Jensen III", "familyName":"Jensen", "givenName":"Barbara" }, "userName":"bjensen", "phoneNumbers":[ { "value":"555-555-8377", "type":"work" } ], "emails":[ { "value":"bjensen@example.com", "type":"work" } ] } 3.2.2. List/Query Resources SCIM defines a standard set of operations that can be used to filter, sort, and paginate response results. The operations are specified by adding query parameters to the Resource's endpoint. Service Providers MAY support additional query parameters not specified here, and Providers SHOULD ignore any query parameters they don't recognize. Drake, et al. [Page 9] =0C draft-scim-api-01 July 2012 The below example returns the userName for all Users: GET /Users?attributes=3DuserName Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 HTTP/1.1 200 OK Content-Type: application/json { "totalResults":2, "schemas":["urn:scim:schemas:core:1.0"], "Resources":[ { "userName":"bjensen" }, { "userName":"jsmith" } ] } 3.2.2.1. Filtering Filtering is OPTIONAL. Consumers may request a subset of Resources by specifying the 'filter' URL query parameter containing a filter expression. When specified only those Resources matching the filter expression SHALL be returned. The expression language that is used in the filter parameter supports references to attributes and literals. The literal values can be strings enclosed in double quotes, numbers, date times enclosed in double quotes, and Boolean values; i.e., true or false. String literals MUST be valid JSON strings [2]. The attribute name and attribute operator are case insensitive. For example, the following two expressions will evaluate to the same logical value: filter=3DuserName Eq "john" filter=3DUsername eq "john" The filter parameter MUST contain at least one valid Boolean expression. Each expression MUST contain an attribute name followed Drake, et al. [Page 10] =0C draft-scim-api-01 July 2012 by an attribute operator and optional value. Multiple expressions MAY be combined using the two logical operators. Furthermore expressions can be grouped together using "()". The operators supported in the expression are listed in the following table. +----------+-------------+------------------------------------------+ | Operator | Description | Behavior | +----------+-------------+------------------------------------------+ | eq | equal | The attribute and operator values must | | | | be identical for a match. | | | | | | co | contains | The entire operator value must be a | | | | substring of the attribute value for a | | | | match. | | | | | | sw | starts with | The entire operator value must be a | | | | substring of the attribute value, | | | | starting at the beginning of the | | | | attribute value. This criterion is | | | | satisfied if the two strings are | | | | identical. | | | | | | pr | present | If the attribute has a non-empty value, | | | (has value) | or if it contains a non-empty node for | | | | complex attributes there is a match. | | | | | | gt | greater | If the attribute value is greater than | | | than | operator value, there is a match. The | | | | actual comparison is dependent on the | | | | attribute type. For string attribute | | | | types, this is a lexicographical | | | | comparison and for DateTime types, it is | | | | a chronological comparison. | | | | | | ge | greater | If the attribute value is greater than | | | than or | or equal to the operator value, there is | | | equal | a match. The actual comparison is | | | | dependent on the attribute type. For | | | | string attribute types, this is a | | | | lexicographical comparison and for | | | | DateTime types, it is a chronological | | | | comparison. | | | | | Drake, et al. [Page 11] =0C draft-scim-api-01 July 2012 | lt | less than | If the attribute value is less than | | | | operator value, there is a match. The | | | | actual comparison is dependent on the | | | | attribute type. For string attribute | | | | types, this is a lexicographical | | | | comparison and for DateTime types, it is | | | | a chronological comparison. | | | | | | le | less than | If the attribute value is less than or | | | or equal | equal to the operator value, there is a | | | | match. The actual comparison is | | | | dependent on the attribute type. For | | | | string attribute types, this is a | | | | lexicographical comparison and for | | | | DateTime types, it is a chronological | | | | comparison. | +----------+-------------+------------------------------------------+ Table 2: Attribute Operators +----------+-------------+------------------------------------------+ | Operator | Description | Behavior | +----------+-------------+------------------------------------------+ | and | Logical And | The filter is only a match if both | | | | expressions evaluate to true. | | | | | | or | Logical or | The filter is a match if either | | | | expression evaluates to true. | +----------+-------------+------------------------------------------+ Table 3: Logical Operators +----------+-------------+------------------------------------------+ | Operator | Description | Behavior | +----------+-------------+------------------------------------------+ | () | Precedence | Boolean expressions may be grouped using | | | grouping | parentheses to change the standard order | | | | of operations; i.e., evaluate OR logical | | | | operators before logical AND operators. | +----------+-------------+------------------------------------------+ Table 4: Grouping Operators Filters MUST be evaluated using standard order of operations. Attribute operators have the highest precedence, followed by the grouping operator (i.e, parentheses), followed by the logical AND operator, followed by the logical OR operator. Drake, et al. [Page 12] =0C draft-scim-api-01 July 2012 If the specified attribute in a filter expression is a multi-valued attribute, the Resource MUST match if any of the instances of the given attribute match the specified criterion; e.g. if a User has multiple emails values, only one has to match for the entire User to match. For complex attributes, a fully qualified Sub-Attribute MUST be specified using standard attribute notation (Section 3.8). For example, to filter by userName the parameter value is userName and to filter by first name, the parameter value is name.givenName. Providers MAY support additional filter operations if they choose. Providers MUST decline to filter results if the specified filter operation is not recognized and return a HTTP 400 error with an appropriate human readable response. For example, if a Consumer specified an unsupported operator named 'regex' the Service Provider should specify an error response description identifying the Consumer error; e.g., 'The operator 'regex' is not supported.' String type attributes are case insensitive by default unless the attribute type is defined as a caseExact string. Attribute operators 'eq', 'co', and 'sw' MUST perform caseIgnore matching for all string attributes unless the attribute is defined as caseExact. By default all string attributes are caseIgnore. Examples: filter=3DuserName eq "bjensen" filter=3Dname.familyName co "O'Malley" filter=3DuserName sw "J" filter=3Dtitle pr filter=3Dmeta.lastModified gt "2011-05-13T04:42:34Z" filter=3Dmeta.lastModified ge "2011-05-13T04:42:34Z" filter=3Dmeta.lastModified lt "2011-05-13T04:42:34Z" filter=3Dmeta.lastModified le "2011-05-13T04:42:34Z" filter=3Dtitle pr and userType eq "Employee" filter=3Dtitle pr or userType eq "Intern" filter=3DuserType eq "Employee" and (emails co "example.com" or = emails co "example.org") Drake, et al. [Page 13] =0C draft-scim-api-01 July 2012 3.2.2.2. Sorting Sort is OPTIONAL. Sorting allows Consumers to specify the order in which Resources are returned by specifying a combination of sortBy and sortOrder URL parameters. sortBy: The sortBy parameter specifies the attribute whose value SHALL be used to order the returned responses. If the sortBy attribute corresponds to a Singular Attribute, Resources are sorted according to that attribute's value; if it's a Multi-valued Attribute, Resources are sorted by the value of the primary attribute, if any, or else the first value in the list, if any. If the attribute is complex the attribute name must be a path to a Sub-Attribute in standard attribute notation (Section 3.8) ; e.g., sortBy=3Dname.givenName. For all attribute types, if there is no data for the specified sortBy value they are sorted via the 'sortOrder' parameter; i.e., they are ordered last if ascending and first if descending. sortOrder: The order in which the sortBy parameter is applied. Allowed values are "ascending" and "descending". If a value for sortBy is provided and no sortOrder is specified, the sortOrder SHALL default to ascending. String type attributes are case insensitive by default unless the attribute type is defined as a caseExact string. sortOrder MUST sort according to the attribute type; i.e., for caseIgnore attributes, sort the result using case insensitive, Unicode alphabetic sort order, with no specific locale implied and for caseExact attribute types, sort the result using case sensitive, Unicode alphabetic sort order. 3.2.2.3. Pagination Pagination parameters can be used together to "page through" large numbers of Resources so as not to overwhelm the Consumer or Service Provider. Pagination is not session based hence Consumers SHOULD never assume repeatable results. For example, a request for a list of 10 Resources beginning with a startIndex of 1 may return different results when repeated as a Resource in the original result could be deleted or new ones could be added in-between requests. Pagination parameters and general behavior are derived from the OpenSearch Protocol [3]. The following table describes the URL pagination parameters. Drake, et al. [Page 14] =0C draft-scim-api-01 July 2012 +------------+-------------------+----------------------------------+ | Parameter | Description | Default | +------------+-------------------+----------------------------------+ | startIndex | The 1-based index | 1 | | | of the first | | | | search result. | | | | | | | count | Non-negative | None. When specified the | | | Integer. | Service Provider MUST not return | | | Specifies the | more results than specified | | | desired maximum | though MAY return fewer results. | | | number of search | If unspecified, the maximum | | | results per page; | number of results is set by the | | | e.g., 10. | Service Provider. | +------------+-------------------+----------------------------------+ Table 5: Pagination Request parameters The following table describes the query response pagination attributes specified by the Service Provider. +--------------+----------------------------------------------------+ | Element | Description | +--------------+----------------------------------------------------+ | itemsPerPage | Non-negative Integer. Specifies the number of | | | search results returned in a query response page; | | | e.g., 10. | | | | | totalResults | Non-negative Integer. Specifies the total number | | | of results matching the Consumer query; e.g., | | | 1000. | | | | | startIndex | The 1-based index of the first result in the | | | current set of search results; e.g., 1. | +--------------+----------------------------------------------------+ Table 6: Pagination Response Elements For example, to retrieve the first 10 Users set the startIndex to 1 and the count to 10. GET /Users?startIndex=3D1&count=3D10 Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 Drake, et al. [Page 15] =0C draft-scim-api-01 July 2012 { "totalResults":100, "itemsPerPage":10, "startIndex":1, "schemas":["urn:scim:schemas:core:1.0"], "Resources":[{ ... }] } Given the example above, to continue paging set the startIndex to 11 and re-fetch; i.e., /Users?startIndex=3D11&count=3D10 3.3. Modifying Resources Resources can be modified in whole or in part via PUT or PATCH, respectively. Implementers MUST support PUT as specified in RFC2616 . Resources such as Groups may be very large hence implementers SHOULD support PATCH [4] to enable partial resource modifications. 3.3.1. Modifying with PUT PUT performs a full update. Consumers must retrieve the entire Resource and PUT the desired modifications as the operation overwrites all previously stored data with the exception of the password attribute. If the password attribute of the User resource is unspecified, it should be left in-tact. Since this performs a full update, Consumers MAY send read-only attributes of the retrieved resource and Service Provider MUST ignore any read-only attributes that are present in the payload of a PUT request. Unless otherwise specified a successful PUT operation returns a 200 OK response code and the entire Resource within the response body, enabling the Consumer to correlate the Consumer's and Provider's views of the updated Resource. Example: Drake, et al. [Page 16] =0C draft-scim-api-01 July 2012 PUT /Users/2819c223-7f76-453a-919d-413861904646 Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 If-Match: W/"a330bc54f0671c9" { "schemas":["urn:scim:schemas:core:1.0"], "id":"2819c223-7f76-453a-919d-413861904646", "userName":"bjensen", "externalId":"bjensen", "name":{ "formatted":"Ms. Barbara J Jensen III", "familyName":"Jensen", "givenName":"Barbara", "middleName":"Jane" }, "emails":[ { "value":"bjensen@example.com" }, { "value":"babs@jensen.org" } ] } The service responds with the entire, updated User Drake, et al. [Page 17] =0C draft-scim-api-01 July 2012 HTTP/1.1 200 OK Content-Type: application/json ETag: W/"b431af54f0671a2" = Location:"https://example.com/v1/Users/2819c223-7f76-453a-919d-41386190464= 6" { "schemas":["urn:scim:schemas:core:1.0"], "id":"2819c223-7f76-453a-919d-413861904646", "userName":"bjensen", "externalId":"bjensen", "name":{ "formatted":"Ms. Barbara J Jensen III", "familyName":"Jensen", "givenName":"Barbara", "middleName":"Jane" }, "emails":[ { "value":"bjensen@example.com" }, { "value":"babs@jensen.org" } ], "meta": { "created":"2011-08-08T04:56:22Z", "lastModified":"2011-08-08T08:00:12Z", = "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904= 646", "version":"W\/\"b431af54f0671a2\"" } } 3.3.2. Modifying with PATCH PATCH is OPTIONAL. PATCH enables consumers to send only those attributes requiring modification, reducing network and processing overhead. Attributes may be deleted, replaced, merged, or added in a single request. The body of a PATCH request MUST contain a partial Resource with the desired modifications. The server MUST return either a 200 OK response code and the entire Resource (subject to the "attributes" query parameter - see Additional Retrieval Query Parameters (Section 3.7)) within the response body, or a 204 No Content response code and the appropriate response headers for a successful PATCH request. The server MUST return a 200 OK if the "attributes" parameter is specified on the request. The server MUST process a PATCH request by first removing any Drake, et al. [Page 18] =0C draft-scim-api-01 July 2012 attributes specified in the meta.attributes Sub-Attribute (if present) and then merging the attributes in the PATCH request body into the Resource. The meta.attributes Sub-Attribute MAY contain a list of attributes to be removed from the Resource. If the PATCH request body contains an attribute that is present in the meta.attributes list, the attribute on the Resource is replaced with the value from the PATCH body. If the attribute is complex the attribute name must be a path to a Sub- Attribute in standard attribute notation (Section 3.8); e.g., name.givenName. Attributes that exist in the PATCH request body but not in the meta.attributes Sub-Attribute will be either be updated or added to the Resource according to the following rules. Singular attributes: Singular attributes in the PATCH request body replace the attribute on the Resource. Complex attributes: Complex Sub-Attribute values in the PATCH request body are merged into the complex attribute on the Resource. Multi-valued attributes: An attribute value in the PATCH request body is added to the value collection if the value does not exist and merged if a matching value is present. Values are matched by comparing the value Sub-Attribute from the PATCH request body to the value Sub-Attribute of the Resource. Attributes that do not have a value Sub-Attribute; e.g., addresses, or do not have unique value Sub-Attributes cannot be matched and must instead be deleted then added. Specific values can be removed from a Resource by adding an "operation" Sub-Attribute with the value "delete" to the attribute in the PATCH request body. As with adding/updating attribute value collections, the value to delete is determined by comparing the value Sub-Attribute from the PATCH request body to the value Sub-Attribute of the Resource. Attributes that do not have a value Sub-Attribute or that have a non-unique value Sub- Attribute are matched by comparing all Sub-Attribute values from the PATCH request body to the Sub-Attribute values of the Resource. A delete operation is ignored if the attribute's name is in the meta.attributes list. If the requested value to delete does not match a unique value on the Resource the server MAY return a HTTP 400 error. The following example shows how to add a member to a group: Drake, et al. [Page 19] =0C draft-scim-api-01 July 2012 PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 If-Match: W/"a330bc54f0671c9" { "schemas": ["urn:scim:schemas:core:1.0"], "members": [ { "display": "Babs Jensen", "value": "2819c223-7f76-453a-919d-413861904646" } ] } The "display" Sub-Attribute in this request is optional since the value attribute uniquely identifies the user to be added. If the user was already a member of this group, no changes should be made to the Resource and a success response should be returned. The server responds with either the entire updated Group or no response body: HTTP/1.1 204 No Content Authorization: Bearer h480djs93hd8 ETag: W/"b431af54f0671a2" Location: = "https://example.com/v1/Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce" The following example shows how to remove a member from a group. As with the previous example, the "display" Sub-Attribute is optional. If the user was not a member of this group, no changes should be made to the Resource and a success response should be returned. Note that server responses have been omitted for the rest of the PATCH examples. Drake, et al. [Page 20] =0C draft-scim-api-01 July 2012 PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 If-Match: W/"a330bc54f0671c9" { "schemas": ["urn:scim:schemas:core:1.0"], "members": [ { "display": "Babs Jensen", "value": "2819c223-7f76-453a-919d-413861904646" "operation": "delete" } ] } The following example shows how to remove all members from a group: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 If-Match: W/"a330bc54f0671c9" { "schemas": ["urn:scim:schemas:core:1.0"], "meta": { "attributes": [ "members" ] } } The following example shows how to replace all of the members of a group with a different members list: Drake, et al. [Page 21] =0C draft-scim-api-01 July 2012 PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 If-Match: W/"a330bc54f0671c9" { "schemas": ["urn:scim:schemas:core:1.0"], "meta": { "attributes": [ "members" ] }, "members": [ { "display": "Babs Jensen", "value": "2819c223-7f76-453a-919d-413861904646" }, { "display": "James Smith", "value": "08e1d05d-121c-4561-8b96-473d93df9210" } ] } The following example shows how to add a member to and remove a member from a Group in a single request: Drake, et al. [Page 22] =0C draft-scim-api-01 July 2012 PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 If-Match: W/"a330bc54f0671c9" { "schemas": ["urn:scim:schemas:core:1.0"], "members": [ { "display": "Babs Jensen", "value": "2819c223-7f76-453a-919d-413861904646" "operation": "delete" }, { "display": "James Smith", "value": "08e1d05d-121c-4561-8b96-473d93df9210" } ] } The following example shows how to change a User's primary email. If the User already has the email address, it is made the primary address and the current primary address (if present) is made non- primary. If the User does not already have the email address, it is added and made the primary address. PATCH /Users/2819c223-7f76-453a-919d-413861904646 Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 If-Match: W/"a330bc54f0671c9" { "schemas": ["urn:scim:schemas:core:1.0"], "emails": [ { "value": "bjensen@example.com", "primary": true } ] } The following example shows how to change a User's address. Since address does not have a value Sub-Attribute, the existing address must be removed and the modified address added. Drake, et al. [Page 23] =0C draft-scim-api-01 July 2012 PATCH /Users/2819c223-7f76-453a-919d-413861904646 Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 If-Match: W/"a330bc54f0671c9" { "schemas": ["urn:scim:schemas:core:1.0"], "addresses": [ { "type": "work", "streetAddress": "100 Universal City Plaza", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "US", "formatted": "100 Universal City Plaza\nHollywood, CA 91608 US", "primary": true "operation": "delete" }, { "type": "work", "streetAddress": "911 Universal City Plaza", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "US", "formatted": "911 Universal City Plaza\nHollywood, CA 91608 US", "primary": true } ] } The following example shows how to change a User's nickname: PATCH /Users/2819c223-7f76-453a-919d-413861904646 Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 If-Match: W/"a330bc54f0671c9" { "schemas": ["urn:scim:schemas:core:1.0"], "nickName": "Barbie" } Drake, et al. [Page 24] =0C draft-scim-api-01 July 2012 The following example shows how to remove a User's nickname: PATCH /Users/2819c223-7f76-453a-919d-413861904646 Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 If-Match: W/"a330bc54f0671c9" { "schemas": ["urn:scim:schemas:core:1.0"], "meta": { "attributes": [ "nickName" ] } } The following example shows how to change a User's familyName. This only updates the familyName and formatted on the "name" complex attribute. Any other name Sub-Attributes on the Resource remain unchanged. PATCH /Users/2819c223-7f76-453a-919d-413861904646 Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 If-Match: W/"a330bc54f0671c9" { "schemas": ["urn:scim:schemas:core:1.0"], "name": { "formatted": "Ms. Barbara J Jensen III", "familyName": "Jensen" } } The following example shows how to remove a complex Sub-Attribute and an extended schema attribute from a User. Drake, et al. [Page 25] =0C draft-scim-api-01 July 2012 PATCH /Users/2819c223-7f76-453a-919d-413861904646 Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 If-Match: W/"a330bc54f0671c9" { "schemas": ["urn:scim:schemas:core:1.0"], "meta": { "attributes": [ "name.formatted", "urn:hr:schemas:user:age" ] } } 3.4. Deleting Resources Consumers request Resource removal via DELETE. Service Providers MAY choose not to permanently delete the Resource, but MUST return a 404 error code for all operations associated with the previously deleted Id. Service Providers MUST also omit the Resource from future query results. In addition the Service Provider MUST not consider the deleted resource in conflict calculation. For example if a User resource is deleted, a CREATE request for a User resource with the same userName as the previously deleted resource should not fail with a 409 error due to userName conflict. DELETE /Users/2819c223-7f76-453a-919d-413861904646 Host: example.com Authorization: Bearer h480djs93hd8 If-Match: W/"c310cd84f0281b7" HTTP/1.1 200 OK Example: Consumer attempt to retrieve the previously deleted User GET /Users/2819c223-7f76-453a-919d-413861904646 Host: example.com Authorization: Bearer h480djs93hd8 Drake, et al. [Page 26] =0C draft-scim-api-01 July 2012 HTTP/1.1 404 NOT FOUND { "Errors":[ { "description":"Resource 2819c223-7f76-453a-919d-413861904646 not = found", "code":"404" } ] } 3.5. Bulk Bulk is OPTIONAL. The bulk operation enables Consumers to send a potentially large collection of Resource operations in a single request. The body of a a bulk operation contains a set of HTTP Resource operations using one of the API supported HTTP methods; i.e., POST, PUT, PATCH or DELETE. The following Singular Attribute is defined in addition to the common attributes defined in SCIM core schema. failOnErrors An Integer specifying the number of errors that the Service Provider will accept before the operation is terminated and an error response is returned. OPTIONAL. The following Complex Multi-valued Attribute is defined in addition to the common attributes defined in core schema. Operations Defines operations within a bulk job. Each operation corresponds to a single HTTP request against a Resource endpoint. REQUIRED. method The HTTP method of the current operation. Possible values are POST, PUT, PATCH or DELETE. REQUIRED. bulkId The transient identifier of a newly created Resource, unique within a bulk request and created by the Consumer. The bulkId serves as a surrogate Resource id enabling Consumers to uniquely identify newly created Resources in the Response and cross reference new Resources in and across operations within a bulk request. REQUIRED when method is POST. version The current Resource version. Version is REQUIRED if the Service Provider supports ETags and the method is PUT, DELETE, or PATCH. Drake, et al. [Page 27] =0C draft-scim-api-01 July 2012 path The Resource's relative path. If the method is POST the value must specify a Resource type endpoint; e.g., /Users or /Groups whereas all other method values must specify the path to a specific Resource; e.g., /Users/ 2819c223-7f76-453a-919d-413861904646. REQUIRED in a request. data The Resource data as it would appear for a single POST, PUT or PATCH Resource operation. REQUIRED in a request when method is POST, PUT and PATCH. location The Resource endpoint URL. REQUIRED in a response, except in the event of a POST failure. status A complex type that contains information about the success or failure of one operation within the bulk job. REQUIRED in a response. code The HTTP response code that would have been returned if a a single HTTP request would have been used. REQUIRED. description A human readable error message. REQUIRED when an error occurred. If a bulk job is processed successfully the HTTP response code 200 OK MUST be returned, otherwise an appropriate HTTP error code MUST be returned. The Service Provider MUST continue performing as many changes as possible and disregard partial failures. The Consumer MAY override this behavior by specifying a value for failOnErrors attribute. The failOnErrors attribute defines the number of errors that the Service Provider should accept before failing the remaining operations returning the response. To be able to reference a newly created Resource the attribute bulkId MUST be specified when creating new Resources. The bulkId is defined by the Consumer as a surrogate identifier in a POST operation. The Service Provider MUST return the same bulkId together with the newly created Resource. The bulkId can then be used by the Consumer to map the Service Provider id with the bulkId of the created Resource. There can be more then one operation per Resource in each bulk job. The Service Consumer MUST take notice of the unordered structure of JSON and the Service Provider can process operations in any order. For example, if the Service Consumer sends two PUT operations in one request, the outcome is non-deterministic. The Service Provider response MUST include the result of all Drake, et al. [Page 28] =0C draft-scim-api-01 July 2012 processed operations. A location attribute that includes the Resource's end point MUST be returned for all operations excluding failed POSTs. The status attribute includes information about the success or failure of one operation within the bulk job. The attribute status MUST include the code attribute that holds the HTTP response code that would have been returned if a single HTTP request would have been used. If an error occurred the status MUST also include the description attribute containing a human readable explanation of the error. "status": { "code": "201" } The following is an example of a status in a failed operation. "status": { "code": "400", "description": "Request is unparseable, syntactically incorrect, or = violates schema." } The following example shows how to add, update, and remove a user. The failOnErrors attribute is set to '1' indicating the Service Provider should return on the first error. The POST operation's bulkId value is set to 'qwerty' enabling the Consumer to match the new User with the returned Resource id '92b725cd-9465-4e7d-8c16- 01f8e146b87a'. POST /v1/Bulk Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 Content-Length: ... { "schemas":[ "urn:scim:schemas:core:1.0" ], "failOnErrors":1, "Operations":[ { "method":"POST", "path":"/Users", "bulkId":"qwerty", Drake, et al. [Page 29] =0C draft-scim-api-01 July 2012 "data":{ "schemas":[ "urn:scim:schemas:core:1.0" ], "userName":"Alice" } }, { "method":"PUT", "path":"/Users/b7c14771-226c-4d05-8860-134711653041", "version":"W\/\"3694e05e9dff591\"", "data":{ "schemas":[ "urn:scim:schemas:core:1.0" ], "id":"b7c14771-226c-4d05-8860-134711653041", "userName":"Bob" } }, { "method":"PATCH", "path":"/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", "version":"W\/\"edac3253e2c0ef2\"", "data":{ "schemas":[ "urn:scim:schemas:core:1.0" ], "id":"5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", "userName":"Dave", "meta":{ "attributes":[ "nickName" ] } } }, { "method":"DELETE", "path":"/Users/e9025315-6bea-44e1-899c-1e07454e468b", "version":"W\/\"0ee8add0a938e1a\"" } ] } The Service Provider returns the following response. Drake, et al. [Page 30] =0C draft-scim-api-01 July 2012 HTTP/1.1 200 OK Content-Type: application/json { "schemas": [ "urn:scim:schemas:core:1.0" ], "Operations": [ { "location": = "https://example.com/v1/Users/92b725cd-9465-4e7d-8c16-01f8e146b87a", "method": "POST", "bulkId": "qwerty", "version": "W\/\"oY4m4wn58tkVjJxK\"", "status": { "code": "201" } }, { "location": = "https://example.com/v1/Users/b7c14771-226c-4d05-8860-134711653041", "method": "PUT", "version": "W\/\"huJj29dMNgu3WXPD\"", "status": { "code": "200" } }, { "location": = "https://example.com/v1/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", "method": "PATCH", "version": "W\/\"huJj29dMNgu3WXPD\"", "status": { "code": "200" } }, { "location": = "https://example.com/v1/Users/e9025315-6bea-44e1-899c-1e07454e468b", "method": "DELETE", "status": { "code": "200" } } ] } The following response is returned if an error occurred when attempting to create the User 'Alice'. The Service Provider stops processing the bulk operation and immediately returns a response to the Consumer. The response contains the error and any successful results prior to the error. Drake, et al. [Page 31] =0C draft-scim-api-01 July 2012 HTTP/1.1 200 OK Content-Type: application/json { "schemas": [ "urn:scim:schemas:core:1.0" ], "Operations": [ { "method": "POST", "bulkId": "qwerty", "status": { "code": "400", "description": "Request is unparseable, syntactically incorrect, = or violates schema." } } ] } If the failOnErrors attribute is not specified or the Service Provider has not reached the error limit defined by the Consumer the Service Provider will continue to process all operations. The following is an example in which all operations failed. Drake, et al. [Page 32] =0C draft-scim-api-01 July 2012 HTTP/1.1 200 OK Content-Type: application/json { "schemas": [ "urn:scim:schemas:core:1.0" ], "Operations": [ { "method": "POST", "bulkId": "qwerty", "status": { "code": "400", "description": "Request is unparseable, syntactically incorrect, = or violates schema." } }, { "location": = "https://example.com/v1/Users/b7c14771-226c-4d05-8860-134711653041", "method": "PUT", "status": { "code": "412", "description": "Failed to update as user changed on the server = since you last retrieved it." } }, { "location": = "https://example.com/v1/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", "method": "PATCH", "status": { "code": "412", "description": "Failed to update as user changed on the server = since you last retrieved it." } }, { "location": = "https://example.com/v1/Users/e9025315-6bea-44e1-899c-1e07454e468b", "method": "DELETE", "status": { "code": "404", "description": "Specified resource; e.g., User, does not exist." } } ] } The Consumer can, within one bulk operation, create a new User, a new Group and add the newly created User to the newly created Group. In order to add the new User to the Group the Consumer must use the surrogate id attribute, bulkId, to reference the User. The bulkId attribute value must be pre-pended with the literal "bulkId:"; e.g., Drake, et al. [Page 33] =0C draft-scim-api-01 July 2012 if the bulkId is 'qwerty' the value is "bulkId:qwerty". The Service Provider MUST replace the string "bulkId:qwerty" with the permanent Resource id once created. The following example creates a User with the userName 'Alice' and a Group with the displayName 'Tour Guides' with Alice as a member. POST /v1/Bulk Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 Content-Length: ... { "schemas": [ "urn:scim:schemas:core:1.0" ], "Operations": [ { "method": "POST", "path": "/Users", "bulkId": "qwerty", "data": { "schemas": [ "urn:scim:schemas:core:1.0" ], "userName": "Alice" } }, { "method": "POST", "path": "/Groups", "bulkId": "ytrewq", "data": { "schemas": [ "urn:scim:schemas:core:1.0" ], "displayName": "Tour Guides", "members": [ { "type": "user", "value": "bulkId:qwerty" } ] } } Drake, et al. [Page 34] =0C draft-scim-api-01 July 2012 ] } The Service Provider returns the following response. HTTP/1.1 200 OK Content-Type: application/json { "schemas": [ "urn:scim:schemas:core:1.0" ], "Operations": [ { "location": = "https://example.com/v1/Users/92b725cd-9465-4e7d-8c16-01f8e146b87a", "method": "POST", "bulkId": "qwerty", "version": "W\/\"4weymrEsh5O6cAEK\"", "status": { "code": "201" } }, { "location": = "https://example.com/v1/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a", "method": "POST", "bulkId": "ytrewq", "version": "W\/\"lha5bbazU3fNvfe5\"", "status": { "code": "201" } } ] } A subsequent request for the 'Tour Guides' Group ('e9e30dba-f08f- 4109-8486-d5c6a331660a') returns the following: GET /v1/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 Drake, et al. [Page 35] =0C draft-scim-api-01 July 2012 HTTP/1.1 200 OK Content-Type: application/json Location: = https://example.com/v1/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a ETag: W/"lha5bbazU3fNvfe5" { "schemas":["urn:scim:schemas:core:1.0"], "id": "e9e30dba-f08f-4109-8486-d5c6a331660a", "displayName": "Tour Guides", "meta": { "created":"2011-08-01T18:29:49.793Z", "lastModified":"2011-08-01T20:31:02.315Z", "location": = "https://example.com/v1/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a", "version": "W\/\"lha5bbazU3fNvfe5\"" }, "members": [ { "value": "92b725cd-9465-4e7d-8c16-01f8e146b87a", "type": "user" } ] } Extensions that include references to other Resources MUST be handled in the same way by the Service Provider. The following example uses the bulkId attribute within the enterprise extension managerId attribute. Drake, et al. [Page 36] =0C draft-scim-api-01 July 2012 POST /v1/Bulk Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 Content-Length: ... { "schemas": [ "urn:scim:schemas:core:1.0" ], "Operations": [ { "method": "POST", "path": "/Users", "bulkId": "qwerty", "data": { "schemas": [ "urn:scim:schemas:core:1.0" ], "userName": "Alice" } }, { "method": "POST", "path": "/Users", "bulkId": "ytrewq", "data": { "schemas": [ "urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:enterprise:1.0" ], "userName": "Bob", "urn:scim:schemas:extension:enterprise:1.0": { "employeeNumber": "11250", "manager": { "managerId": "batchId:qwerty", "displayName": "Alice" } } } } ] } The Service Provider MUST try to resolve circular cross references between Resources in a single bulk job but MAY stop after a failed attempt and instead return the status code 409 Conflict. The Drake, et al. [Page 37] =0C draft-scim-api-01 July 2012 following example exhibits the potential conflict. Drake, et al. [Page 38] =0C draft-scim-api-01 July 2012 POST /v1/Bulk Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 Content-Length: ... { "schemas": [ "urn:scim:schemas:core:1.0" ], "Operations": [ { "method": "POST", "path": "/Groups", "bulkId": "qwerty", "data": { "schemas": [ "urn:scim:schemas:core:1.0" ], "displayName": "Group A", "members": [ { "type": "group", "value": "bulkId:ytrewq" } ] } }, { "method": "POST", "path": "/Groups", "bulkId": "ytrewq", "data": { "schemas": [ "urn:scim:schemas:core:1.0" ], "displayName": "Group B", "members": [ { "type": "group", "value": "bulkId:qwerty" } ] } } ] } Drake, et al. [Page 39] =0C draft-scim-api-01 July 2012 If the Service Provider resolved the above circular references the following is returned from a subsequent GET request. GET /v1/Groups?filter=3DdisplayName sw 'Group' Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 HTTP/1.1 200 OK Content-Type: application/json { "totalResults": 2, "schemas": [ "urn:scim:schemas:core:1.0" ], "Resources": [ { "id": "c3a26dd3-27a0-4dec-a2ac-ce211e105f97", "schemas": [ "urn:scim:schemas:core:1.0" ], "displayName": "Group A", "meta": { "created":"2011-08-01T18:29:49.793Z", "lastModified":"2011-08-01T18:29:51.135Z", = "location":"https://example.com/v1/Groups/c3a26dd3-27a0-4dec-a2ac-ce211e10= 5f97", "version":"W\/\"mvwNGaxB5SDq074p\"" }, "members": [ { "value": "6c5bb468-14b2-4183-baf2-06d523e03bd3", "type": "group" } ] }, { "id": "6c5bb468-14b2-4183-baf2-06d523e03bd3", "schemas": [ "urn:scim:schemas:core:1.0" ], "displayName": "Group B", "meta": { "created":"2011-08-01T18:29:50.873Z", "lastModified":"2011-08-01T18:29:50.873Z", Drake, et al. [Page 40] =0C draft-scim-api-01 July 2012 = "location":"https://example.com/v1/Groups/6c5bb468-14b2-4183-baf2-06d523e0= 3bd3", "version":"W\/\"wGB85s2QJMjiNnuI\"" }, "members": [ { "value": "c3a26dd3-27a0-4dec-a2ac-ce211e105f97", "type": "group" } ] } ] } The Service Provider MUST define the maximum number of operations and maximum payload size a Consumer may send in a single request. If either limits are exceeded the Service Provider MUST return the HTTP response code 413 Request Entity Too Large. The returned response MUST specify the limit exceeded in the body of the error response. The following example the Consumer sent a request exceeding the Service Provider's max payload size of 1 megabyte. POST /v1/Bulk Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 Content-Length: 4294967296 ... HTTP/1.1 413 Request Entity Too Large Content-Type: application/json Location: https://example.com/v1/Bulk/yfCrVJhFIJagAHj8 { "Errors":[ { "description":"The size of the bulk operation exceeds the = maxPayloadSize (1048576).", "code":"413" } ] } Drake, et al. [Page 41] =0C draft-scim-api-01 July 2012 3.6. Data Input/Output Formats Consumers MUST specify the format in which the data is submitted via the HTTP header content-type and MAY specify the desired response data format via an HTTP Accept Header; e.g.,"Accept: application/ json" or via URI suffix; e.g., GET /Users/2819c223-7f76-453a-919d-413861904646.json Host: example.com GET /Users/2819c223-7f76-453a-919d-413861904646.xml Host: example.com Service Providers MUST support the Accept Headers "Accept: application/json" for JSON [5] and, if supported, "Accept: application/xml" for XML [6]. The format defaults to JSON if no format is specified. The data structure returned is equivalent in both formats; the only difference is in the encoding of the data. Singular attributes are encoded as string name-value-pairs in JSON; e.g., "attribute": "value" and elements in XML; e.g., value Multi-valued attributes in JSON are encoded as arrays; e.g., "attributes": [ "value1", "value2" ] and repeated tags in XML; e.g., value1 value2 Elements with nested elements are represented as objects in JSON; e.g, "attribute": { "subattribute1": "value1", "subattribute2": "value2" } and repeated tags in XML; e.g., value1 value2 Drake, et al. [Page 42] =0C draft-scim-api-01 July 2012 3.7. Additional retrieval query parameters Consumers MAY request a partial Resource representation on any operation that returns a Resource within the response by specifying the URL query parameter 'attributes'. When specified, each Resource returned MUST contain the minimal set of Resource attributes and, MUST contain no other attributes or Sub-Attributes than those explicitly requested. The query parameter attributes value is a comma separated list of Resource attribute names in standard, attribute notation (Section 3.8) form (e.g. userName, name, emails). GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=3DuserName Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 Giving the response HTTP/1.1 200 OK Content-Type: application/json Location: = https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 ETag: W/"a330bc54f0671c9" { "schemas":["urn:scim:schemas:core:1.0"], "id":"2819c223-7f76-453a-919d-413861904646", "userName":"bjensen", "meta":{ "created":"2011-08-01T18:29:49.793Z", "lastModified":"2011-08-01T18:29:49.793Z", = "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904= 646", "version":"W\/\"a330bc54f0671c9\"" } } 3.8. Attribute Notation All operations share a common scheme for referencing simple and complex attributes. In general, attributes are identified by prefixing the attribute name with its schema URN separated by a ':' character; e.g., the core User Resource attribute 'userName' is identified as 'urn:scim:schemas:core:1.0:userName'. Consumers MAY omit core schema attribute URN prefixes though MUST fully qualify Drake, et al. [Page 43] =0C draft-scim-api-01 July 2012 extended attributes with the associated Resource URN; e.g., the attribute 'age' defined in 'urn:hr:schemas:user' is fully encoded as 'urn:hr:schemas:user:age'. A Complex attributes' Sub-Attributes are referenced via nested, dot ('.') notation; i.e., {urn}:{Attribute name}.{Sub-Attribute name}. For example, the fully qualified path for a User's givenName is urn:scim:schemas:core:1.0:name.givenName All facets (URN, attribute and Sub-Attribute name) of the fully encoded Attribute name are case insensitive. 3.9. HTTP Response Codes The SCIM Protocol uses the response status codes defined in HTTP [7] to indicate operation success or failure. In addition to returning a HTTP response code implementers MUST return the errors in the body of the response in the client requested format containing the error response and, per the HTTP specification, human-readable explanations. Implementers SHOULD handle the identified errors as described below. +--------------+---------------------------+------------------------+ | Code | Applicability | Suggested Explanation | +--------------+---------------------------+------------------------+ | 400 BAD | GET,POST,PUT,PATCH,DELETE | Request is | | REQUEST | | unparseable, | | | | syntactically | | | | incorrect, or violates | | | | schema | | | | | | 401 | GET,POST,PUT,PATCH,DELETE | Authorization failure | | UNAUTHORIZED | | | | | | | | 403 | GET,POST,PUT,PATCH,DELETE | Server does not | | FORBIDDEN | | support requested | | | | operation | | | | | | 404 NOT | GET,PUT,PATCH,DELETE | Specified resource; | | FOUND | | e.g., User, does not | | | | exist | | | | | | 409 CONFLICT | POST, PUT,PATCH,DELETE | The specified version | | | | number does not match | | | | the resource's latest | | | | version number or a | | | | Service Provider | | | | refused to create a | | | | new, duplicate | | | | resource | | | | | Drake, et al. [Page 44] =0C draft-scim-api-01 July 2012 | 412 | PUT,PATCH,DELETE | Failed to update as | | PRECONDITION | | Resource {id} changed | | FAILED | | on the server last | | | | retrieved | | | | | | 413 REQUEST | POST | {"maxOperations": | | ENTITY TOO | | 1000,"maxPayload": | | LARGE | | 1048576} | | | | | | 500 INTERNAL | GET,POST,PUT,PATCH,DELETE | An internal error. | | SERVER ERROR | | Implementers SHOULD | | | | provide descriptive | | | | debugging advice | | | | | | 501 NOT | GET,POST,PUT,PATCH,DELETE | Service Provider does | | IMPLEMENTED | | not support the | | | | request operation; | | | | e.g., PATCH | +--------------+---------------------------+------------------------+ Table 7: Defined error cases Error example in response to a non-existent GET request. HTTP/1.1 404 NOT FOUND { "Errors":[ { "description":"Resource 2819c223-7f76-453a-919d-413861904646 not = found", "code":"404" } ] } 3.10. API Versioning The Base URL MAY be appended with a version identifier as a separate segment in the URL path. At this time the only valid identifier is 'v1'. If specified, the version identifier MUST appear in the URL path immediately preceding the Resource endpoint and conform to the following scheme: the character 'v' followed by the desired SCIM version number; e.g., a version 'v1' User request is specified as /v1/Users. When specified Service Providers MUST perform the operation using the desired version or reject the request. When omitted Service Providers SHOULD perform the operation using the most recent API supported by the Service Provider. Drake, et al. [Page 45] =0C draft-scim-api-01 July 2012 3.11. Versioning Resources The API supports resource versioning via standard,HTTP ETags. Service providers MAY support weak ETags as the preferred mechanism for performing conditional retrievals and ensuring Consumers do not inadvertently overwrite each others changes, respectively. When supported SCIM ETags MUST be specified as an HTTP header and SHOULD be specified within the 'version' attribute contained in the Resource's 'meta' attribute. Example: POST /Users HTTP/1.1 Host: example.com Content-Type: application/json Authorization: Bearer h480djs93hd8 Content-Length: ... { "schemas":["urn:scim:schemas:core:1.0"], "userName":"bjensen", "externalId":"bjensen", "name":{ "formatted":"Ms. Barbara J Jensen III", "familyName":"Jensen", "givenName":"Barbara" } } The server responds with an ETag in the response header and meta structure. Drake, et al. [Page 46] =0C draft-scim-api-01 July 2012 HTTP/1.1 201 Created Content-Type: application/json Location: = https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 ETag: W/"e180ee84f0671b1" { "schemas":["urn:scim:schemas:core:1.0"], "id":"2819c223-7f76-453a-919d-413861904646", "meta":{ "created":"2011-08-01T21:32:44.882Z", "lastModified":"2011-08-01T21:32:44.882Z", = "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904= 646", "version":"W\/\"e180ee84f0671b1\"" }, "name":{ "formatted":"Ms. Barbara J Jensen III", "familyName":"Jensen", "givenName":"Barbara" }, "userName":"bjensen" } With the returned ETag, Consumers MAY choose to retrieve the Resource only if the Resource has been modified. Conditional retrieval example using If-None-Match header: GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=3DdisplayName= Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 If-None-Match: W/"e180ee84f0671b1" If the Resource has not changed the Service Provider simply returns an empty body with a 304 "Not Modified" response code. If the Service Providers supports versioning of resources the Consumer MUST supply an If-Match header for PUT and PATCH operations to ensure that the requested operation succeeds only if the supplied ETag matches the latest Service Provider Resource; e.g., If-Match: W/"e180ee84f0671b1" 3.12. HTTP Method Overloading In recognition that some clients, servers and firewalls prevent PUT, PATCH and DELETE operations a client MAY override the POST operation by specifying the custom header "X-HTTP-Method-Override" with the Drake, et al. [Page 47] =0C draft-scim-api-01 July 2012 desired PUT, PATCH, DELETE operation. For example: POST /Users/2819c223-7f76-453a-919d-413861904646 X-HTTP-Method-Override: DELETE Drake, et al. [Page 48] =0C draft-scim-api-01 July 2012 4. Security Considerations The SCIM Protocol is based on HTTP and thus subject to the security considerations found in Section 15 of [RFC2616]. SCIM Resources (e.g., Users and Groups) can contain sensitive information. Therefore, SCIM Consumers and Service Providers MUST implement TLS. Which version(s) ought to be implemented will vary over time, and depend on the widespread deployment and known security vulnerabilities at the time of implementation. At the time of this writing, TLS version 1.2 [RFC5246 [8]] is the most recent version, but has very limited actual deployment, and might not be readily available in implementation toolkits. TLS version 1.0 [RFC2246 [8]] is the most widely deployed version, and will give the broadest interoperability. Drake, et al. [Page 49] =0C draft-scim-api-01 July 2012 5. Contributors Samuel Erdtman (samuel@erdtman.se) Patrick Harding (pharding@pingidentity.com) Drake, et al. [Page 50] =0C draft-scim-api-01 July 2012 6. Acknowledgments The editor would like to thank the participants in the the SCIM working group for their support of this specification. Drake, et al. [Page 51] =0C draft-scim-api-01 July 2012 Authors' Addresses Trey Drake (editor) UnboundID Email: trey.drake@unboundid.com Chuck Mortimore SalesForce Email: cmortimore@salesforce.com Morteza Ansari Cisco Email: morteza.ansari@cisco.com Kelly Grizzle SailPoint Email: kelly.grizzle@sailpoint.com Erik Wahlstroem Technology Nexus Email: erik.wahlstrom@nexussafe.com Drake, et al. [Page 52] =0C --Apple-Mail=_19FFEAC6-A1D7-4DDC-818F-22E497C6FAE7-- From leifj@mnt.se Fri Jul 13 10:45:35 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B1C11E80A3 for ; Fri, 13 Jul 2012 10:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.015 X-Spam-Level: X-Spam-Status: No, score=-3.015 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XeP990ijQZsz for ; Fri, 13 Jul 2012 10:45:34 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id D67C611E8087 for ; Fri, 13 Jul 2012 10:45:32 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q6DHk0Eh019770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jul 2012 19:46:06 +0200 (CEST) Message-ID: <50005ED8.1010900@mnt.se> Date: Fri, 13 Jul 2012 19:46:00 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: cloud-directory@googlegroups.com, scim WG References: <89400D61-3678-4110-B4E4-29B856F38CE5@unboundid.com> In-Reply-To: <89400D61-3678-4110-B4E4-29B856F38CE5@unboundid.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [scim] SCIM 1.1 posted to IETF X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 17:45:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/13/2012 05:49 AM, Trey Drake wrote: > FYI: the 1.1 protocol and schema specifications have been submitted > to the IETF. They ought to, eventually, show up here > https://datatracker.ietf.org/wg/scim/. > > Thanks, Trey > They will show up there when (or more formally if) the WG adopts these as wg documents. That is also when the issue tracker will appear. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAAXtQACgkQ8Jx8FtbMZnev6wCdEGWT/8NxBn1XHe3oWJMoXPzv Lw0An3fTRXvzoE2I4m0vDZZYF0oO7tV3 =St7g -----END PGP SIGNATURE----- From phil.hunt@oracle.com Fri Jul 13 11:14:54 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F8E11E80B7 for ; Fri, 13 Jul 2012 11:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.306 X-Spam-Level: X-Spam-Status: No, score=-10.306 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilYNMXbcC6Xt for ; Fri, 13 Jul 2012 11:14:53 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id E96C011E80A6 for ; Fri, 13 Jul 2012 11:14:52 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6DIFSHR013418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Jul 2012 18:15:29 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6DIFRfE029969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jul 2012 18:15:27 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6DIFQXH019819; Fri, 13 Jul 2012 13:15:26 -0500 Received: from [192.168.1.200] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 13 Jul 2012 11:15:26 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <4FFEC5C1.8060609@mnt.se> Date: Fri, 13 Jul 2012 11:15:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <59E377B8-389E-4328-8809-8C3D20B0497F@oracle.com> References: <4FFEC5C1.8060609@mnt.se> To: Leif Johansson X-Mailer: Apple Mail (2.1278) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: scim WG Subject: Re: [scim] draft agenda for Vancouver X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 18:14:54 -0000 It doesn't have to be a formal session, but I would like to discuss the = following topics (possibly during the open mic): * Searching without using URLs (e.g. due to privacy and injection attack = considerations) * Is minimum (GET/POST) REST profile needed? * Using PUT to support Add/Replace since they are identical save for = entity URL Another topic of general exploration is: * Reverse provisioning use case discussion Is this a big deal? Or will it have to wait for the next charter? Targeting: * Do we need an explicit extension, or should we just role the schema = change into the core schema (to support linking related User entities) = with appropriate modification of the core api spec clarifying extended = path support as an alternative. SCIM As General purpose IDMaaS: * Example, allowing OAuth enabled client devices to update attributes in = a person's profile. Important Note: some of these topics may be a case of acknowledging the = case and deciding stuff that can't be supported within the current = charter. I do not want to argue for a change in scope, but really talk = more about use cases and limit expectations appropriately. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-07-12, at 5:40 AM, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 > Here is a draft agenda for Vancouver. Please help us fill this > in by suggesting things we missed or volunteering to present. >=20 > - - Agenda bashing and IETF Note Well > - - Chairs Introduction to the WG > - - SCIM 1.1 overview and document status (volunteers welcome!) > - - Technical discussion and open Mic >=20 > We have 2 hours on Friday morning so make sure not to leave early! >=20 > For those who are new to the IETF I suggest reading the Tao of > the IETF: http://www.ietf.org/tao.html >=20 > Note that on this our first WG meeting we will try to devote a little > bit of time to level-set and introduction but during future meetings > we will focus increasingly on resolving technical issues so if you are > curious about SCIM this is the time to get involved! >=20 > Morteza and Leif > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAk/+xcEACgkQ8Jx8FtbMZnfhwQCfW48IetBbBDb4FqZLsHI1D7vC > XgYAoI+39hyFZhDHXV30aoSgIgdHy4Ql > =3D+7V9 > -----END PGP SIGNATURE----- > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From leifj@mnt.se Fri Jul 13 12:19:15 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DFD21F8648 for ; Fri, 13 Jul 2012 12:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.985 X-Spam-Level: X-Spam-Status: No, score=-2.985 tagged_above=-999 required=5 tests=[AWL=-0.386, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEfMUz5yg1zD for ; Fri, 13 Jul 2012 12:19:10 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 47BB821F8609 for ; Fri, 13 Jul 2012 12:19:10 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q6DJJeja009206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jul 2012 21:19:45 +0200 (CEST) Message-ID: <500074CC.8000707@mnt.se> Date: Fri, 13 Jul 2012 21:19:40 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Phil Hunt References: <4FFEC5C1.8060609@mnt.se> <59E377B8-389E-4328-8809-8C3D20B0497F@oracle.com> In-Reply-To: <59E377B8-389E-4328-8809-8C3D20B0497F@oracle.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: scim WG Subject: Re: [scim] draft agenda for Vancouver X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 19:19:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/13/2012 08:15 PM, Phil Hunt wrote: > It doesn't have to be a formal session, but I would like to discuss > the following topics (possibly during the open mic): > Do you think you could put together a few slides to get the discussion started? > * Searching without using URLs (e.g. due to privacy and injection > attack considerations) * Is minimum (GET/POST) REST profile > needed? * Using PUT to support Add/Replace since they are identical > save for entity URL > > Another topic of general exploration is: * Reverse provisioning use > case discussion Is this a big deal? Or will it have to wait for the > next charter? > > Targeting: * Do we need an explicit extension, or should we just > role the schema change into the core schema (to support linking > related User entities) with appropriate modification of the core > api spec clarifying extended path support as an alternative. > > SCIM As General purpose IDMaaS: * Example, allowing OAuth enabled > client devices to update attributes in a person's profile. > > Important Note: some of these topics may be a case of acknowledging > the case and deciding stuff that can't be supported within the > current charter. I do not want to argue for a change in scope, but > really talk more about use cases and limit expectations > appropriately. > > Phil > > @independentid www.independentid.com phil.hunt@oracle.com > > > > > > On 2012-07-12, at 5:40 AM, Leif Johansson wrote: > > > Here is a draft agenda for Vancouver. Please help us fill this in > by suggesting things we missed or volunteering to present. > > - Agenda bashing and IETF Note Well - Chairs Introduction to the > WG - SCIM 1.1 overview and document status (volunteers welcome!) - > Technical discussion and open Mic > > We have 2 hours on Friday morning so make sure not to leave early! > > For those who are new to the IETF I suggest reading the Tao of the > IETF: http://www.ietf.org/tao.html > > Note that on this our first WG meeting we will try to devote a > little bit of time to level-set and introduction but during future > meetings we will focus increasingly on resolving technical issues > so if you are curious about SCIM this is the time to get involved! > > Morteza and Leif >> _______________________________________________ scim mailing >> list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAAdMgACgkQ8Jx8FtbMZnd3EACdEa7HUAIgiRK86xXk6Z06HZGc QugAniySGYwfzc9G1bQhMEQ/SnA5Uw54 =KRSG -----END PGP SIGNATURE----- From phil.hunt@oracle.com Fri Jul 13 12:24:05 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6070E21F8798 for ; Fri, 13 Jul 2012 12:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.618 X-Spam-Level: X-Spam-Status: No, score=-9.618 tagged_above=-999 required=5 tests=[AWL=-0.415, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0OMMhcV5+xq for ; Fri, 13 Jul 2012 12:24:03 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB0F21F8792 for ; Fri, 13 Jul 2012 12:24:00 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6DJOZgW026659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Jul 2012 19:24:35 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6DJOYBn007688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jul 2012 19:24:34 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6DJOYlE019684; Fri, 13 Jul 2012 14:24:34 -0500 Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 13 Jul 2012 12:24:34 -0700 References: <4FFEC5C1.8060609@mnt.se> <59E377B8-389E-4328-8809-8C3D20B0497F@oracle.com> <500074CC.8000707@mnt.se> In-Reply-To: <500074CC.8000707@mnt.se> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B206) From: Phil Hunt Date: Fri, 13 Jul 2012 12:24:33 -0700 To: Leif Johansson X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: scim WG Subject: Re: [scim] draft agenda for Vancouver X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 19:24:05 -0000 Sure.=20 Also re targeting. I think we should have a combined targeting graph api dis= cussion re Kim Cameron's recent thoughts on scim and graph.=20 Phil On 2012-07-13, at 12:19, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 07/13/2012 08:15 PM, Phil Hunt wrote: >> It doesn't have to be a formal session, but I would like to discuss >> the following topics (possibly during the open mic): >>=20 >=20 > Do you think you could put together a few slides to get the discussion > started? >=20 >> * Searching without using URLs (e.g. due to privacy and injection >> attack considerations) * Is minimum (GET/POST) REST profile >> needed? * Using PUT to support Add/Replace since they are identical >> save for entity URL >>=20 >> Another topic of general exploration is: * Reverse provisioning use >> case discussion Is this a big deal? Or will it have to wait for the >> next charter? >>=20 >> Targeting: * Do we need an explicit extension, or should we just >> role the schema change into the core schema (to support linking >> related User entities) with appropriate modification of the core >> api spec clarifying extended path support as an alternative. >>=20 >> SCIM As General purpose IDMaaS: * Example, allowing OAuth enabled >> client devices to update attributes in a person's profile. >>=20 >> Important Note: some of these topics may be a case of acknowledging >> the case and deciding stuff that can't be supported within the >> current charter. I do not want to argue for a change in scope, but >> really talk more about use cases and limit expectations >> appropriately. >>=20 >> Phil >>=20 >> @independentid www.independentid.com phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2012-07-12, at 5:40 AM, Leif Johansson wrote: >>=20 >>=20 >> Here is a draft agenda for Vancouver. Please help us fill this in >> by suggesting things we missed or volunteering to present. >>=20 >> - Agenda bashing and IETF Note Well - Chairs Introduction to the >> WG - SCIM 1.1 overview and document status (volunteers welcome!) - >> Technical discussion and open Mic >>=20 >> We have 2 hours on Friday morning so make sure not to leave early! >>=20 >> For those who are new to the IETF I suggest reading the Tao of the >> IETF: http://www.ietf.org/tao.html >>=20 >> Note that on this our first WG meeting we will try to devote a >> little bit of time to level-set and introduction but during future >> meetings we will focus increasingly on resolving technical issues >> so if you are curious about SCIM this is the time to get involved! >>=20 >> Morteza and Leif >>> _______________________________________________ scim mailing >>> list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim >>=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAlAAdMgACgkQ8Jx8FtbMZnd3EACdEa7HUAIgiRK86xXk6Z06HZGc > QugAniySGYwfzc9G1bQhMEQ/SnA5Uw54 > =3DKRSG > -----END PGP SIGNATURE----- From michael.hammer@yaanatech.com Fri Jul 13 14:05:46 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2098B11E80FD for ; Fri, 13 Jul 2012 14:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbxszV0tz3nB for ; Fri, 13 Jul 2012 14:05:45 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 3408E11E8097 for ; Fri, 13 Jul 2012 14:05:45 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Fri, 13 Jul 2012 14:06:22 -0700 From: Michael Hammer To: "trey.drake@unboundid.com" Thread-Topic: [scim] SCIM drafts Thread-Index: AQHNYF/cWws3NXZV/Umxji7Z130xrpcnsfTg Date: Fri, 13 Jul 2012 21:06:20 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB38C2FCC@EX2K10MB1.corp.yaanatech.com> References: <93E72F4B-CFE4-4F43-897C-FB7B0F8B2050@unboundid.com> In-Reply-To: <93E72F4B-CFE4-4F43-897C-FB7B0F8B2050@unboundid.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.2] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_019D_01CD6119.D26F0420" MIME-Version: 1.0 Cc: "scim@ietf.org" , "moransar@cisco.com" Subject: Re: [scim] SCIM drafts X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 21:05:46 -0000 ------=_NextPart_000_019D_01CD6119.D26F0420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Trey, I have a nit about the elements: emails, phoneNumbers, ims, photos, addresses, etc. Is there a reason those have to be put in the plural? (Understand these are multivalued, but that will be obvious.) Maybe I am brainwashed, but when I saw ims I was thinking 3GPP IMS and was looking for the sip: addressing type. :) Which also begs the question, does the IETF buy into the idea that all "phones" will be E.164 based only? Also, for the next thousand internet applications, do we expect a new extension for an identity for each? Could there be some type of generic URI extension, where an attribute holds the already defined applications types? "genericURI": [ { "value": "user@domain", "app-type": "sip:" }, { "value": "object@domain", "app-type": "http:" } Or, whatever. Mike -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Trey Drake Sent: Thursday, July 12, 2012 2:55 PM To: internet-drafts@ietf.org Cc: scim@ietf.org Management; Morteza Ansari (moransar) Subject: [scim] SCIM drafts The attached contain the SCIM "1.1" protocol and schema drafts for consideration by the SCIM working group. Thanks, Trey ------=_NextPart_000_019D_01CD6119.D26F0420 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcx MzIxMDYxOVowIwYJKoZIhvcNAQkEMRYEFDLIIADQC3BtVFIhiFb9IPp3xGClMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAcA1vnkPDb0gvzEVRiF4Yz+5hUNmNIcwETjx//jlsH/Nh apYOroFopqrGi7szgv9tgAf3N30D42SEv5Y8VAH8KJwFOy02sn7FVfgNIg98OfHF+avy+jmNyP0b 3SrLWYJgG3DSpRNj6wn3jqlHCp3vZiZSR3hIG6FRJmTodbsS984AAAAAAAA= ------=_NextPart_000_019D_01CD6119.D26F0420-- From igor.faynberg@alcatel-lucent.com Fri Jul 13 14:13:41 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C380311E80FF for ; Fri, 13 Jul 2012 14:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.932 X-Spam-Level: X-Spam-Status: No, score=-7.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4t6Eqg-bVcya for ; Fri, 13 Jul 2012 14:13:41 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 0D94411E8097 for ; Fri, 13 Jul 2012 14:13:40 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q6DLEFOR009932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 13 Jul 2012 16:14:15 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q6DLEEGB012180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 13 Jul 2012 16:14:15 -0500 Received: from [135.222.232.88] ([135.222.232.88]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q6DLEEuM024549; Fri, 13 Jul 2012 16:14:14 -0500 (CDT) Message-ID: <50008FAB.2080903@alcatel-lucent.com> Date: Fri, 13 Jul 2012 17:14:19 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: scim@ietf.org References: <93E72F4B-CFE4-4F43-897C-FB7B0F8B2050@unboundid.com> <00C069FD01E0324C9FFCADF539701DB38C2FCC@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB38C2FCC@EX2K10MB1.corp.yaanatech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [scim] SCIM drafts X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 21:13:42 -0000 On 7/13/2012 5:06 PM, Michael Hammer wrote: > ... > Which also begs the question, does the IETF buy into the idea that all > "phones" will be E.164 based only? As opposed to...? Igor From michael.hammer@yaanatech.com Fri Jul 13 14:35:51 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B5F11E80BF for ; Fri, 13 Jul 2012 14:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJTAwVDIeSAH for ; Fri, 13 Jul 2012 14:35:50 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2F511E80AD for ; Fri, 13 Jul 2012 14:35:50 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Fri, 13 Jul 2012 14:36:28 -0700 From: Michael Hammer To: "igor.faynberg@alcatel-lucent.com" , "scim@ietf.org" Thread-Topic: [scim] SCIM drafts Thread-Index: AQHNYF/cWws3NXZV/Umxji7Z130xrpcnsfTggAB7k4D//5B6QA== Date: Fri, 13 Jul 2012 21:36:27 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB38C301E@EX2K10MB1.corp.yaanatech.com> References: <93E72F4B-CFE4-4F43-897C-FB7B0F8B2050@unboundid.com> <00C069FD01E0324C9FFCADF539701DB38C2FCC@EX2K10MB1.corp.yaanatech.com> <50008FAB.2080903@alcatel-lucent.com> In-Reply-To: <50008FAB.2080903@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.2] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01AE_01CD611E.06E5D090" MIME-Version: 1.0 Subject: Re: [scim] SCIM drafts X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 21:35:51 -0000 ------=_NextPart_000_01AE_01CD611E.06E5D090 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Try a non-E.164-based URI. Ever use Skype or a softphone? Mike -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Igor Faynberg Sent: Friday, July 13, 2012 5:14 PM To: scim@ietf.org Subject: Re: [scim] SCIM drafts On 7/13/2012 5:06 PM, Michael Hammer wrote: > ... > Which also begs the question, does the IETF buy into the idea that all > "phones" will be E.164 based only? As opposed to...? Igor _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim ------=_NextPart_000_01AE_01CD611E.06E5D090 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcx MzIxMzYyNVowIwYJKoZIhvcNAQkEMRYEFOMIBVorgKlCnyP8vEMJhvqi4vTaMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAJ7x3As3z8Nnaz6nvkCVq318gy6872o4p31vgajzPv0+r ow/slH8uAWkT+7Bf+H6fm7SfeLy4Rj6zBpkkFRZ2s2cgRqdzZ1GRooonNPfPP/cotP7/tM0xsWv6 qD0Uyg1zP2wBkERG53oZv0fR1/pNFiUX0QN4r+4ggMPKIw4/M4kAAAAAAAA= ------=_NextPart_000_01AE_01CD611E.06E5D090-- From igor.faynberg@alcatel-lucent.com Fri Jul 13 15:13:00 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A8811E8121 for ; Fri, 13 Jul 2012 15:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBXXFTQIHxeW for ; Fri, 13 Jul 2012 15:12:59 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id E03B611E8102 for ; Fri, 13 Jul 2012 15:12:58 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q6DMDZSt005346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Jul 2012 17:13:35 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q6DMDZlK018377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Jul 2012 17:13:35 -0500 Received: from [135.222.232.88] (USMUYN0L055118.mh.lucent.com [135.222.232.88] (may be forged)) by umail.lucent.com (8.13.8/TPES) with ESMTP id q6DMDYlK001164; Fri, 13 Jul 2012 17:13:34 -0500 (CDT) Message-ID: <50009D9A.9070005@alcatel-lucent.com> Date: Fri, 13 Jul 2012 18:13:46 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Michael Hammer References: <93E72F4B-CFE4-4F43-897C-FB7B0F8B2050@unboundid.com> <00C069FD01E0324C9FFCADF539701DB38C2FCC@EX2K10MB1.corp.yaanatech.com> <50008FAB.2080903@alcatel-lucent.com> <00C069FD01E0324C9FFCADF539701DB38C301E@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB38C301E@EX2K10MB1.corp.yaanatech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "scim@ietf.org" Subject: Re: [scim] SCIM drafts X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 22:13:00 -0000 Yes, now I understand. (I admit I never used Skype or a sophtphone for making calls that did not end up on PSTN--hence the initial confusion). But I thought that in the scope of SCIM, "phone" implied the E.164 numbering scheme. To this end, the IETF has actually spent a lot of time dealing with it (staring in PINT, but mostly, of course, in ENUM). Of course, the authors of the draft should correct me if I am wrong. Igor On 7/13/2012 5:36 PM, Michael Hammer wrote: > Try a non-E.164-based URI. > > Ever use Skype or a softphone? > > Mike > > > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Igor > Faynberg > Sent: Friday, July 13, 2012 5:14 PM > To: scim@ietf.org > Subject: Re: [scim] SCIM drafts > > > > On 7/13/2012 5:06 PM, Michael Hammer wrote: >> ... >> Which also begs the question, does the IETF buy into the idea that all >> "phones" will be E.164 based only? > As opposed to...? > > Igor > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From michael.hammer@yaanatech.com Fri Jul 13 15:15:01 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCD511E8121 for ; Fri, 13 Jul 2012 15:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVWUwu2V1x8F for ; Fri, 13 Jul 2012 15:15:01 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id F240911E8102 for ; Fri, 13 Jul 2012 15:15:00 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Fri, 13 Jul 2012 15:15:38 -0700 From: Michael Hammer To: "igor.faynberg@alcatel-lucent.com" Thread-Topic: [scim] SCIM drafts Thread-Index: AQHNYF/cWws3NXZV/Umxji7Z130xrpcnsfTggAB7k4D//5B6QIAAgCIA//+K8KA= Date: Fri, 13 Jul 2012 22:15:37 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB38C307B@EX2K10MB1.corp.yaanatech.com> References: <93E72F4B-CFE4-4F43-897C-FB7B0F8B2050@unboundid.com> <00C069FD01E0324C9FFCADF539701DB38C2FCC@EX2K10MB1.corp.yaanatech.com> <50008FAB.2080903@alcatel-lucent.com> <00C069FD01E0324C9FFCADF539701DB38C301E@EX2K10MB1.corp.yaanatech.com> <50009D9A.9070005@alcatel-lucent.com> In-Reply-To: <50009D9A.9070005@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.2] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01E3_01CD6123.7FFE1500" MIME-Version: 1.0 Cc: "scim@ietf.org" Subject: Re: [scim] SCIM drafts X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 22:15:01 -0000 ------=_NextPart_000_01E3_01CD6123.7FFE1500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit That is why I put the phone in " ". I just thought the IETF should be looking forward rather than backwards. Mike -----Original Message----- From: Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com] Sent: Friday, July 13, 2012 6:14 PM To: Michael Hammer Cc: scim@ietf.org Subject: Re: [scim] SCIM drafts Yes, now I understand. (I admit I never used Skype or a sophtphone for making calls that did not end up on PSTN--hence the initial confusion). But I thought that in the scope of SCIM, "phone" implied the E.164 numbering scheme. To this end, the IETF has actually spent a lot of time dealing with it (staring in PINT, but mostly, of course, in ENUM). Of course, the authors of the draft should correct me if I am wrong. Igor On 7/13/2012 5:36 PM, Michael Hammer wrote: > Try a non-E.164-based URI. > > Ever use Skype or a softphone? > > Mike > > > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf > Of Igor Faynberg > Sent: Friday, July 13, 2012 5:14 PM > To: scim@ietf.org > Subject: Re: [scim] SCIM drafts > > > > On 7/13/2012 5:06 PM, Michael Hammer wrote: >> ... >> Which also begs the question, does the IETF buy into the idea that >> all "phones" will be E.164 based only? > As opposed to...? > > Igor > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim ------=_NextPart_000_01E3_01CD6123.7FFE1500 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcx MzIyMTUzNlowIwYJKoZIhvcNAQkEMRYEFMhBdtMgV4yxu1ipIvGkQGn3BDc3MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAnyB/MZJP8NWiEPpOycQxbEWyQMNFp/SCWg029uv8Ymwi LEZxojWhtFcesXd/w94DxAr7BI1+CmBxmN8eyGzpdLAiN8tl0y8xX1+mxHYwjqBY5PDZWwtGIsH7 grU5FjTQo+is30N4j9+B7fUHsoLfPzPYc//fH88PVi4gBBCFW8cAAAAAAAA= ------=_NextPart_000_01E3_01CD6123.7FFE1500-- From trey.drake@unboundid.com Fri Jul 13 19:08:22 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6A921F85AD for ; Fri, 13 Jul 2012 19:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivr6i4nMIvyy for ; Fri, 13 Jul 2012 19:08:21 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C3F7121F8595 for ; Fri, 13 Jul 2012 19:08:21 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so6225711obb.31 for ; Fri, 13 Jul 2012 19:08:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=rwHMvuFb2adHv7JtKYrYSdkNJ43lZJWE2vsVa8YmSJ0=; b=VhekDUgTZKe/A39cq9BlkY3QueBoUTcRa9Vw33bIc8cUl6JvyowWJLAGnMOxK8/yf/ /gSSYhLLF9DpHzwDcHnNzRptY+s17ovEIRpYF/IJYkB892JqlWMeedzjxEiwq/SQw7im XcrWIntUMhEQZKzjkShwjLLBlwlLboB/VEubHexcDsxTE64oQ9v1/sKX9u1toG3NMhXR q8yTWP5dVelmlEd1BdliRQWemBZfRUg1NFa06HA63QMNJEm9nGY0KywVdv979O+FIkFg Ag+6Ly3loQCE3TfaJAqFL4NJBzsQbhM1gSotS8KkGVqv0CD76Zc5bgzDOR3X4JdN0qZb jk1A== Received: by 10.60.29.169 with SMTP id l9mr4762441oeh.14.1342231739325; Fri, 13 Jul 2012 19:08:59 -0700 (PDT) Received: from [10.0.1.27] (cpe-66-69-203-135.austin.res.rr.com. [66.69.203.135]) by mx.google.com with ESMTPS id sq1sm3696296obb.11.2012.07.13.19.08.58 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Jul 2012 19:08:58 -0700 (PDT) References: <93E72F4B-CFE4-4F43-897C-FB7B0F8B2050@unboundid.com> <00C069FD01E0324C9FFCADF539701DB38C2FCC@EX2K10MB1.corp.yaanatech.com> <50008FAB.2080903@alcatel-lucent.com> <00C069FD01E0324C9FFCADF539701DB38C301E@EX2K10MB1.corp.yaanatech.com> <50009D9A.9070005@alcatel-lucent.com> <00C069FD01E0324C9FFCADF539701DB38C307B@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB38C307B@EX2K10MB1.corp.yaanatech.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <4309D0BF-B461-452F-8FBA-C0439710E117@unboundid.com> X-Mailer: iPad Mail (9B206) From: Trey Drake Date: Fri, 13 Jul 2012 21:08:57 -0500 To: Michael Hammer X-Gm-Message-State: ALoCoQlknTlGBTEWRWLtSTGpsv66gUBedvcDBryZD4n6Dsu94s8N/GhS01dPXZhXO7nftw3R2tKU Cc: "igor.faynberg@alcatel-lucent.com" , "scim@ietf.org" Subject: Re: [scim] SCIM drafts X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 02:08:22 -0000 Hadn't thought of it, but it makes sense to me. Igor, Mike, suggested langu= age change? Thanks, Trey On Jul 13, 2012, at 5:15 PM, Michael Hammer w= rote: > That is why I put the phone in " ". >=20 > I just thought the IETF should be looking forward rather than backwards. >=20 > Mike >=20 >=20 > -----Original Message----- > From: Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com]=20 > Sent: Friday, July 13, 2012 6:14 PM > To: Michael Hammer > Cc: scim@ietf.org > Subject: Re: [scim] SCIM drafts >=20 > Yes, now I understand. (I admit I never used Skype or a sophtphone for > making calls that did not end up on PSTN--hence the initial confusion). >=20 > But I thought that in the scope of SCIM, "phone" implied the E.164 > numbering scheme. To this end, the IETF has actually spent a lot of time > dealing with it (staring in PINT, but mostly, of course, in ENUM). >=20 > Of course, the authors of the draft should correct me if I am wrong. >=20 > Igor >=20 > On 7/13/2012 5:36 PM, Michael Hammer wrote: >> Try a non-E.164-based URI. >>=20 >> Ever use Skype or a softphone? >>=20 >> Mike >>=20 >>=20 >> -----Original Message----- >> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf=20 >> Of Igor Faynberg >> Sent: Friday, July 13, 2012 5:14 PM >> To: scim@ietf.org >> Subject: Re: [scim] SCIM drafts >>=20 >>=20 >>=20 >> On 7/13/2012 5:06 PM, Michael Hammer wrote: >>> ... >>> Which also begs the question, does the IETF buy into the idea that=20 >>> all "phones" will be E.164 based only? >> As opposed to...? >>=20 >> Igor >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From phil.hunt@oracle.com Sat Jul 14 11:16:13 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FC321F8616 for ; Sat, 14 Jul 2012 11:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.605 X-Spam-Level: X-Spam-Status: No, score=-9.605 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTqo5iJ5tHFe for ; Sat, 14 Jul 2012 11:16:12 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 3881B21F860D for ; Sat, 14 Jul 2012 11:16:12 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6EIGnAl016591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 14 Jul 2012 18:16:50 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6EIGmYe028751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 14 Jul 2012 18:16:49 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6EIGmSS016997 for ; Sat, 14 Jul 2012 13:16:48 -0500 Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 14 Jul 2012 11:16:48 -0700 From: Phil Hunt Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (9B206) Message-Id: <909D4F95-636E-4525-BBC8-7A3142AEC85A@oracle.com> Date: Sat, 14 Jul 2012 11:16:44 -0700 To: scim WG Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Subject: [scim] Directory mapping discussion at ietf vancouver X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 18:16:13 -0000 Would anyone be interested in having a broader discussion about ldap directo= ries and mapping support prior to the scim wg session.=20 In particular it would good to explore some alternatives for mapping vs dire= ct complex attribute support. My primary worry is some mapping proposals lead to existing clients having t= o change classic ldap queries. I'd like to get to full fidelity (bi-directio= nal mapping) support and full backwards compatibility for existing clients i= f possible. =20 I think a good open discussion might take longer than we have scheduled time= in the meeting. :) Phil= From tonynad@microsoft.com Sat Jul 14 13:16:18 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF2E21F85E4 for ; Sat, 14 Jul 2012 13:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.466 X-Spam-Level: X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gguoS63TiLx9 for ; Sat, 14 Jul 2012 13:16:17 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 248C121F85D3 for ; Sat, 14 Jul 2012 13:16:17 -0700 (PDT) Received: from mail83-am1-R.bigfish.com (10.3.201.228) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Sat, 14 Jul 2012 20:16:56 +0000 Received: from mail83-am1 (localhost [127.0.0.1]) by mail83-am1-R.bigfish.com (Postfix) with ESMTP id CAF5E14026B for ; Sat, 14 Jul 2012 20:16:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VS-19(zzbb2dI9371Ic85fhzz1202h1082kzz1033IL8275dhz2fh2a8h683h839hd25hf0ah107ah) Received-SPF: pass (mail83-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail83-am1 (localhost.localdomain [127.0.0.1]) by mail83-am1 (MessageSwitch) id 1342297013849420_12903; Sat, 14 Jul 2012 20:16:53 +0000 (UTC) Received: from AM1EHSMHS006.bigfish.com (unknown [10.3.201.229]) by mail83-am1.bigfish.com (Postfix) with ESMTP id CDAE92A004B for ; Sat, 14 Jul 2012 20:16:53 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS006.bigfish.com (10.3.207.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 14 Jul 2012 20:16:50 +0000 Received: from co1outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.2.298.5; Sat, 14 Jul 2012 20:16:47 +0000 Received: from mail216-co1-R.bigfish.com (10.243.78.245) by CO1EHSOBE016.bigfish.com (10.243.66.79) with Microsoft SMTP Server id 14.1.225.23; Sat, 14 Jul 2012 20:16:47 +0000 Received: from mail216-co1 (localhost [127.0.0.1]) by mail216-co1-R.bigfish.com (Postfix) with ESMTP id 6A80F8C0133 for ; Sat, 14 Jul 2012 20:16:47 +0000 (UTC) Received: from mail216-co1 (localhost.localdomain [127.0.0.1]) by mail216-co1 (MessageSwitch) id 1342297005742610_30863; Sat, 14 Jul 2012 20:16:45 +0000 (UTC) Received: from CO1EHSMHS012.bigfish.com (unknown [10.243.78.225]) by mail216-co1.bigfish.com (Postfix) with ESMTP id B3283800044; Sat, 14 Jul 2012 20:16:45 +0000 (UTC) Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by CO1EHSMHS012.bigfish.com (10.243.66.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 14 Jul 2012 20:16:46 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.12.220]) by BL2PRD0310HT002.namprd03.prod.outlook.com ([10.255.97.37]) with mapi id 14.16.0175.005; Sat, 14 Jul 2012 20:16:44 +0000 From: Anthony Nadalin To: Phil Hunt , scim WG Thread-Topic: [scim] Directory mapping discussion at ietf vancouver Thread-Index: AQHNYeziBNW6gj0haUmCvB+/p3nKBZcpN1KO Date: Sat, 14 Jul 2012 20:16:43 +0000 Message-ID: References: <909D4F95-636E-4525-BBC8-7A3142AEC85A@oracle.com> In-Reply-To: <909D4F95-636E-4525-BBC8-7A3142AEC85A@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.147.92.221] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E7554F7E39BL2PRD0310MB362_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%ORACLE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC101.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Subject: Re: [scim] Directory mapping discussion at ietf vancouver X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 20:16:18 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E7554F7E39BL2PRD0310MB362_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would be interested Sent from my Windows Phone ________________________________ From: Phil Hunt Sent: 7/14/2012 11:17 AM To: scim WG Subject: [scim] Directory mapping discussion at ietf vancouver Would anyone be interested in having a broader discussion about ldap direct= ories and mapping support prior to the scim wg session. In particular it would good to explore some alternatives for mapping vs dir= ect complex attribute support. My primary worry is some mapping proposals lead to existing clients having = to change classic ldap queries. I'd like to get to full fidelity (bi-direct= ional mapping) support and full backwards compatibility for existing client= s if possible. I think a good open discussion might take longer than we have scheduled tim= e in the meeting. :) Phil _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_B26C1EF377CB694EAB6BDDC8E624B6E7554F7E39BL2PRD0310MB362_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I would be in= terested

Sent from my Windows Phone
From: Phil H= unt
Sent: 7/14/2= 012 11:17 AM
To: scim W= G
Subject: [scim]= Directory mapping discussion at ietf vancouver

Would anyone be interested in having a broader dis= cussion about ldap directories and mapping support prior to the scim wg ses= sion.

In particular it would good to explore some alternatives for mapping vs dir= ect complex attribute support.

My primary worry is some mapping proposals lead to existing clients having = to change classic ldap queries. I'd like to get to full fidelity (bi-direct= ional mapping) support and full backwards compatibility for existing client= s if possible. 

I think a good open discussion might take longer than we have scheduled tim= e in the meeting. :)

Phil
_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org= /mailman/listinfo/scim



 --_000_B26C1EF377CB694EAB6BDDC8E624B6E7554F7E39BL2PRD0310MB362_-- From leifj@mnt.se Sat Jul 14 15:00:18 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F354621F8637 for ; Sat, 14 Jul 2012 15:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.959 X-Spam-Level: X-Spam-Status: No, score=-2.959 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnPetokxoeTS for ; Sat, 14 Jul 2012 15:00:06 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id B0E5321F8629 for ; Sat, 14 Jul 2012 15:00:05 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q6EM0ejN022980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 15 Jul 2012 00:00:43 +0200 (CEST) Message-ID: <5001EC08.8000407@mnt.se> Date: Sun, 15 Jul 2012 00:00:40 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: scim@ietf.org References: <909D4F95-636E-4525-BBC8-7A3142AEC85A@oracle.com> In-Reply-To: <909D4F95-636E-4525-BBC8-7A3142AEC85A@oracle.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [scim] Directory mapping discussion at ietf vancouver X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 22:00:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/14/2012 08:16 PM, Phil Hunt wrote: > Would anyone be interested in having a broader discussion about > ldap directories and mapping support prior to the scim wg session. > > > In particular it would good to explore some alternatives for > mapping vs direct complex attribute support. > > My primary worry is some mapping proposals lead to existing clients > having to change classic ldap queries. I'd like to get to full > fidelity (bi-directional mapping) support and full backwards > compatibility for existing clients if possible. > > I think a good open discussion might take longer than we have > scheduled time in the meeting. :) We can at least do a report-back in the session and make sure to capture follow-ups etc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAB7AcACgkQ8Jx8FtbMZne8yQCeLhEo0rsPF0BQclf34uS1Sw2M Ps4An3oRlV1i+fVOA4CfdAgfuH4G2MAT =sJyT -----END PGP SIGNATURE----- From phil.hunt@oracle.com Sat Jul 14 18:13:41 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C9021F85EF for ; Sat, 14 Jul 2012 18:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.29 X-Spam-Level: X-Spam-Status: No, score=-10.29 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPU8LfNcvLO2 for ; Sat, 14 Jul 2012 18:13:41 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id E686321F84C2 for ; Sat, 14 Jul 2012 18:13:40 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6F1EJob022957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 15 Jul 2012 01:14:20 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6F1EILP021525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Jul 2012 01:14:18 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6F1EHdP016619; Sat, 14 Jul 2012 20:14:18 -0500 Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 14 Jul 2012 18:14:17 -0700 References: <909D4F95-636E-4525-BBC8-7A3142AEC85A@oracle.com> <5001EC08.8000407@mnt.se> In-Reply-To: <5001EC08.8000407@mnt.se> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <23AFD7EC-FDF6-4268-9355-E8D9B479337B@oracle.com> X-Mailer: iPhone Mail (9B206) From: Phil Hunt Date: Sat, 14 Jul 2012 18:14:14 -0700 To: Leif Johansson X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "scim@ietf.org" Subject: Re: [scim] Directory mapping discussion at ietf vancouver X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2012 01:13:41 -0000 Agreed. Phil On 2012-07-14, at 15:00, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/14/2012 08:16 PM, Phil Hunt wrote: >> Would anyone be interested in having a broader discussion about >> ldap directories and mapping support prior to the scim wg session. >> >> >> In particular it would good to explore some alternatives for >> mapping vs direct complex attribute support. >> >> My primary worry is some mapping proposals lead to existing clients >> having to change classic ldap queries. I'd like to get to full >> fidelity (bi-directional mapping) support and full backwards >> compatibility for existing clients if possible. >> >> I think a good open discussion might take longer than we have >> scheduled time in the meeting. :) > > We can at least do a report-back in the session and make sure to > capture follow-ups etc. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAlAB7AcACgkQ8Jx8FtbMZne8yQCeLhEo0rsPF0BQclf34uS1Sw2M > Ps4An3oRlV1i+fVOA4CfdAgfuH4G2MAT > =sJyT > -----END PGP SIGNATURE----- > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From Chris.Phillips@canarie.ca Sun Jul 15 05:00:03 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC1F21F8564 for ; Sun, 15 Jul 2012 05:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2lo69HArqOf for ; Sun, 15 Jul 2012 05:00:02 -0700 (PDT) Received: from mail.canarie.ca (mail.canarie.ca [205.189.33.5]) by ietfa.amsl.com (Postfix) with ESMTP id 63C8721F8530 for ; Sun, 15 Jul 2012 05:00:02 -0700 (PDT) Received: from RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d]) by RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d%10]) with mapi; Sun, 15 Jul 2012 07:48:44 -0400 From: Chris Phillips To: Phil Hunt Date: Sun, 15 Jul 2012 07:48:43 -0400 Thread-Topic: [scim] Directory mapping discussion at ietf vancouver Thread-Index: Ac1if8j7zcpjFqXaRwijBA4z2kP4EQ== Message-ID: References: <909D4F95-636E-4525-BBC8-7A3142AEC85A@oracle.com> In-Reply-To: <909D4F95-636E-4525-BBC8-7A3142AEC85A@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: scim WG Subject: Re: [scim] Directory mapping discussion at ietf vancouver X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2012 12:00:03 -0000 I would be interested as well... /mobile_____________________ chris.phillips@canarie.ca On Jul 14, 2012, at 2:16 PM, "Phil Hunt" wrote: > Would anyone be interested in having a broader discussion about ldap dire= ctories and mapping support prior to the scim wg session.=20 >=20 > In particular it would good to explore some alternatives for mapping vs d= irect complex attribute support. >=20 > My primary worry is some mapping proposals lead to existing clients havin= g to change classic ldap queries. I'd like to get to full fidelity (bi-dire= ctional mapping) support and full backwards compatibility for existing clie= nts if possible. =20 >=20 > I think a good open discussion might take longer than we have scheduled t= ime in the meeting. :) >=20 > Phil > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From michael.hammer@yaanatech.com Mon Jul 16 08:17:03 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E8821F8672 for ; Mon, 16 Jul 2012 08:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgGtJ0w59icZ for ; Mon, 16 Jul 2012 08:17:02 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 3786721F86A3 for ; Mon, 16 Jul 2012 08:17:02 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Mon, 16 Jul 2012 08:17:47 -0700 From: Michael Hammer To: "trey.drake@unboundid.com" Thread-Topic: [scim] SCIM drafts Thread-Index: AQHNYF/cWws3NXZV/Umxji7Z130xrpcnsfTggAB7k4D//5B6QIAAgCIA//+K8KCAALbGgIADeSDQ Date: Mon, 16 Jul 2012 15:17:45 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB38C84B1@ex2k10mb2.corp.yaanatech.com> References: <93E72F4B-CFE4-4F43-897C-FB7B0F8B2050@unboundid.com> <00C069FD01E0324C9FFCADF539701DB38C2FCC@EX2K10MB1.corp.yaanatech.com> <50008FAB.2080903@alcatel-lucent.com> <00C069FD01E0324C9FFCADF539701DB38C301E@EX2K10MB1.corp.yaanatech.com> <50009D9A.9070005@alcatel-lucent.com> <00C069FD01E0324C9FFCADF539701DB38C307B@EX2K10MB1.corp.yaanatech.com> <4309D0BF-B461-452F-8FBA-C0439710E117@unboundid.com> In-Reply-To: <4309D0BF-B461-452F-8FBA-C0439710E117@unboundid.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.6] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0035_01CD6344.9F516510" MIME-Version: 1.0 Cc: "igor.faynberg@alcatel-lucent.com" , "scim@ietf.org" Subject: Re: [scim] SCIM drafts X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 15:17:03 -0000 ------=_NextPart_000_0035_01CD6344.9F516510 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Trey, If you go back to my original email, you will see that I brought up two issues: - the specific case of the sip: and sips: addresses, which could be phone, video conference, telepresence, or any type of multimedia connection-oriented service. - the more generic problem of potentially many more application types for which you need to provide an address. So, the easy answer would be to extend the following from 6.2. Multi-valued Attributes to include: phoneNumbers Phone numbers for the User. The value SHOULD be canonicalized by the Service Provider according to format in RFC3966 [7] e.g. 'tel:+1-201-555-0123'. Canonical Type values of work, home, mobile, fax, pager and other. Add: Or according to RFC3261 and RFC3969 for sip: and sips: URIs. Note: IANA also lists RFC5341 for tel: URI. BTW, there is also RFC5031 for urn:service:sos.* numbers. Not sure is you need that, but emergency numbers should be considered. Another more off-the-wall one would be geo:* RFC5870, but not sure you want to get into geo-locations. For the more generic case, you might want to have the addresses block be the main item, with sub-cases being the different application types as an attribute at the same level as "type" and "value". 3.2. Multi-valued Attributes type A label indicating the attribute's function; e.g., "work" or "home". value The attribute's significant value; e.g., the e-mail address, phone number, etc. Attributes that define a "value" sub-attribute MAY be alternately represented as a collection of primitive types. > address-type A label indicating the attribute' application specific format. < For example: "addresses": [ { "address-type":"snail-mail", "type": "work", "streetAddress": "100 Universal City Plaza", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "USA", "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA", "primary": true }, { "address-type":"email", "value": "bjensen@example.com", "type": "work", "primary": true }, { "address-type":"im", "value": "someaimhandle", "type": "aim" } { "address-type":"pstn", "value": "555-555-5555", "type": "work" }, { "address-type":"tel:", "value": "+1-555-555-4444", "type": "mobile" } { "address-type":"sip:", "value": "john.doe@voip.provider.com", "type": "internet" } { "address-type":"skype", "value": "johndoe123", "type": "internet" } { "address-type":"https:", "value": "//photos.example.com/profilephoto/72930000000Ccne/F", "type": "photo" }, ], Just throwing this out there for thought. Many ways to slice and dice this, just wondering if you want people doing extensions of attribute types or of attribute values. It might be easier to put and get values, even if they are unknown to the registry. Mike -----Original Message----- From: Trey Drake [mailto:trey.drake@unboundid.com] Sent: Friday, July 13, 2012 10:09 PM To: Michael Hammer Cc: igor.faynberg@alcatel-lucent.com; scim@ietf.org Subject: Re: [scim] SCIM drafts Hadn't thought of it, but it makes sense to me. Igor, Mike, suggested language change? Thanks, Trey On Jul 13, 2012, at 5:15 PM, Michael Hammer wrote: > That is why I put the phone in " ". > > I just thought the IETF should be looking forward rather than backwards. > > Mike > > > -----Original Message----- > From: Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com] > Sent: Friday, July 13, 2012 6:14 PM > To: Michael Hammer > Cc: scim@ietf.org > Subject: Re: [scim] SCIM drafts > > Yes, now I understand. (I admit I never used Skype or a sophtphone for > making calls that did not end up on PSTN--hence the initial confusion). > > But I thought that in the scope of SCIM, "phone" implied the E.164 > numbering scheme. To this end, the IETF has actually spent a lot of > time dealing with it (staring in PINT, but mostly, of course, in ENUM). > > Of course, the authors of the draft should correct me if I am wrong. > > Igor > > On 7/13/2012 5:36 PM, Michael Hammer wrote: >> Try a non-E.164-based URI. >> >> Ever use Skype or a softphone? >> >> Mike >> >> >> -----Original Message----- >> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf >> Of Igor Faynberg >> Sent: Friday, July 13, 2012 5:14 PM >> To: scim@ietf.org >> Subject: Re: [scim] SCIM drafts >> >> >> >> On 7/13/2012 5:06 PM, Michael Hammer wrote: >>> ... >>> Which also begs the question, does the IETF buy into the idea that >>> all "phones" will be E.164 based only? >> As opposed to...? >> >> Igor >> >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim ------=_NextPart_000_0035_01CD6344.9F516510 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcx NjE1MTc0NFowIwYJKoZIhvcNAQkEMRYEFCdgEE8LzJPk7adVWdXmrW7i2E0AMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGACwZsj9y2sHT4paYLeiKofT7llnj/ThV0UckesbVY4R5H hXloOXoZe78L5EiMuC4mjy3GMjXB60k3+ejzosXjS+xZG7RKYEcqw4fWGz9d5TVYUocICE+y+XX3 HO0NS3bADxVDCzF3JZPTW896rejOwfbJasjy+Gbjr54vQN4smYcAAAAAAAA= ------=_NextPart_000_0035_01CD6344.9F516510-- From igor.faynberg@alcatel-lucent.com Mon Jul 16 09:26:27 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B3F21F8648 for ; Mon, 16 Jul 2012 09:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.799 X-Spam-Level: X-Spam-Status: No, score=-7.799 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITUeKzeQ4mft for ; Mon, 16 Jul 2012 09:26:26 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 9715121F8646 for ; Mon, 16 Jul 2012 09:26:26 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q6GGR84x015865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 16 Jul 2012 11:27:08 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q6GGR8lP002550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 16 Jul 2012 11:27:08 -0500 Received: from [135.222.232.88] (USMUYN0L055118.mh.lucent.com [135.222.232.88]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q6GGR7pq003924; Mon, 16 Jul 2012 11:27:08 -0500 (CDT) Message-ID: <500440DB.8030401@alcatel-lucent.com> Date: Mon, 16 Jul 2012 12:27:07 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: scim@ietf.org References: <93E72F4B-CFE4-4F43-897C-FB7B0F8B2050@unboundid.com> <00C069FD01E0324C9FFCADF539701DB38C2FCC@EX2K10MB1.corp.yaanatech.com> <50008FAB.2080903@alcatel-lucent.com> <00C069FD01E0324C9FFCADF539701DB38C301E@EX2K10MB1.corp.yaanatech.com> <50009D9A.9070005@alcatel-lucent.com> <00C069FD01E0324C9FFCADF539701DB38C307B@EX2K10MB1.corp.yaanatech.com> <4309D0BF-B461-452F-8FBA-C0439710E117@unboundid.com> In-Reply-To: <4309D0BF-B461-452F-8FBA-C0439710E117@unboundid.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [scim] SCIM drafts X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 16:26:27 -0000 Actually, I did not see a need for a change here... Igor On 7/13/2012 10:08 PM, Trey Drake wrote: > Hadn't thought of it, but it makes sense to me. Igor, Mike, suggested language change? > > Thanks, > Trey > > On Jul 13, 2012, at 5:15 PM, Michael Hammer wrote: > >> That is why I put the phone in " ". >> >> I just thought the IETF should be looking forward rather than backwards. >> >> Mike >> >> >> -----Original Message----- >> From: Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com] >> Sent: Friday, July 13, 2012 6:14 PM >> To: Michael Hammer >> Cc: scim@ietf.org >> Subject: Re: [scim] SCIM drafts >> >> Yes, now I understand. (I admit I never used Skype or a sophtphone for >> making calls that did not end up on PSTN--hence the initial confusion). >> >> But I thought that in the scope of SCIM, "phone" implied the E.164 >> numbering scheme. To this end, the IETF has actually spent a lot of time >> dealing with it (staring in PINT, but mostly, of course, in ENUM). >> >> Of course, the authors of the draft should correct me if I am wrong. >> >> Igor >> >> On 7/13/2012 5:36 PM, Michael Hammer wrote: >>> Try a non-E.164-based URI. >>> >>> Ever use Skype or a softphone? >>> >>> Mike >>> >>> >>> -----Original Message----- >>> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf >>> Of Igor Faynberg >>> Sent: Friday, July 13, 2012 5:14 PM >>> To: scim@ietf.org >>> Subject: Re: [scim] SCIM drafts >>> >>> >>> >>> On 7/13/2012 5:06 PM, Michael Hammer wrote: >>>> ... >>>> Which also begs the question, does the IETF buy into the idea that >>>> all "phones" will be E.164 based only? >>> As opposed to...? >>> >>> Igor >>> >>> >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From scotty@catbert.net Thu Jul 19 15:37:46 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E799D11E8087 for ; Thu, 19 Jul 2012 15:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfgW8q5kQPG5 for ; Thu, 19 Jul 2012 15:37:45 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id AF08911E80A2 for ; Thu, 19 Jul 2012 15:37:45 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2678608vbb.31 for ; Thu, 19 Jul 2012 15:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catbert.net; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QRJjHA9SOmerbch67vdt7dfsW1aQsxII3bMrr13j3qY=; b=bSTK+C0Ey+Qb6Iqcy5Am5GXPobZTyyJrC+CTi5d5U3ClBmPAi80dNOCepLDheI8cRC zt4kdC0yULM1rD8FPJ/SuLNS6bAQthyRRN5f4LmNG4uqINhIvPWWp4E4TIwp4+dQVuyI oKkRW5ItdwOy+Y9BYnmWkEQYKLDkdYss3NiAo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=QRJjHA9SOmerbch67vdt7dfsW1aQsxII3bMrr13j3qY=; b=chB9Q4Xc5S7zXdxGiueUQMXUfhf49xj15dEjyZKvtP1RLbPe8XFdHnlsFfjcJLw6aM OYM08LaWWX1RVVtAusqgT/itfjDbXzZvBZw/YeX6XqHUNDjGpXjmpwTZ/MAEZzkT/mlH 2AeJlcaz1iO4DQZvWuO9aOqTlZOElhyn7KnRC/0bQMjTnw27wDDacTLohH2+iB1RCSLa BcL26LSYKTwDuj2fqoYcVki1f54btYowMtcpFSlWsHMqfNzbyjrqWyvTjNrViWk6PdaK xHaOpYWBFMPLHbObcS1VvE2YP5gxXPQi8aSZEs+jKD9wZDY+7wPTHYGHRdfhIdDz4pdy blWA== MIME-Version: 1.0 Received: by 10.52.72.99 with SMTP id c3mr2200090vdv.54.1342737519293; Thu, 19 Jul 2012 15:38:39 -0700 (PDT) Received: by 10.220.210.67 with HTTP; Thu, 19 Jul 2012 15:38:39 -0700 (PDT) X-Originating-IP: [171.66.167.111] In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C343722AB03F8@BL2PRD0411MB397.namprd04.prod.outlook.com> References: <67261554-7E01-4FBD-B7E5-4EF6F3487BAE@oracle.com> <9B9F7C7A-A3FB-4E6E-B686-45E7AA452607@oracle.com> <4FEBA2BE.2050006@alcatel-lucent.com> <219947F0B2242843A0A1E62FDB510DC026CED44475@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <56C3C758F9D6534CA3778EAA1E0C343722AB03F8@BL2PRD0411MB397.namprd04.prod.outlook.com> Date: Thu, 19 Jul 2012 15:38:39 -0700 Message-ID: From: Scotty Logan To: Kelly Grizzle Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlOstI3V4cQ5kRoRMRzSQIilAjA6GDJlGKFCLYzJ86OglM6FbTnrrweH4bogPu5CN0j3vgr Cc: "Brenner, Michael Ralf \(Michael\)" , "Faynberg, Igor \(Igor\)" , "scim@ietf.org" , Phil Hunt Subject: Re: [scim] Searching with POST instead of GET X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 22:37:47 -0000 On Fri, Jun 29, 2012 at 8:35 AM, Kelly Grizzle wrote: > I don=92t know how often there will be a security concern over GET parame= ters, > although I can see some of the more security conscious worrying about thi= s. > My vote would be to simply add official support for the GET method in Bul= k > requests (it is currently the only excluded method). Clients that are no= t > worried can use a normal GET request and others could use a POST to /Bulk > with a GET request in the payload. Coming to this late=85 finally catching up on mail=85 One approach that's come up in some recent discussions at work about search APIs is to treat complex (or in this case sensitive) searches as (temporary) resources: POST /search HTTP/1.1 Content-type: application/json =85 { =85 search description=85 } The server responds with a 201 and a location: HTTP/1.1 201 CREATED Location: https://scim.example.com/search/D9uRkgJhQ04tPhAmYlvMGcHtD4DRWqkQa= M98JqxwfDg The client then GETs that resource GET /search/D9uRkgJhQ04tPhAmYlvMGcHtD4DRWqkQaM98JqxwfDg HTTP/1.1 =85 And the server returns the results: HTTP/1.1 200 OK Content-type: application/json =85 [ { object1 }, { object2 }, { object3 } ] Servers could automatically delete the search after some period, or clients could clean up after themselves: DELETE /search/D9uRkgJhQ04tPhAmYlvMGcHtD4DRWqkQaM98JqxwfDg HTTP/1.1 =85 It's up to the server implementation to decide whether the result set is created when the search is created or when it is retrieved. Scotty From leifj@mnt.se Thu Jul 26 05:17:04 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D14221F8700 for ; Thu, 26 Jul 2012 05:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.937 X-Spam-Level: X-Spam-Status: No, score=-2.937 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBeclgaPd9Xp for ; Thu, 26 Jul 2012 05:17:03 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 58F2C21F8675 for ; Thu, 26 Jul 2012 05:17:03 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q6QCGvjo028838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Jul 2012 14:17:01 +0200 (CEST) Message-ID: <50113539.8050802@mnt.se> Date: Thu, 26 Jul 2012 14:16:57 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: scim WG X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [scim] fyi - remote participation & meeting time change X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 12:17:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For those not in Vancouver you can still listen to the audio stream and we'll make sure to have somebody watching the jabber feed ready to "channel" anybody not present. http://www.ietf.org/meeting/84/remote-participation.html We're also going to get a meetecho feed (full video and voice): http://ietf84.conf.meetecho.com/ Also note that the meeting has been moved to after lunch on Friday to avoid a scheduling conflict (involving other WGs). This sort of thing is not uncommon at IETF meetings. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlARNTIACgkQ8Jx8FtbMZnejAwCfUnWeRj3fSuHtJGT60/qvQ+TP sTIAoLMEf2O1npKnDcWxuVMsOATO+tKW =zE69 -----END PGP SIGNATURE----- From sal@idmachines.com Thu Jul 26 06:27:27 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5F921F86AD for ; Thu, 26 Jul 2012 06:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKISBNMH0IaA for ; Thu, 26 Jul 2012 06:27:26 -0700 (PDT) Received: from outbound001.roc2.bluetie.com (outbound001.roc2.bluetie.com [208.89.132.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEE521F864F for ; Thu, 26 Jul 2012 06:27:25 -0700 (PDT) Received: from emta003.roc2.bluetie.com ([10.200.2.133]) by outbound001.roc2.bluetie.com with bizsmtp id f1TR1j0012sBFZW011TR7P; Thu, 26 Jul 2012 09:27:25 -0400 X-CMAE-OUT-Analysis: v=2.0 cv=D/fF24tj c=1 sm=1 a=vF9M573zfL0Q28mXaLzL3A==:17 a=R8jQN94y0xsA:10 a=rDVSmjPdij8A:10 a=I9BJdG6Tl3oA:10 a=Oe1vhrNJAAAA:8 a=48vgC7mUAAAA:8 a=E1R-V3ATAAAA:8 a=xe8BsctaAAAA:8 a=9biErEOyXELBdzTPb0MA:9 a=CjuIK1q_8ugA:10 a=Qv5F4YHriPYA:10 a=lZB815dzVvQA:10 a=W3nx6EVduvWh_piH:21 a=wolrFcsf6JOUURx_:21 a=OAUM8_f4AAAA:8 a=Hzc67GbKAAAA:8 a=J_R1D7kMAAAA:8 a=v_HabFGYiU2OGkFS6PwA:9 a=ZVk8-NSrHBgA:10 a=BaG7jsApzVfQP5CKn1ndzA==:117 X-CMAE-OUT-Score: 0.00 Received: from salPC (pool-72-70-99-155.bstnma.east.verizon.net [72.70.99.155]) (Authenticated sender: sal@idmachines.com) by emta003.roc2.bluetie.com (Postfix) with ESMTP id D829B11D01AD; Thu, 26 Jul 2012 09:27:23 -0400 (EDT) From: "Salvatore D'Agostino" To: "'Leif Johansson'" , "'scim WG'" References: <50113539.8050802@mnt.se> In-Reply-To: <50113539.8050802@mnt.se> Date: Thu, 26 Jul 2012 09:27:22 -0400 Message-ID: <031c01cd6b32$649a67f0$2dcf37d0$@com> X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1rKJNuzFixz/d7SPejSTRI4mDn3AACcASQ Content-Language: en-us MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_0317_01CD6B10.DC47E380"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Subject: Re: [scim] fyi - remote participation & meeting time change X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 13:27:27 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0317_01CD6B10.DC47E380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks, appreciate the accommodations. -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Leif Johansson Sent: Thursday, July 26, 2012 8:17 AM To: scim WG Subject: [scim] fyi - remote participation & meeting time change -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For those not in Vancouver you can still listen to the audio stream and we'll make sure to have somebody watching the jabber feed ready to "channel" anybody not present. http://www.ietf.org/meeting/84/remote-participation.html We're also going to get a meetecho feed (full video and voice): http://ietf84.conf.meetecho.com/ Also note that the meeting has been moved to after lunch on Friday to avoid a scheduling conflict (involving other WGs). This sort of thing is not uncommon at IETF meetings. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlARNTIACgkQ8Jx8FtbMZnejAwCfUnWeRj3fSuHtJGT60/qvQ+TP sTIAoLMEf2O1npKnDcWxuVMsOATO+tKW =zE69 -----END PGP SIGNATURE----- _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim ------=_NextPart_000_0317_01CD6B10.DC47E380 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITIjCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIEnTCC A4WgAwIBAgIQND3pK6wnNP+PyzSU+8xwVDANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoX DTIwMDUzMDEwNDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2Fs dCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk 8n2rQTtiRjeuzcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTE hb2FUTV5pE5okHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov 66yhs2qqty5nNYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8 goqOpA6l14lD/BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6h hX71R2XL+E1XKHTSNP8wtu72YjAUjCzrAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6 xCZU7wO94CTLVBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNo dHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYB BQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQABvJzjYyiw8zEBwt973WKgAZ0jMQ+cknNTUeofTPrWn8TKL2d+eDMPdBa5kYeR 9Yom+mRwANge+QsEYlCHk4HU2vUj2zS7hVa0cDRueIM3HoUcxREVkl+HF72sav3xwtHMiV+xfPA+ UfI183zsYJhrOivg79+zfYbrtRv1W+yifJgT1wBQudEtc94DeHThBYUxXsuauZ2UxrmUN3Vy3ET7 Z+jw+iUeUqfaJelH4KDHPKBOsQo2+3dIn++Xivu0/uOUFKiDvFwtP9JgcWDuwnGCDOmINuPaILSj oGyqlku4gI51ykkH9jsUut/cBdmf2+Cy5k2geCbn5y1uf1/GHogVMIIFGjCCBAKgAwIBAgIQbRnq pxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVU MRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmly c3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1 MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09N T0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU 4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHff sReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kAB W0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJk JpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IB SzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4 Y2QnwS/ioFu8ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQK MAgwBgYEVR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVRO LVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVu dF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcN AQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjB MCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8 H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5 OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggUlMIIEDaADAgECAhBml2Ca GVWQ27CLZWxPuG8TMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGlt aXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTEyMDQyMzAwMDAwMFoXDTEzMDQyMzIzNTk1OVowIzEhMB8GCSqGSIb3DQEJARYS c2FsQGlkbWFjaGluZXMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqXbqpeKb v6msCdkE9pU77+XTOz1HFVGd3mSAD+ytO81OvXar2GWFKQ4NyjyE4qYIjcFawjY/kwLmpqIoEOVm LgLkLvxqmR22mXsT4XRjltTO9aC/J/WBEw3jWwO8gUMyMvJupz9fZK/Bykz6BSZMyWnAy/BjXgCx jlRQObY9LzlOMBecuARhxFI/JVjO6T7UMvbOJL1dAMsaswbLxAcJ6w3Opl8pBtlSLgsPpi4gvo4y sVVCJoYVsTz3Rg3tj9/Y3pbIWNzw3681Kqu6pT5HUGtE4zyA1zUqtLQ4vQU3B2plycnZu2yiHe/a RYXh1MCcMrKYnA5Hhef40prZki8qBwIDAQABo4IB4jCCAd4wHwYDVR0jBBgwFoAUehNOAHRbxnhj ZCfBL+KgW7x5xXswHQYDVR0OBBYEFAdVs/aLLn0ncD2xlTTlPtqMLcdVMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0cDovL2NybC5j b21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy bDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9D T01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHQYDVR0RBBYwFIESc2FsQGlkbWFjaGluZXMuY29t MA0GCSqGSIb3DQEBBQUAA4IBAQBknw1mVN5lBeQwkKlhJcdd5PwttXcZJJmm4IBt5Ae/KPKovzvb DPWWrWoeEdu3SR7Vq+EfBvkPw+BhYGPrp/1Uke608E+RQsuYhXE8B/mF/3b9mlSxKCb4Y33l6HFM i7yv2rNZEa/tR2TfoT0ZC6DdJo/gSLEBV/mPoXh/ltl1xniX0T3724elyh+k5ucgU0tbwh2dJLvv gDb5RYPMixh8cvKTKwnkcGFo8m59+mKC4ozo58/yCTok+kZ98/csOTSopBPnttZjZ43+Ht78et33 gbGLmhNMQqN38ysO40qZ8m4PZ8Zm80FF/T5BXT3DWP0ARC/ES/B74jg0GF2ip16lMYIEZTCCBGEC AQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8g Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEGaXYJoZVZDbsItlbE+4 bxMwCQYFKw4DAhoFAKCCApEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTIwNzI2MTMyNzIyWjAjBgkqhkiG9w0BCQQxFgQUdRpwSZeG1UDKHso8snYO709rf/4wgbcG CSqGSIb3DQEJDzGBqTCBpjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsG CWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZI hvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEw CgYIKoZIhvcNAgUwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQZpdgmhlVkNuwi2VsT7hvEzCBuwYLKoZIhvcNAQkQAgsxgauggagwgZMxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEGaXYJoZVZDbsItlbE+4bxMwDQYJKoZIhvcN AQEBBQAEggEAHXiGAF3BUfr3n4XlUPBqlLcohC5K8HBrrUHY9ER2mG8hPHmRM9WbarkWOjEJjfjA 5/sAQsnLcDDqBah7MTxoxCguKAQlKsdTl8z2/YMgdJBm2UMzlLWdvXYbj4NtZEyCg1jg8uYEEzgj kxMopEjCNhiESfwOaIXKcYRzs7clyM66x2JHakG19PaUfg9VitAX1j1QXxeGaoU1wTxfoNdeLdCB gu/WlbJgsV1bCRNm5coldaI7ij7xMBA3wFIGjzisYOwL4vH+KUajAJJKTqKWnuu2JR5qm/mIYfXM 5ID81nDKiBW1sArZYfvz/VNX8Rk05jVQgwv58v8hfKgq/NfqiwAAAAAAAA== ------=_NextPart_000_0317_01CD6B10.DC47E380-- From mrutkows@us.ibm.com Thu Jul 26 15:06:44 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F423311E80C4 for ; Thu, 26 Jul 2012 15:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.948 X-Spam-Level: X-Spam-Status: No, score=-9.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avwhc0XHcSHk for ; Thu, 26 Jul 2012 15:06:42 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id 5381511E80BF for ; Thu, 26 Jul 2012 15:06:41 -0700 (PDT) Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 26 Jul 2012 18:06:06 -0400 Received: from d01dlp02.pok.ibm.com (9.56.224.85) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 26 Jul 2012 18:06:04 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 1DE9D6E8039 for ; Thu, 26 Jul 2012 18:06:03 -0400 (EDT) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q6QM5w0j191448 for ; Thu, 26 Jul 2012 18:05:59 -0400 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q6QM75qm003565 for ; Thu, 26 Jul 2012 16:07:05 -0600 Received: from d03nm133.boulder.ibm.com (d03nm133.boulder.ibm.com [9.17.195.180]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q6QM6xd1002885 for ; Thu, 26 Jul 2012 16:07:05 -0600 Auto-Submitted: auto-generated From: Matt Rutkowski To: scim@ietf.org Message-ID: Date: Thu, 26 Jul 2012 16:05:42 -0600 X-MIMETrack: Serialize by Router on D03NM133/03/M/IBM(Release 8.5.3HF266 | January 13, 2012) at 07/26/2012 16:05:53 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBF0D4DFEAD9AD8f9e8a93df938690918c08BBF0D4DFEAD9AD" Content-Disposition: inline X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12072622-7182-0000-0000-00000215D9E2 Subject: [scim] AUTO: Matt Rutkowski/Austin/IBM is travelling (returning 08/01/2012) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 22:06:44 -0000 --0__=08BBF0D4DFEAD9AD8f9e8a93df938690918c08BBF0D4DFEAD9AD Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I am out of the office until 08/01/2012. I will be travelling and unable to respond to email or mobile messages.= For emergencies please contact my manager Johanna Koester. Note: This is an automated response to your message "scim Digest, Vol = 7, Issue 9" sent on 07/26/2012 13:00:15. This is the only notification you will receive while this person is awa= y.= --0__=08BBF0D4DFEAD9AD8f9e8a93df938690918c08BBF0D4DFEAD9AD Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I am out of the office until 08= /01/2012.

I will be travelling and un= able to respond to email or mobile messages.  For emergencies plea= se contact my manager Johanna Koester.


Note: Thi= s is an automated response to your message  "scim Digest, Vol 7, Issue 9" sent o= n 07/26/2012 13:00:15.

This is t= he only notification you will receive while this person is away.= = --0__=08BBF0D4DFEAD9AD8f9e8a93df938690918c08BBF0D4DFEAD9AD-- From leifj@mnt.se Mon Jul 30 13:33:40 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0074211E816F for ; Mon, 30 Jul 2012 13:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zl-khjf8172B for ; Mon, 30 Jul 2012 13:33:39 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id F1D3F11E817E for ; Mon, 30 Jul 2012 13:33:38 -0700 (PDT) Received: from [130.129.18.31] (dhcp-121f.meeting.ietf.org [130.129.18.31]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q6UKXTRu003744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Jul 2012 22:33:35 +0200 (CEST) Message-ID: <5016EF99.9050703@mnt.se> Date: Mon, 30 Jul 2012 22:33:29 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: scim WG References: <20120730032233.17770.35790.idtracker@ietfa.amsl.com> In-Reply-To: <20120730032233.17770.35790.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.3 X-Forwarded-Message-Id: <20120730032233.17770.35790.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [scim] Fwd: Need volunteers for the NomCom X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 20:33:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -------- Original Message -------- Subject: Need volunteers for the NomCom Date: Sun, 29 Jul 2012 20:22:33 -0700 From: NomCom Chair To: Working Group Chairs We are currently looking for volunteers to serve on the 2012-2013 NomCom. As you know, the success of the NomCom process depends crucially on having a large pool of volunteers from throughout the IETF community. In particular, it is valuable for the pool of volunteers to have strong representation from all of the technical areas within the IETF. I understand that not all IETF participants read the IETF announce list frequently. Therefore, if you would be willing to inform active participants in your working groups about this year's call for NomCom volunteers, I would greatly appreciate it. The NomCom 2012-2013 Call for Volunteers is open until this Sunday, August 5. Details can be found at: https://datatracker.ietf.org/ann/nomcom/49851/ Thank you for your help, - - Matt Lepinski mlepinski.ietf@gmail.com nomcom-chair@ietf.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAW75kACgkQ8Jx8FtbMZndMlwCbBnv/Akrm6HdA7bH75QKFSGHK rmYAoI5xgY/T2TTUmbJ5LgmF6FFc0AB7 =QoiW -----END PGP SIGNATURE----- From phil.hunt@oracle.com Tue Jul 31 10:25:46 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF0E21F85A0 for ; Tue, 31 Jul 2012 10:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.294 X-Spam-Level: X-Spam-Status: No, score=-10.294 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q12r3U+s+KSB for ; Tue, 31 Jul 2012 10:25:45 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id BE21E21F84E1 for ; Tue, 31 Jul 2012 10:25:44 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6VHPgSV013932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 31 Jul 2012 17:25:43 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6VHPfWt000647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Jul 2012 17:25:42 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6VHPfXX025505; Tue, 31 Jul 2012 12:25:41 -0500 Received: from [192.168.1.8] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 31 Jul 2012 10:25:41 -0700 From: Phil Hunt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Jul 2012 10:25:43 -0700 Message-Id: <42721FC7-1CF3-47F7-8A02-B2D5F362794E@oracle.com> To: scim@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: Leif Johansson Subject: [scim] Directory Support for SCIM X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 17:25:46 -0000 As discussed, I am proposing an informal meeting to discuss issues for = Directory Support of SCIM. The agenda is flexible. Some suggested = topics: * Support for Complex Attributes * LDAPv3 Client Compatibility - can existing clients be supported = without change to code (e.g. even filters or attribute names) -> Extended controls for LDAP access to complex data. * SCIM Directories - Should SCIM be the new LDAP? -> Will an LDAPv4 be needed? * Other topics? We can report a summary of our discussion in the SCIM WG session on = Friday. I propose we meet at the Hyatt Lobby at 1PM on Thursday to discuss. I = will see if I can arrange a room to meet and will let you know. Also, the agenda looks fairly open at lunch time. Would anyone like to = meet up for lunch at 11:45? Phil @independentid www.independentid.com phil.hunt@oracle.com From tonynad@microsoft.com Tue Jul 31 10:35:19 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE2B21F880D for ; Tue, 31 Jul 2012 10:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPsvNXpXflRg for ; Tue, 31 Jul 2012 10:35:18 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF1E21F84EB for ; Tue, 31 Jul 2012 10:35:16 -0700 (PDT) Received: from mail52-ch1-R.bigfish.com (10.43.68.239) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.23; Tue, 31 Jul 2012 17:35:15 +0000 Received: from mail52-ch1 (localhost [127.0.0.1]) by mail52-ch1-R.bigfish.com (Postfix) with ESMTP id BCCD91E024C for ; Tue, 31 Jul 2012 17:35:15 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VS-23(zz9371I542Mzz1202h1082kzz1033IL8275bh8275dhz2fh2a8h683h839h944hd25hf0ah107ah) Received-SPF: pass (mail52-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail52-ch1 (localhost.localdomain [127.0.0.1]) by mail52-ch1 (MessageSwitch) id 1343756113867243_10027; Tue, 31 Jul 2012 17:35:13 +0000 (UTC) Received: from CH1EHSMHS011.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.239]) by mail52-ch1.bigfish.com (Postfix) with ESMTP id C8965420046 for ; Tue, 31 Jul 2012 17:35:13 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS011.bigfish.com (10.43.70.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 31 Jul 2012 17:35:13 +0000 Received: from co1outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.2.309.3; Tue, 31 Jul 2012 17:34:58 +0000 Received: from mail82-co1-R.bigfish.com (10.243.78.243) by CO1EHSOBE016.bigfish.com (10.243.66.79) with Microsoft SMTP Server id 14.1.225.23; Tue, 31 Jul 2012 17:34:58 +0000 Received: from mail82-co1 (localhost [127.0.0.1]) by mail82-co1-R.bigfish.com (Postfix) with ESMTP id 362415A02E4 for ; Tue, 31 Jul 2012 17:34:58 +0000 (UTC) Received: from mail82-co1 (localhost.localdomain [127.0.0.1]) by mail82-co1 (MessageSwitch) id 1343756096562460_22083; Tue, 31 Jul 2012 17:34:56 +0000 (UTC) Received: from CO1EHSMHS020.bigfish.com (unknown [10.243.78.239]) by mail82-co1.bigfish.com (Postfix) with ESMTP id 85111100044; Tue, 31 Jul 2012 17:34:56 +0000 (UTC) Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by CO1EHSMHS020.bigfish.com (10.243.66.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 31 Jul 2012 17:34:53 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.12.232]) by BL2PRD0310HT001.namprd03.prod.outlook.com ([10.255.97.36]) with mapi id 14.16.0175.005; Tue, 31 Jul 2012 17:34:53 +0000 From: Anthony Nadalin To: Phil Hunt , "scim@ietf.org" Thread-Topic: [scim] Directory Support for SCIM Thread-Index: AQHNb0GZYSgMJQpYj0SO/C9EPe+dGZdDpjPg Date: Tue, 31 Jul 2012 17:34:52 +0000 Message-ID: References: <42721FC7-1CF3-47F7-8A02-B2D5F362794E@oracle.com> In-Reply-To: <42721FC7-1CF3-47F7-8A02-B2D5F362794E@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.19.205] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT001.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%ORACLE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%MNT.SE$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC105.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC105.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: Leif Johansson Subject: Re: [scim] Directory Support for SCIM X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 17:35:19 -0000 API operation simplification -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phi= l Hunt Sent: Tuesday, July 31, 2012 10:26 AM To: scim@ietf.org Cc: Leif Johansson Subject: [scim] Directory Support for SCIM As discussed, I am proposing an informal meeting to discuss issues for Dire= ctory Support of SCIM. The agenda is flexible. Some suggested topics: * Support for Complex Attributes * LDAPv3 Client Compatibility - can existing clients be supported without c= hange to code (e.g. even filters or attribute names) -> Extended controls for LDAP access to complex data. * SCIM Directories - Should SCIM be the new LDAP? -> Will an LDAPv4 be needed? * Other topics? We can report a summary of our discussion in the SCIM WG session on Friday. I propose we meet at the Hyatt Lobby at 1PM on Thursday to discuss. I will = see if I can arrange a room to meet and will let you know. Also, the agenda looks fairly open at lunch time. Would anyone like to meet= up for lunch at 11:45? Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim