From alexey.melnikov@isode.com Mon Jun 4 14:03:16 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 A731411E8105; Mon, 4 Jun 2012 14:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 2-+-JC1hL9xC; Mon, 4 Jun 2012 14:03:15 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 662F911E80DF; Mon, 4 Jun 2012 14:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1338843794; d=isode.com; s=selector; i=@isode.com; bh=7m+Tpb+ImSvavWNBDe3USoMJwwg7kV4GyDGUYbCdXro=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=DfKJgmxKlo7keI3x4N1ayYM3zJm0daqld90v7D49GtQFi+HiPsUn7hNEZpxWwKgYiC/cgS hnVDg6k3xEW3L7W+iR39yE/OxbB36hnKmyZ67PRC3eaUdcS7CT6wRM0FpytPD3JGISXdns hxpKTB2rh40AtGjW8FSEGnNyKuFiGJE=; Received: from [172.20.10.2] ((unknown) [212.183.128.204]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 4 Jun 2012 22:03:11 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FCD228C.1070402@isode.com> Date: Mon, 04 Jun 2012 22:03:08 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: scim@ietf.org, The IESG References: <20120531150837.7422.10288.idtracker@ietfa.amsl.com> In-Reply-To: <20120531150837.7422.10288.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 04 Jun 2012 14:05:13 -0700 Subject: Re: [scim] WG Review: System for Cross-domain Identity Management (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: Mon, 04 Jun 2012 21:03:16 -0000 On 31/05/2012 16:08, IESG Secretary wrote: > A new IETF working group has been proposed in the Applications > Area. The IESG has not made any determination as yet. The following > draft charter was submitted, and is provided for informational purposes > only. Please send your comments to the IESG mailing list (iesg@ietf.org) > by June 7, 2012. Ok, this version is much better than the one I complained about privately to some ADs. Either this, or I am getting used to it ;-). I have 2 comments on the latest Charter text that I would like to see addressed: 1). I would like the Charter to be crystally clear that the protocol being worked on is going to be HTTP-based. I don't think saying "RESTful" makes it unambiguous, because REST is style of software architecture. Also, "RESTful" probably needs a reference. 2). I would really like the initial milestone for the LDAP mapping to be *before* the scheme document is finished. This will help to make sure that the SCIM schema is not reinventing the wheel needlessly. (Of course I wish you would have just used the LDAP schema with no changes, then the mapping to LDAP becomes Noop. But that is probably a wishful thinking.) > System for Cross-domain Identity Management (SCIM) > ---------------------------------------------- > Status: Proposed Working Group > > Last updated: 2012-05-29 > > Chair(s): TBD > > Applications Area Director(s): > Pete Resnick > Barry Leiba > > Mailing Lists: > General Discussion:scim@ietf.org > To Subscribe:https://www.ietf.org/mailman/listinfo/scim > Archive:http://www.ietf.org/mail-archive/web/scim/ > > Description of Working Group: > > The System for Cross-domain Identity Management (SCIM) working group > will standardize methods for creating, reading, searching, modifying, > and deleting user identities and identity-related objects across > administrative domains, with the goal of simplifying common tasks > related to user identity management in services and applications. > > "Standardize" does not necessarily mean that the working group will > develop new technologies. For example, the existing specifications > for "SCIM 1.0" provide RESTful interfaces on top of HTTP rather than > defining a new application protocol. > > Today, distributed identity management across administrative domains > is complicated by a lack of protocol and schema standardization > between consumers and producers of identities. This has led to a > number of approaches, including error-prone manual administration and > bulk file uploads, as well as proprietary protocols and mediation > devices that must be adapted to each service for each organization. > While there is existing work in the field, it has not been widely > adopted for a variety of reasons, including a lack of common artifacts > such as schema, toolsets, and libraries. > > The SCIM working group will develop the core schema and RESTful > interfaces to address these problems. Initially, the group will focus > on > - a schema definition > - a set of operations for creation, modification, and deletion of users > - schema discovery > - read and search > - bulk operations > - mapping between the inetOrgPerson LDAP object class (RFC 2798) and > the SCIM schema > > It will follow that by considering extensions for client targeting of > specific SCIM endpoints and SAML binding. The approach will be > extensible. > > The group will use, as starting points, the following drafts in the > following ways: > draft-scim-use-cases-00 as the initial use cases for SCIM > draft-scim-core-schema-00 as the schema specification > draft-scim-api-00 as the protocol specification > > These drafts are based on existing specifications, which together are > commonly known as SCIM 1.0. Because there is existing work with > existing implementations, some consideration should be given to > backward compatibility, though getting it right takes priority. This > group will consider the operational experience gathered from the > existing work, as well as experiences with work done by other bodies, > including the OASIS Provisioning TC. > > The use cases document will be a "living document", guiding the > working group during its development of the standards. The group may > take snapshots of that document for Informational publication, to > serve as documentation of the motivation for the work in progress > and to similarly guide planning and implementation. > > The group will produce Proposed Standards for a schema, a REST-based > protocol, and a SAML binding, as well as an Informational document > defining an LDAP mapping. In doing so, the group will make the > terminology consistent, identify any functional gaps that would be > useful for future work, address internationalization, and provide > guidelines and mechanisms for extensibility. > > In addition, the working group will ensure that the SCIM protocol > embodies good security practices. Given both the sensitivity of the > information being conveyed in SCIM messages and the regulatory > requirements regarding the privacy of personally identifiable > information, the working group will pay particular attention to issues > around authorization, authenticity, and privacy. > > The group considers the following out of scope for this group: > Defining new authentication schemes > Defining new policy/authorization schemes > > Milestones > > 06/2012 Initial adoption of SCIM use cases, as a living document > 06/2012 Initial adoption of SCIM core schema > 08/2012 Initial adoption of SCIM restful interface draft > 12/2012 Snapshot version of SCIM use cases to IESG as Informational (possibly) > 12/2012 Proposal for client targeting of SCIM endpoints > 01/2013 Initial adoption of SCIM LDAP inetOrgPerson mapping draft > 02/2013 SCIM core schema to IESG as Proposed Standard > 05/2013 SCIM restful interface to IESG as Proposed Standard > 06/2013 SCIM LDAP inetOrgPerson mapping to IESG as Informational > 07/2013 Initial adoption of SCIM SAML bindings draft > 08/2013 Client targeting of SCIM endpoints to IESG as Proposed Standard > 09/2013 Snapshot update of SCIM use cases as Informational (possibly) > 11/2013 SCIM SAML bindings to IESG as Proposed Standard > 01/2014 Work completed; discuss re-charter From stpeter@stpeter.im Mon Jun 4 14:07:08 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 673F911E810D for ; Mon, 4 Jun 2012 14:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.845 X-Spam-Level: X-Spam-Status: No, score=-102.845 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 bOFu1Vl2sBLL for ; Mon, 4 Jun 2012 14:07:07 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BA01811E8107 for ; Mon, 4 Jun 2012 14:07:07 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0F846400A4; Mon, 4 Jun 2012 15:23:51 -0600 (MDT) Message-ID: <4FCD237A.3060508@stpeter.im> Date: Mon, 04 Jun 2012 15:07:06 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Alexey Melnikov References: <20120531150837.7422.10288.idtracker@ietfa.amsl.com> <4FCD228C.1070402@isode.com> In-Reply-To: <4FCD228C.1070402@isode.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: scim@ietf.org Subject: Re: [scim] WG Review: System for Cross-domain Identity Management (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: Mon, 04 Jun 2012 21:07:08 -0000 On 6/4/12 3:03 PM, Alexey Melnikov wrote: > On 31/05/2012 16:08, IESG Secretary wrote: >> A new IETF working group has been proposed in the Applications >> Area. The IESG has not made any determination as yet. The following >> draft charter was submitted, and is provided for informational purposes >> only. Please send your comments to the IESG mailing list (iesg@ietf.org) >> by June 7, 2012. > Ok, this version is much better than the one I complained about > privately to some ADs. Either this, or I am getting used to it ;-). > > I have 2 comments on the latest Charter text that I would like to see > addressed: > > 1). I would like the Charter to be crystally clear that the protocol > being worked on is going to be HTTP-based. I don't think saying > "RESTful" makes it unambiguous, because REST is style of software > architecture. Also, "RESTful" probably needs a reference. Architectural Styles and the Design of Network-based Software Architectures University of California, Irvine > 2). I would really like the initial milestone for the LDAP mapping to be > *before* the scheme document is finished. This will help to make sure > that the SCIM schema is not reinventing the wheel needlessly. (Of course > I wish you would have just used the LDAP schema with no changes, then > the mapping to LDAP becomes Noop. But that is probably a wishful thinking.) I'd prefer to use vCard4, but we can fight about that later. ;-) Peter -- Peter Saint-Andre https://stpeter.im/ From alexey.melnikov@isode.com Mon Jun 4 14:24: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 E9CEA11E810C for ; Mon, 4 Jun 2012 14:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 T9ojFwG6pihn for ; Mon, 4 Jun 2012 14:24:21 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id E19ED11E80DF for ; Mon, 4 Jun 2012 14:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1338845060; d=isode.com; s=selector; i=@isode.com; bh=bOVkXolo0qKJZVFcUgAzf3qLEjb+htvavp8D0Q3Ped4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=XYqw1iXWGa6aO8BZw9hHaxfKDnvjvIyjPVAKCvuFI0B8P72Z4Eekc44oLsJ8JHEpyo5vPb ezGB4r3ODijARo5Q4J8WGo3U5l967QCtYP2BJSOHQ4tI7/oRPRqGSglxr2xzqZkCThDBUH ofwBlieSHRALXSu6UN6WUMal2qsAYeM=; Received: from [172.20.10.2] ((unknown) [212.183.128.204]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 4 Jun 2012 22:24:18 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FCD277F.6010606@isode.com> Date: Mon, 04 Jun 2012 22:24:15 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Peter Saint-Andre References: <20120531150837.7422.10288.idtracker@ietfa.amsl.com> <4FCD228C.1070402@isode.com> <4FCD237A.3060508@stpeter.im> In-Reply-To: <4FCD237A.3060508@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 04 Jun 2012 14:25:10 -0700 Cc: scim@ietf.org Subject: Re: [scim] WG Review: System for Cross-domain Identity Management (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: Mon, 04 Jun 2012 21:24:22 -0000 On 04/06/2012 22:07, Peter Saint-Andre wrote: > On 6/4/12 3:03 PM, Alexey Melnikov wrote: >> On 31/05/2012 16:08, IESG Secretary wrote: [...] >> 2). I would really like the initial milestone for the LDAP mapping to be >> *before* the scheme document is finished. This will help to make sure >> that the SCIM schema is not reinventing the wheel needlessly. (Of course >> I wish you would have just used the LDAP schema with no changes, then >> the mapping to LDAP becomes Noop. But that is probably a wishful thinking.) > I'd prefer to use vCard4, but we can fight about that later. ;-) That would be my second preferred choice as well. (Anything other than Yet Another Schema for a User Account will do, really.) But LDAP mapping is already on the table... From lear@cisco.com Mon Jun 4 20:29:09 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 A4A7C21F869F; Mon, 4 Jun 2012 20:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 cx6ERT2Kzz7l; Mon, 4 Jun 2012 20:29:08 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 07E6721F86A0; Mon, 4 Jun 2012 20:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=6101; q=dns/txt; s=iport; t=1338866948; x=1340076548; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=9y0baCZLKGN9wqx1S7xlhpdRgp7nLY6I+xAQqtuz3XI=; b=jeDc+D5T1EkD4oD0EZwAku6oQwsjJsFCr8fudm186y6FCU3WUsbBQuAA xgtwgZ8UTfezcNLGzHYjD3B1T6TCWeEBMMbHfUVqQX37ZvTYR4T9B0QY9 48/YuNRvsxTEurAN6G2VT2BmYZICV8vCvgYE4Svo+LC0r0sDOWLvXzSx9 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOJ7zU+Q/khR/2dsb2JhbAA7AQmFTq5ggQeCGAEBAQMBAQEBDwEQSwoBEAsYAgIFAxMLAgIJAwIBAgEVMAYNAQMCAgEBBRmHZAULl0ONFpJagSOJbgkHAQmEZIESA5UbjhCBZoJiPIEYCQ X-IronPort-AV: E=Sophos;i="4.75,716,1330905600"; d="scan'208";a="5369565" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 05 Jun 2012 03:29:06 +0000 Received: from ams3-vpn-dhcp1146.cisco.com (ams3-vpn-dhcp1146.cisco.com [10.61.68.122]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q553T5rH031516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jun 2012 03:29:06 GMT Message-ID: <4FCD7D01.6020509@cisco.com> Date: Tue, 05 Jun 2012 05:29:05 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Alexey Melnikov References: <20120531150837.7422.10288.idtracker@ietfa.amsl.com> <4FCD228C.1070402@isode.com> In-Reply-To: <4FCD228C.1070402@isode.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: scim@ietf.org, The IESG Subject: Re: [scim] WG Review: System for Cross-domain Identity Management (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, 05 Jun 2012 03:29:09 -0000 Alexey, On 6/4/12 11:03 PM, Alexey Melnikov wrote: > > 2). I would really like the initial milestone for the LDAP mapping to > be *before* the scheme document is finished. This will help to make > sure that the SCIM schema is not reinventing the wheel needlessly. (Of > course I wish you would have just used the LDAP schema with no > changes, then the mapping to LDAP becomes Noop. But that is probably a > wishful thinking.) I don't understand your concern here- the milestones indicate precisely that below. Eliot >> System for Cross-domain Identity Management (SCIM) >> ---------------------------------------------- >> Status: Proposed Working Group >> >> Last updated: 2012-05-29 >> >> Chair(s): TBD >> >> Applications Area Director(s): >> Pete Resnick >> Barry Leiba >> >> Mailing Lists: >> General Discussion:scim@ietf.org >> To Subscribe:https://www.ietf.org/mailman/listinfo/scim >> Archive:http://www.ietf.org/mail-archive/web/scim/ >> >> Description of Working Group: >> >> The System for Cross-domain Identity Management (SCIM) working group >> will standardize methods for creating, reading, searching, modifying, >> and deleting user identities and identity-related objects across >> administrative domains, with the goal of simplifying common tasks >> related to user identity management in services and applications. >> >> "Standardize" does not necessarily mean that the working group will >> develop new technologies. For example, the existing specifications >> for "SCIM 1.0" provide RESTful interfaces on top of HTTP rather than >> defining a new application protocol. >> >> Today, distributed identity management across administrative domains >> is complicated by a lack of protocol and schema standardization >> between consumers and producers of identities. This has led to a >> number of approaches, including error-prone manual administration and >> bulk file uploads, as well as proprietary protocols and mediation >> devices that must be adapted to each service for each organization. >> While there is existing work in the field, it has not been widely >> adopted for a variety of reasons, including a lack of common artifacts >> such as schema, toolsets, and libraries. >> >> The SCIM working group will develop the core schema and RESTful >> interfaces to address these problems. Initially, the group will focus >> on >> - a schema definition >> - a set of operations for creation, modification, and deletion of users >> - schema discovery >> - read and search >> - bulk operations >> - mapping between the inetOrgPerson LDAP object class (RFC 2798) and >> the SCIM schema >> >> It will follow that by considering extensions for client targeting of >> specific SCIM endpoints and SAML binding. The approach will be >> extensible. >> >> The group will use, as starting points, the following drafts in the >> following ways: >> draft-scim-use-cases-00 as the initial use cases for SCIM >> draft-scim-core-schema-00 as the schema specification >> draft-scim-api-00 as the protocol specification >> >> These drafts are based on existing specifications, which together are >> commonly known as SCIM 1.0. Because there is existing work with >> existing implementations, some consideration should be given to >> backward compatibility, though getting it right takes priority. This >> group will consider the operational experience gathered from the >> existing work, as well as experiences with work done by other bodies, >> including the OASIS Provisioning TC. >> >> The use cases document will be a "living document", guiding the >> working group during its development of the standards. The group may >> take snapshots of that document for Informational publication, to >> serve as documentation of the motivation for the work in progress >> and to similarly guide planning and implementation. >> >> The group will produce Proposed Standards for a schema, a REST-based >> protocol, and a SAML binding, as well as an Informational document >> defining an LDAP mapping. In doing so, the group will make the >> terminology consistent, identify any functional gaps that would be >> useful for future work, address internationalization, and provide >> guidelines and mechanisms for extensibility. >> >> In addition, the working group will ensure that the SCIM protocol >> embodies good security practices. Given both the sensitivity of the >> information being conveyed in SCIM messages and the regulatory >> requirements regarding the privacy of personally identifiable >> information, the working group will pay particular attention to issues >> around authorization, authenticity, and privacy. >> >> The group considers the following out of scope for this group: >> Defining new authentication schemes >> Defining new policy/authorization schemes >> >> Milestones >> >> 06/2012 Initial adoption of SCIM use cases, as a living document >> 06/2012 Initial adoption of SCIM core schema >> 08/2012 Initial adoption of SCIM restful interface draft >> 12/2012 Snapshot version of SCIM use cases to IESG as >> Informational (possibly) >> 12/2012 Proposal for client targeting of SCIM endpoints >> 01/2013 Initial adoption of SCIM LDAP inetOrgPerson mapping draft >> 02/2013 SCIM core schema to IESG as Proposed Standard >> 05/2013 SCIM restful interface to IESG as Proposed Standard >> 06/2013 SCIM LDAP inetOrgPerson mapping to IESG as Informational >> 07/2013 Initial adoption of SCIM SAML bindings draft >> 08/2013 Client targeting of SCIM endpoints to IESG as Proposed >> Standard >> 09/2013 Snapshot update of SCIM use cases as Informational (possibly) >> 11/2013 SCIM SAML bindings to IESG as Proposed Standard >> 01/2014 Work completed; discuss re-charter > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > From alexey.melnikov@isode.com Tue Jun 5 03:16:37 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 6C85921F864D; Tue, 5 Jun 2012 03:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.987 X-Spam-Level: X-Spam-Status: No, score=-100.987 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] 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 IxP8EA-5cMbc; Tue, 5 Jun 2012 03:16:36 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEC021F85FC; Tue, 5 Jun 2012 03:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1338891394; d=isode.com; s=selector; i=@isode.com; bh=j8HX6pBwQLsDdL7NojQc/YqMUCY89OT8KOaETocrSEI=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=LcAcnsUVvAIreu2xEp0ibSrcOj4utqqdiPbTZT++6pn81OzP7L+kH7J9zrDZACHG4v1VD4 qY7s6DjDGs9P0wwAmrq28OTmNqlFpLDM94vW3ZPLT62DPKuBg7fmRXc0h+ugJciqtTzEsr A3dAwhS+SzjVGKSxA3madsBbxSgi8Tk=; Received: from [188.29.204.191] (188.29.204.191.threembb.co.uk [188.29.204.191]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 5 Jun 2012 11:16:33 +0100 References: <20120531150837.7422.10288.idtracker@ietfa.amsl.com> <4FCD228C.1070402@isode.com> <4FCD7D01.6020509@cisco.com> In-Reply-To: <4FCD7D01.6020509@cisco.com> Message-Id: <9DCD5D31-D3DF-45E3-B44A-0ED2C8B2756A@isode.com> X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Tue, 5 Jun 2012 11:16:31 +0100 To: Eliot Lear MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 05 Jun 2012 06:57:09 -0700 Cc: "scim@ietf.org" , The IESG Subject: Re: [scim] WG Review: System for Cross-domain Identity Management (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, 05 Jun 2012 10:16:37 -0000 Hi Eliot, On 5 Jun 2012, at 04:29, Eliot Lear wrote: > Alexey, >=20 > On 6/4/12 11:03 PM, Alexey Melnikov wrote: >>=20 >> 2). I would really like the initial milestone for the LDAP mapping to >> be *before* the scheme document is finished. This will help to make >> sure that the SCIM schema is not reinventing the wheel needlessly. (Of >> course I wish you would have just used the LDAP schema with no >> changes, then the mapping to LDAP becomes Noop. But that is probably a >> wishful thinking.) >=20 > I don't understand your concern here- the milestones indicate precisely > that below. >=20 Formally: yes. But the initial version of the LDAP mapping is supposed to be= adopted in January 2013 and the schema is going to IESG in February. Would a= ny changes to the schema due to LDAP be accepted at this point? I think the= answer would be "you must be kidding, we are done with the schema". So move the LDAP milestone earlier by 4-5 months. > Eliot >=20 >>> System for Cross-domain Identity Management (SCIM) >>> ---------------------------------------------- >>> Status: Proposed Working Group >>>=20 >>> Last updated: 2012-05-29 >>>=20 >>> Chair(s): TBD >>>=20 >>> Applications Area Director(s): >>> Pete Resnick >>> Barry Leiba >>>=20 >>> Mailing Lists: >>> General Discussion:scim@ietf.org >>> To Subscribe:https://www.ietf.org/mailman/listinfo/scim >>> Archive:http://www.ietf.org/mail-archive/web/scim/ >>>=20 >>> Description of Working Group: >>>=20 >>> The System for Cross-domain Identity Management (SCIM) working group >>> will standardize methods for creating, reading, searching, modifying, >>> and deleting user identities and identity-related objects across >>> administrative domains, with the goal of simplifying common tasks >>> related to user identity management in services and applications. >>>=20 >>> "Standardize" does not necessarily mean that the working group will >>> develop new technologies. For example, the existing specifications >>> for "SCIM 1.0" provide RESTful interfaces on top of HTTP rather than >>> defining a new application protocol. >>>=20 >>> Today, distributed identity management across administrative domains >>> is complicated by a lack of protocol and schema standardization >>> between consumers and producers of identities. This has led to a >>> number of approaches, including error-prone manual administration and >>> bulk file uploads, as well as proprietary protocols and mediation >>> devices that must be adapted to each service for each organization. >>> While there is existing work in the field, it has not been widely >>> adopted for a variety of reasons, including a lack of common artifacts >>> such as schema, toolsets, and libraries. >>>=20 >>> The SCIM working group will develop the core schema and RESTful >>> interfaces to address these problems. Initially, the group will focus >>> on >>> - a schema definition >>> - a set of operations for creation, modification, and deletion of users >>> - schema discovery >>> - read and search >>> - bulk operations >>> - mapping between the inetOrgPerson LDAP object class (RFC 2798) and >>> the SCIM schema >>>=20 >>> It will follow that by considering extensions for client targeting of >>> specific SCIM endpoints and SAML binding. The approach will be >>> extensible. >>>=20 >>> The group will use, as starting points, the following drafts in the >>> following ways: >>> draft-scim-use-cases-00 as the initial use cases for SCIM >>> draft-scim-core-schema-00 as the schema specification >>> draft-scim-api-00 as the protocol specification >>>=20 >>> These drafts are based on existing specifications, which together are >>> commonly known as SCIM 1.0. Because there is existing work with >>> existing implementations, some consideration should be given to >>> backward compatibility, though getting it right takes priority. This >>> group will consider the operational experience gathered from the >>> existing work, as well as experiences with work done by other bodies, >>> including the OASIS Provisioning TC. >>>=20 >>> The use cases document will be a "living document", guiding the >>> working group during its development of the standards. The group may >>> take snapshots of that document for Informational publication, to >>> serve as documentation of the motivation for the work in progress >>> and to similarly guide planning and implementation. >>>=20 >>> The group will produce Proposed Standards for a schema, a REST-based >>> protocol, and a SAML binding, as well as an Informational document >>> defining an LDAP mapping. In doing so, the group will make the >>> terminology consistent, identify any functional gaps that would be >>> useful for future work, address internationalization, and provide >>> guidelines and mechanisms for extensibility. >>>=20 >>> In addition, the working group will ensure that the SCIM protocol >>> embodies good security practices. Given both the sensitivity of the >>> information being conveyed in SCIM messages and the regulatory >>> requirements regarding the privacy of personally identifiable >>> information, the working group will pay particular attention to issues >>> around authorization, authenticity, and privacy. >>>=20 >>> The group considers the following out of scope for this group: >>> Defining new authentication schemes >>> Defining new policy/authorization schemes >>>=20 >>> Milestones >>>=20 >>> 06/2012 Initial adoption of SCIM use cases, as a living document >>> 06/2012 Initial adoption of SCIM core schema >>> 08/2012 Initial adoption of SCIM restful interface draft >>> 12/2012 Snapshot version of SCIM use cases to IESG as >>> Informational (possibly) >>> 12/2012 Proposal for client targeting of SCIM endpoints >>> 01/2013 Initial adoption of SCIM LDAP inetOrgPerson mapping draft >>> 02/2013 SCIM core schema to IESG as Proposed Standard >>> 05/2013 SCIM restful interface to IESG as Proposed Standard >>> 06/2013 SCIM LDAP inetOrgPerson mapping to IESG as Informational >>> 07/2013 Initial adoption of SCIM SAML bindings draft >>> 08/2013 Client targeting of SCIM endpoints to IESG as Proposed >>> Standard >>> 09/2013 Snapshot update of SCIM use cases as Informational (possibly)= >>> 11/2013 SCIM SAML bindings to IESG as Proposed Standard >>> 01/2014 Work completed; discuss re-charter >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >>=20 >>=20 From phil.hunt@oracle.com Tue Jun 5 08:53: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 305F021F8713; Tue, 5 Jun 2012 08:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.203 X-Spam-Level: X-Spam-Status: No, score=-9.203 tagged_above=-999 required=5 tests=[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 UFU4pP0wb5lZ; Tue, 5 Jun 2012 08:53:17 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0F221F86FE; Tue, 5 Jun 2012 08:53:16 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q55FrEQQ027047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Jun 2012 15:53:15 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 q55FrDAa022502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jun 2012 15:53:14 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q55FrDvJ028538; Tue, 5 Jun 2012 10:53:13 -0500 Received: from [25.64.91.172] (/74.198.150.172) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 05 Jun 2012 08:53:13 -0700 References: <20120531150837.7422.10288.idtracker@ietfa.amsl.com> <4FCD228C.1070402@isode.com> <4FCD7D01.6020509@cisco.com> <9DCD5D31-D3DF-45E3-B44A-0ED2C8B2756A@isode.com> In-Reply-To: <9DCD5D31-D3DF-45E3-B44A-0ED2C8B2756A@isode.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <54C26342-F0CF-4D92-A89A-046448D50126@oracle.com> X-Mailer: iPhone Mail (9B206) From: Phil Hunt Date: Tue, 5 Jun 2012 08:55:46 -0700 To: Alexey Melnikov X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "scim@ietf.org" , The IESG , Eliot Lear Subject: Re: [scim] WG Review: System for Cross-domain Identity Management (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, 05 Jun 2012 15:53:19 -0000 Fwiw. LDAP does not support complex attributes. Without an extension to ldap= schema it seems unlikely that the mapped data will be interoperable when ac= cessing via ldap.=20 This only matters if there is need for high fidelity mappings. IOW one where= the same scim entry can be written and read back.=20 Phil On 2012-06-05, at 3:16, Alexey Melnikov wrote: > Hi Eliot, >=20 > On 5 Jun 2012, at 04:29, Eliot Lear wrote: >=20 >> Alexey, >>=20 >> On 6/4/12 11:03 PM, Alexey Melnikov wrote: >>>=20 >>> 2). I would really like the initial milestone for the LDAP mapping to >>> be *before* the scheme document is finished. This will help to make >>> sure that the SCIM schema is not reinventing the wheel needlessly. (Of >>> course I wish you would have just used the LDAP schema with no >>> changes, then the mapping to LDAP becomes Noop. But that is probably a >>> wishful thinking.) >>=20 >> I don't understand your concern here- the milestones indicate precisely >> that below. >>=20 >=20 > Formally: yes. But the initial version of the LDAP mapping is supposed to b= e adopted in January 2013 and the schema is going to IESG in February. Would= any changes to the schema due to LDAP be accepted at this point? I think t= he answer would be "you must be kidding, we are done with the schema". >=20 > So move the LDAP milestone earlier by 4-5 months. >=20 >> Eliot >>=20 >>>> System for Cross-domain Identity Management (SCIM) >>>> ---------------------------------------------- >>>> Status: Proposed Working Group >>>>=20 >>>> Last updated: 2012-05-29 >>>>=20 >>>> Chair(s): TBD >>>>=20 >>>> Applications Area Director(s): >>>> Pete Resnick >>>> Barry Leiba >>>>=20 >>>> Mailing Lists: >>>> General Discussion:scim@ietf.org >>>> To Subscribe:https://www.ietf.org/mailman/listinfo/scim >>>> Archive:http://www.ietf.org/mail-archive/web/scim/ >>>>=20 >>>> Description of Working Group: >>>>=20 >>>> The System for Cross-domain Identity Management (SCIM) working group >>>> will standardize methods for creating, reading, searching, modifying, >>>> and deleting user identities and identity-related objects across >>>> administrative domains, with the goal of simplifying common tasks >>>> related to user identity management in services and applications. >>>>=20 >>>> "Standardize" does not necessarily mean that the working group will >>>> develop new technologies. For example, the existing specifications >>>> for "SCIM 1.0" provide RESTful interfaces on top of HTTP rather than >>>> defining a new application protocol. >>>>=20 >>>> Today, distributed identity management across administrative domains >>>> is complicated by a lack of protocol and schema standardization >>>> between consumers and producers of identities. This has led to a >>>> number of approaches, including error-prone manual administration and >>>> bulk file uploads, as well as proprietary protocols and mediation >>>> devices that must be adapted to each service for each organization. >>>> While there is existing work in the field, it has not been widely >>>> adopted for a variety of reasons, including a lack of common artifacts >>>> such as schema, toolsets, and libraries. >>>>=20 >>>> The SCIM working group will develop the core schema and RESTful >>>> interfaces to address these problems. Initially, the group will focus >>>> on >>>> - a schema definition >>>> - a set of operations for creation, modification, and deletion of users= >>>> - schema discovery >>>> - read and search >>>> - bulk operations >>>> - mapping between the inetOrgPerson LDAP object class (RFC 2798) and >>>> the SCIM schema >>>>=20 >>>> It will follow that by considering extensions for client targeting of >>>> specific SCIM endpoints and SAML binding. The approach will be >>>> extensible. >>>>=20 >>>> The group will use, as starting points, the following drafts in the >>>> following ways: >>>> draft-scim-use-cases-00 as the initial use cases for SCIM >>>> draft-scim-core-schema-00 as the schema specification >>>> draft-scim-api-00 as the protocol specification >>>>=20 >>>> These drafts are based on existing specifications, which together are >>>> commonly known as SCIM 1.0. Because there is existing work with >>>> existing implementations, some consideration should be given to >>>> backward compatibility, though getting it right takes priority. This >>>> group will consider the operational experience gathered from the >>>> existing work, as well as experiences with work done by other bodies, >>>> including the OASIS Provisioning TC. >>>>=20 >>>> The use cases document will be a "living document", guiding the >>>> working group during its development of the standards. The group may >>>> take snapshots of that document for Informational publication, to >>>> serve as documentation of the motivation for the work in progress >>>> and to similarly guide planning and implementation. >>>>=20 >>>> The group will produce Proposed Standards for a schema, a REST-based >>>> protocol, and a SAML binding, as well as an Informational document >>>> defining an LDAP mapping. In doing so, the group will make the >>>> terminology consistent, identify any functional gaps that would be >>>> useful for future work, address internationalization, and provide >>>> guidelines and mechanisms for extensibility. >>>>=20 >>>> In addition, the working group will ensure that the SCIM protocol >>>> embodies good security practices. Given both the sensitivity of the >>>> information being conveyed in SCIM messages and the regulatory >>>> requirements regarding the privacy of personally identifiable >>>> information, the working group will pay particular attention to issues >>>> around authorization, authenticity, and privacy. >>>>=20 >>>> The group considers the following out of scope for this group: >>>> Defining new authentication schemes >>>> Defining new policy/authorization schemes >>>>=20 >>>> Milestones >>>>=20 >>>> 06/2012 Initial adoption of SCIM use cases, as a living document >>>> 06/2012 Initial adoption of SCIM core schema >>>> 08/2012 Initial adoption of SCIM restful interface draft >>>> 12/2012 Snapshot version of SCIM use cases to IESG as >>>> Informational (possibly) >>>> 12/2012 Proposal for client targeting of SCIM endpoints >>>> 01/2013 Initial adoption of SCIM LDAP inetOrgPerson mapping draft >>>> 02/2013 SCIM core schema to IESG as Proposed Standard >>>> 05/2013 SCIM restful interface to IESG as Proposed Standard >>>> 06/2013 SCIM LDAP inetOrgPerson mapping to IESG as Informational >>>> 07/2013 Initial adoption of SCIM SAML bindings draft >>>> 08/2013 Client targeting of SCIM endpoints to IESG as Proposed >>>> Standard >>>> 09/2013 Snapshot update of SCIM use cases as Informational (possibly= ) >>>> 11/2013 SCIM SAML bindings to IESG as Proposed Standard >>>> 01/2014 Work completed; discuss re-charter >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>>=20 >>>=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From barryleiba.mailing.lists@gmail.com Fri Jun 15 07:47:17 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 7975021F8597 for ; Fri, 15 Jun 2012 07:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.826 X-Spam-Level: X-Spam-Status: No, score=-102.826 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 Iuh0LbpccPjW for ; Fri, 15 Jun 2012 07:47:17 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABF721F870F for ; Fri, 15 Jun 2012 07:46:58 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3272484lbb.31 for ; Fri, 15 Jun 2012 07:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=V3syUpmYXr6utjdjJmBqUI+w7XEl3Hj1lMyuQMZiaE0=; b=HIvp4EZv6pbssG4sDcV46ifrduIO5YAJkrDRzS03ferX8/VVOHyhMtMt0gg4TcO89F lynpMLnISPYyhoMjluB5TkOTXp0Nk4aoh+iRsawe5bcAvwTR5wt/CEhKyuTiEIXoaGPh hBIWO71rZStsWCm7+yrLuFlNt32txcU7TA1s+8mNi6qAMtxdbC2IM2y+cO3MI0QcoOuZ 5qtpnX2O7IymXMEgLqazJhpYN9xj+bggg2qKVAt//K4mIbLpdY/IrCPMdXe0/MRHkrsa 4nwffbomvPTxZ8GagC9T1QaaACxfbdbvOsREGat7dOc17lD76LJy4X3qb05yHlj3fa/7 5nZg== MIME-Version: 1.0 Received: by 10.112.98.231 with SMTP id el7mr2731869lbb.14.1339771617263; Fri, 15 Jun 2012 07:46:57 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.48.104 with HTTP; Fri, 15 Jun 2012 07:46:57 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 Jun 2012 10:46:57 -0400 X-Google-Sender-Auth: 3JrmopdV2LVMj5m-61yI0F_7f-0 Message-ID: From: Barry Leiba To: scim@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [scim] SCIM charter has passed the first step 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, 15 Jun 2012 14:47:17 -0000 > Expect to see a final "SCIM is chartered" > announcement the week of 11 June, unless you hear something otherwise > from me before then. Since it's the end of the week, I should post an update: The charter *was* approved on the 7 June telechat, and everything is OK. It's only the announcement that's been delayed, by an administrative issue: the automated tools that the Secretariat uses to set this stuff up currently has some problems that the tools team is working on.[1] Working group charter announcements (there are a few of them) are being held up until the tool is fixed and the proper system updates can be made. So keep watching for the announcement... Real Soon Now. Barry, responsible AD [1] Just a note: please don't grumble about the tools team... they do *excellent* work, and this is all volunteer. Gradually, some of the tools are being folded into paid contract work over time. But the tools we're talking about here are done by volunteers who have *really* made our lives easier over the past years. Consider volunteering for the "code sprint" on the Saturday before the Vancouver IETF meeting. That's where a bunch of folks get together and work on the bug/feature list... and you can get your name on the screen in the administrative plenary session. From iesg-secretary@ietf.org Thu Jun 21 12:21:38 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 1D79721F87BE; Thu, 21 Jun 2012 12:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 k9tHq+SzUoBu; Thu, 21 Jun 2012 12:21:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2431321F87BF; Thu, 21 Jun 2012 12:21:37 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.21 Message-ID: <20120621192137.24776.70032.idtracker@ietfa.amsl.com> Date: Thu, 21 Jun 2012 12:21:37 -0700 Cc: scim WG Subject: [scim] WG Action: Formed System for Cross-domain Identity Management (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: Thu, 21 Jun 2012 19:21:38 -0000 A new IETF working group has been formed in the Applications Area. For additional information please contact the Area Directors or the WG Chairs. System for Cross-domain Identity Management (scim) ------------------------------------------------ Current Status: Active Working Group Chairs: Morteza Ansari Leif Johansson Assigned Area Director: Barry Leiba Mailing list Address: scim@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/scim Archive: http://www.ietf.org/mail-archive/web/scim/ Charter of Working Group: The System for Cross-domain Identity Management (SCIM) working group will standardize methods for creating, reading, searching, modifying, and deleting user identities and identity-related objects across administrative domains, with the goal of simplifying common tasks related to user identity management in services and applications. "Standardize" does not necessarily mean that the working group will develop new technologies. The existing specifications for "SCIM 1.0" provide RESTful interfaces on top of HTTP rather than defining a new application protocol. That will be the basis for the new work. Today, distributed identity management across administrative domains is complicated by a lack of protocol and schema standardization between consumers and producers of identities. This has led to a number of approaches, including error-prone manual administration and bulk file uploads, as well as proprietary protocols and mediation devices that must be adapted to each service for each organization. While there is existing work in the field, it has not been widely adopted for a variety of reasons, including a lack of common artifacts such as schema, toolsets, and libraries. The SCIM working group will develop the core schema and interfaces based on HTTP and REST to address these problems. Initially, the group will focus on - a schema definition - a set of operations for creation, modification, and deletion of users - schema discovery - read and search - bulk operations - mapping between the inetOrgPerson LDAP object class (RFC 2798) and the SCIM schema It will follow that by considering extensions for client targeting of specific SCIM endpoints and SAML binding. The approach will be extensible. The group will use, as starting points, the following drafts in the following ways: draft-scim-use-cases-00 as the initial use cases for SCIM draft-scim-core-schema-00 as the schema specification draft-scim-api-00 as the protocol specification These drafts are based on existing specifications, which together are commonly known as SCIM 1.0. Because there is existing work with existing implementations, some consideration should be given to backward compatibility, though getting it right takes priority. This group will consider the operational experience gathered from the existing work, as well as experiences with work done by other bodies, including the OASIS Provisioning TC. The use cases document will be a "living document", guiding the working group during its development of the standards. The group may take snapshots of that document for Informational publication, to serve as documentation of the motivation for the work in progress and to similarly guide planning and implementation. The group will produce Proposed Standards for a schema, a REST-based protocol, and a SAML binding, as well as an Informational document defining an LDAP mapping. In doing so, the group will make the terminology consistent, identify any functional gaps that would be useful for future work, address internationalization, and provide guidelines and mechanisms for extensibility. In addition, the working group will ensure that the SCIM protocol embodies good security practices. Given both the sensitivity of the information being conveyed in SCIM messages and the regulatory requirements regarding the privacy of personally identifiable information, the working group will pay particular attention to issues around authorization, authenticity, and privacy. The group considers the following out of scope for this group: Defining new authentication schemes Defining new policy/authorization schemes Milestones: Jun 2012 - Initial adoption of SCIM use cases, as a living document Jun 2012 - Initial adoption of SCIM core schema Aug 2012 - Initial adoption of SCIM restful interface draft Nov 2012 - Initial adoption of SCIM LDAP inetOrgPerson mapping draft Dec 2012 - Snapshot version of SCIM use cases to IESG as Informational (possibly) Dec 2012 - Proposal for client targeting of SCIM endpoints Feb 2013 - SCIM core schema to IESG as Proposed Standard May 2013 - SCIM restful interface to IESG as Proposed Standard Jun 2013 - SCIM LDAP inetOrgPerson mapping to IESG as Informational Jul 2013 - Initial adoption of SCIM SAML bindings draft Aug 2013 - Client targeting of SCIM endpoints to IESG as Proposed Standard Sep 2013 - Snapshot update of SCIM use cases as Informational (possibly) Nov 2013 - SCIM SAML bindings to IESG as Proposed Standard Jan 2014 - Work completed; discuss re-charter From barryleiba.mailing.lists@gmail.com Thu Jun 21 12:36: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 23E3F11E80BC for ; Thu, 21 Jun 2012 12:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.936 X-Spam-Level: X-Spam-Status: No, score=-102.936 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 xEP51588BLI4 for ; Thu, 21 Jun 2012 12:36:00 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB0F11E80C1 for ; Thu, 21 Jun 2012 12:35:59 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2815131lbb.31 for ; Thu, 21 Jun 2012 12:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Iqgs9nF5oTNKEwrXkdH61UKQly2pAAzvLaaoi6F3b6g=; b=oI0uWjTTS5pQWSi38HRJLU3ol2OsQV3omIgqiQbVb/OFLvcPIOXigWUrijvo7OkJrv 86DZvatG4MhNJzuIKqSWBtoz3Ix3sa8JVaVipz2EIT6CyG20gw2q1Pl9cpDjx2VFtHoN P2frw3LBkpbmupT5MQdvslXlceglduTMBRRf2QV+wR85uZSWmk9WNtDkiN3a3hTfqdr7 YkpE+xOSdeKiatAysQwF2xQNJVDdo7SQbtvRAnySTQUbbKmHmVXkfSAwHarff5qN4caS eEGpoGV+PD/g7RvZieYzRNCJunsMjskVgb3QuqnCiwRyg1MHmxn0heGEVC8a/INta47u ruCA== MIME-Version: 1.0 Received: by 10.152.105.173 with SMTP id gn13mr27583355lab.20.1340307359148; Thu, 21 Jun 2012 12:35:59 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.48.104 with HTTP; Thu, 21 Jun 2012 12:35:59 -0700 (PDT) In-Reply-To: <20120621192137.24776.70032.idtracker@ietfa.amsl.com> References: <20120621192137.24776.70032.idtracker@ietfa.amsl.com> Date: Thu, 21 Jun 2012 15:35:59 -0400 X-Google-Sender-Auth: VB256zWmigit1auUgD5Z01XMg0A Message-ID: From: Barry Leiba To: scim WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: scim chairs Subject: Re: [scim] WG Action: Formed System for Cross-domain Identity Management (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: Thu, 21 Jun 2012 19:36:01 -0000 > A new IETF working group has been formed in the Applications Area. For > additional information please contact the Area Directors or the WG > Chairs. > > System for Cross-domain Identity Management (scim) > ------------------------------------------------ > Current Status: Active Working Group > > Chairs: > =A0Morteza Ansari > =A0Leif Johansson > > Assigned Area Director: > =A0Barry Leiba Yay, and here we go. The bug in the administrative tools has been fixed, and the announcement is out. As you can see, Morteza and Leif are your chairs, and you may contact them with the alias (it might or might not be working right now, but if it's not, it will be soon). They'll be posting here soon to get things moving. We did make a session request for IETF 84 in Vancouver, so there will be a session on the agenda for SCIM there. Barry From leifj@sunet.se Thu Jun 21 13:50: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 56C0221F85B5 for ; Thu, 21 Jun 2012 13:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-1.333, 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 zvjIyJeh-BbB for ; Thu, 21 Jun 2012 13:50:43 -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 5391F21F85A8 for ; Thu, 21 Jun 2012 13:50:42 -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 q5LKoV1l003725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2012 22:50:35 +0200 (CEST) Message-ID: <4FE38916.20300@sunet.se> Date: Thu, 21 Jun 2012 22:50:30 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: scim WG References: <20120621192137.24776.70032.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 21 Jun 2012 14:02:36 -0700 Cc: scim chairs , Barry Leiba Subject: Re: [scim] WG Action: Formed System for Cross-domain Identity Management (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: Thu, 21 Jun 2012 20:50:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Yay, and here we go. The bug in the administrative tools has been > fixed, and the announcement is out. > > As you can see, Morteza and Leif are your chairs, and you may > contact them with the alias (it might > or might not be working right now, but if it's not, it will be > soon). They'll be posting here soon to get things moving. > > We did make a session request for IETF 84 in Vancouver, so there > will be a session on the agenda for SCIM there. > > Barry Thanks Barry, Morteza and me will be posting a draft agenda in the next few days. This is the first time SCIM meets as a WG and we will devote a little bit of time to re-cap and level-setting and then devote much of our time to technical discussions. Best Leif & Morteza -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/jiRIACgkQ8Jx8FtbMZnfpHACfbgpmmZDx3En3E1UqukoWOfc0 0PkAnjnFOhc4XMMhBgfifkbrWk2Y9JNn =0l4L -----END PGP SIGNATURE----- From phil.hunt@oracle.com Sat Jun 23 11:44:58 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 398EC21F84FF for ; Sat, 23 Jun 2012 11:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 4T6IIyq5+dSl for ; Sat, 23 Jun 2012 11:44:57 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2A721F84E6 for ; Sat, 23 Jun 2012 11:44:56 -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 q5NIitsJ032433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 23 Jun 2012 18:44:56 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q5NIitYA009269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 23 Jun 2012 18:44:55 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q5NIitsn016835 for ; Sat, 23 Jun 2012 13:44:55 -0500 Received: from [192.168.1.7] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 23 Jun 2012 11:44:54 -0700 From: Phil Hunt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 23 Jun 2012 11:43:54 -0700 Message-Id: To: scim@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Subject: [scim] Filter should be encoded 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, 23 Jun 2012 18:44:58 -0000 I've noticed that the GET 'filter' parameter is intended as a URL = parameter. Since it is space delimited this will cause an invalid URL. I = am assuming the spec should indicate URL encoding (e.g. %20). =20 Am I missing something? Phil @independentid www.independentid.com phil.hunt@oracle.com From mrutkows@us.ibm.com Sat Jun 23 15:06:14 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 BF2E521F860F for ; Sat, 23 Jun 2012 15:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.998 X-Spam-Level: X-Spam-Status: No, score=-7.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 OiIVXcXlvsnb for ; Sat, 23 Jun 2012 15:06:14 -0700 (PDT) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by ietfa.amsl.com (Postfix) with ESMTP id 04DC321F8622 for ; Sat, 23 Jun 2012 15:06:13 -0700 (PDT) Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sat, 23 Jun 2012 16:06:09 -0600 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e39.co.us.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Sat, 23 Jun 2012 16:06:08 -0600 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id BAA833E4005E for ; Sat, 23 Jun 2012 22:06:06 +0000 (WET) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q5NM6675179224 for ; Sat, 23 Jun 2012 16:06:06 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q5NM658A007458 for ; Sat, 23 Jun 2012 16:06:05 -0600 Received: from d03nm133.boulder.ibm.com (d03nm133.boulder.ibm.com [9.17.195.180]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q5NM65cu007436 for ; Sat, 23 Jun 2012 16:06:05 -0600 Auto-Submitted: auto-generated From: Matt Rutkowski To: scim@ietf.org Message-ID: Date: Sat, 23 Jun 2012 16:06:04 -0600 X-MIMETrack: Serialize by Router on D03NM133/03/M/IBM(Release 8.5.3HF266 | January 13, 2012) at 06/23/2012 16:06:05 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBF0B5DFEAE1738f9e8a93df938690918c08BBF0B5DFEAE173" Content-Disposition: inline X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12062322-4242-0000-0000-000002187692 Subject: [scim] AUTO: Matt Rutkowski/Austin/IBM is travelling (returning 07/02/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: Sat, 23 Jun 2012 22:06:15 -0000 --0__=08BBF0B5DFEAE1738f9e8a93df938690918c08BBF0B5DFEAE173 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I am out of the office until 07/02/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 = 6, Issue 6" sent on 06/23/2012 13:00:15. This is the only notification you will receive while this person is awa= y.= --0__=08BBF0B5DFEAE1738f9e8a93df938690918c08BBF0B5DFEAE173 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I am out of the office until 07= /02/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 6, Issue 6" sent o= n 06/23/2012 13:00:15.

This is t= he only notification you will receive while this person is away.= = --0__=08BBF0B5DFEAE1738f9e8a93df938690918c08BBF0B5DFEAE173-- From prvs=45227CD5D3=erik.wahlstrom@nexussafe.com Sun Jun 24 00:57: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 D591221F8648 for ; Sun, 24 Jun 2012 00:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 3+sc4e-2dQF0 for ; Sun, 24 Jun 2012 00:57:19 -0700 (PDT) Received: from MailEdge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 704A121F863D for ; Sun, 24 Jun 2012 00:57:17 -0700 (PDT) Received: from MARVMAILCAS.technxs.com (10.75.28.35) by MailEdge.nexussafe.com (83.241.133.98) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 24 Jun 2012 09:59:23 +0200 Received: from MARVMAILDB.technxs.com ([fe80::b01b:248c:aaec:bf11]) by MarvMailCAS.technxs.com ([::1]) with mapi id 14.01.0355.002; Sun, 24 Jun 2012 09:56:46 +0200 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= To: Phil Hunt Thread-Topic: [scim] Filter should be encoded Thread-Index: AQHNUXA+xyJRJlXpcES7F2BlTLZMZpcI+YQA Date: Sun, 24 Jun 2012 07:56:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.75.28.12] Content-Type: multipart/alternative; boundary="_000_A02C2991B27949EE9BF92454861A2286nexussafecom_" MIME-Version: 1.0 Cc: "" Subject: Re: [scim] Filter should be encoded 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, 24 Jun 2012 07:57:20 -0000 --_000_A02C2991B27949EE9BF92454861A2286nexussafecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Phil, Yes, that's correct, it should be encoded. There are a small text segment a= bout that under "Notational Conventions ". It's not encoded in the examples= for readability. http://tools.ietf.org/html/draft-scim-api-00#section-1.2 Cheers Erik On Jun 23, 2012, at 8:43 PM, Phil Hunt wrote: I've noticed that the GET 'filter' parameter is intended as a URL parameter= . Since it is space delimited this will cause an invalid URL. I am assuming= the spec should indicate URL encoding (e.g. %20). Am I missing something? Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_A02C2991B27949EE9BF92454861A2286nexussafecom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Phil,


Yes, that's correct, it should be encoded. There are a small text segm= ent about that under "Notational Conventions ". It's not encoded = in the examples for readability.


Cheers
Erik

On Jun 23, 2012, at 8:43 PM, Phil Hunt wrote:

I've noticed that the GET 'filter' parameter is intended as a URL para= meter. Since it is space delimited this will cause an invalid URL. I am ass= uming the spec should indicate URL encoding (e.g. %20).  

Am I missing something?

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





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

--_000_A02C2991B27949EE9BF92454861A2286nexussafecom_-- From phil.hunt@oracle.com Wed Jun 27 12:34: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 10CB321F86A8 for ; Wed, 27 Jun 2012 12:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.424 X-Spam-Level: X-Spam-Status: No, score=-10.424 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] 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 vcmHowEZcvtA for ; Wed, 27 Jun 2012 12:34:53 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 41B8D21F85F6 for ; Wed, 27 Jun 2012 12:34:53 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5RJYpGD012740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 27 Jun 2012 19:34:51 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 q5RJYoIu012847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 27 Jun 2012 19:34:51 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q5RJYouv014321 for ; Wed, 27 Jun 2012 14:34:50 -0500 Received: from dhcp-amer-vpn-rmdc-anyconnect-10-159-171-74.vpn.oracle.com (/10.159.171.74) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 27 Jun 2012 12:34:50 -0700 From: Phil Hunt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jun 2012 12:34:57 -0700 Message-Id: <67261554-7E01-4FBD-B7E5-4EF6F3487BAE@oracle.com> To: scim@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [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: Wed, 27 Jun 2012 19:34:54 -0000 Has any consideration been given to allowing searching in SCIM with a = POST operation? The reason is, that the URL based approach in GET means = high-risk filters can be caught up in logs and is generally something to = be avoided. We have a security concern about passing parameters in many = cases using GET. =20 In thinking about how to do this, could we allow/reserve POST for = queries and BULK, and expand PUT to support add/replace. Such as with = /Users for an add, and /Users/identifier for a replace. Right now POST = is used for replace and for Bulk. If this was discussed in the consortium, maybe someone could summarize = the current position on the IETF list here? Another alternative is to allow GET parameters to be passed in the = header. Phil @independentid www.independentid.com phil.hunt@oracle.com From tonynad@microsoft.com Wed Jun 27 16:27:17 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 B66D311E8126 for ; Wed, 27 Jun 2012 16:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.717 X-Spam-Level: X-Spam-Status: No, score=-0.717 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 azlor3hjNwFt for ; Wed, 27 Jun 2012 16:27:17 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id A9E2511E80A6 for ; Wed, 27 Jun 2012 16:27:13 -0700 (PDT) Received: from mail82-am1-R.bigfish.com (10.3.201.236) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Jun 2012 23:25:28 +0000 Received: from mail82-am1 (localhost [127.0.0.1]) by mail82-am1-R.bigfish.com (Postfix) with ESMTP id 0C001260375 for ; Wed, 27 Jun 2012 23:25:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VS-23(zz9371I542Mzz1202h1082kzz1033IL8275bh8275dhz2fh2a8h683h839h944hd25hf0ah) Received-SPF: pass (mail82-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=TK5EX14HUBC103.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 mail82-am1 (localhost.localdomain [127.0.0.1]) by mail82-am1 (MessageSwitch) id 1340839526365400_16741; Wed, 27 Jun 2012 23:25:26 +0000 (UTC) Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.239]) by mail82-am1.bigfish.com (Postfix) with ESMTP id 4D6814E0044 for ; Wed, 27 Jun 2012 23:25:26 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 27 Jun 2012 23:25:26 +0000 Received: from CH1EHSOBE014.bigfish.com (157.54.51.81) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.2.309.3; Wed, 27 Jun 2012 23:27:08 +0000 Received: from mail142-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Jun 2012 23:25:22 +0000 Received: from mail142-ch1 (localhost [127.0.0.1]) by mail142-ch1-R.bigfish.com (Postfix) with ESMTP id 66569A0489 for ; Wed, 27 Jun 2012 23:25:22 +0000 (UTC) Received: from mail142-ch1 (localhost.localdomain [127.0.0.1]) by mail142-ch1 (MessageSwitch) id 1340839520893167_10428; Wed, 27 Jun 2012 23:25:20 +0000 (UTC) Received: from CH1EHSMHS028.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242]) by mail142-ch1.bigfish.com (Postfix) with ESMTP id CE819160046; Wed, 27 Jun 2012 23:25:20 +0000 (UTC) Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS028.bigfish.com (10.43.70.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 27 Jun 2012 23:25:21 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.10.205]) by BL2PRD0310HT001.namprd03.prod.outlook.com ([10.255.97.36]) with mapi id 14.16.0164.004; Wed, 27 Jun 2012 23:27:04 +0000 From: Anthony Nadalin To: Phil Hunt , "scim@ietf.org" Thread-Topic: [scim] Searching with POST instead of GET Thread-Index: AQHNVJv8g0QR19A2hU6fZWmcUh7Iu5cOzmzg Date: Wed, 27 Jun 2012 23:27:04 +0000 Message-ID: References: <67261554-7E01-4FBD-B7E5-4EF6F3487BAE@oracle.com> In-Reply-To: <67261554-7E01-4FBD-B7E5-4EF6F3487BAE@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.57] 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-CrossPremisesHeadersPromoted: TK5EX14HUBC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com 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: Wed, 27 Jun 2012 23:27:17 -0000 PUT could be a replace object, or create a named object, when applicable POST could be create a new object based on data provided, or submit a comm= and -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phi= l Hunt Sent: Wednesday, June 27, 2012 12:35 PM To: scim@ietf.org Subject: [scim] Searching with POST instead of GET Has any consideration been given to allowing searching in SCIM with a POST = operation? The reason is, that the URL based approach in GET means high-ris= k filters can be caught up in logs and is generally something to be avoided= . We have a security concern about passing parameters in many cases using G= ET. =20 In thinking about how to do this, could we allow/reserve POST for queries a= nd BULK, and expand PUT to support add/replace. Such as with /Users for an = add, and /Users/identifier for a replace. Right now POST is used for repla= ce and for Bulk. If this was discussed in the consortium, maybe someone could summarize the = current position on the IETF list here? Another alternative is to allow GET parameters to be passed in the header. Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From phil.hunt@oracle.com Wed Jun 27 16:44: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 C16B111E80A6 for ; Wed, 27 Jun 2012 16:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.459 X-Spam-Level: X-Spam-Status: No, score=-10.459 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] 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 lbbCrkqYLju7 for ; Wed, 27 Jun 2012 16:44:13 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id E200E11E80D3 for ; Wed, 27 Jun 2012 16:30: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 q5RNUYkH000932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Jun 2012 23:30:35 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 q5RNUXtP017096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jun 2012 23:30:34 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q5RNUXRm000484; Wed, 27 Jun 2012 18:30:33 -0500 Received: from dhcp-amer-vpn-rmdc-anyconnect-10-159-178-218.vpn.oracle.com (/10.159.178.218) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 27 Jun 2012 16:30:33 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: Date: Wed, 27 Jun 2012 16:30:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9B9F7C7A-A3FB-4E6E-B686-45E7AA452607@oracle.com> References: <67261554-7E01-4FBD-B7E5-4EF6F3487BAE@oracle.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.1278) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "scim@ietf.org" 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: Wed, 27 Jun 2012 23:44:13 -0000 The requirement is to do a search without using GET. IOW a non-url = based search where the URL only shows /Users or /Users/id. I know what the spec currently says. What I'm trying to do is open the = possibility for POST to do a search. Hopefully that clarifies. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-06-27, at 4:27 PM, Anthony Nadalin wrote: > PUT could be a replace object, or create a named object, when = applicable > POST could be create a new object based on data provided, or submit a = command >=20 >=20 > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Phil Hunt > Sent: Wednesday, June 27, 2012 12:35 PM > To: scim@ietf.org > Subject: [scim] Searching with POST instead of GET >=20 > Has any consideration been given to allowing searching in SCIM with a = POST operation? The reason is, that the URL based approach in GET means = high-risk filters can be caught up in logs and is generally something to = be avoided. We have a security concern about passing parameters in many = cases using GET. =20 >=20 > In thinking about how to do this, could we allow/reserve POST for = queries and BULK, and expand PUT to support add/replace. Such as with = /Users for an add, and /Users/identifier for a replace. Right now POST = is used for replace and for Bulk. >=20 > If this was discussed in the consortium, maybe someone could summarize = the current position on the IETF list here? >=20 > Another alternative is to allow GET parameters to be passed in the = header. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From igor.faynberg@alcatel-lucent.com Wed Jun 27 17:18:09 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 5A81311E814C for ; Wed, 27 Jun 2012 17:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.872 X-Spam-Level: X-Spam-Status: No, score=-9.872 tagged_above=-999 required=5 tests=[AWL=0.726, 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 pAE2FMSqAJsn for ; Wed, 27 Jun 2012 17:18:08 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADAC11E8149 for ; Wed, 27 Jun 2012 17:18:08 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q5S0I78A021468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 27 Jun 2012 19:18:07 -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 q5S0I7e8007581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 27 Jun 2012 19:18:07 -0500 Received: from [135.244.33.64] (faynberg.lra.lucent.com [135.244.33.64]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q5S0I67n013934; Wed, 27 Jun 2012 19:18:06 -0500 (CDT) Message-ID: <4FEBA2BE.2050006@alcatel-lucent.com> Date: Wed, 27 Jun 2012 20:18:06 -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: <67261554-7E01-4FBD-B7E5-4EF6F3487BAE@oracle.com> <9B9F7C7A-A3FB-4E6E-B686-45E7AA452607@oracle.com> In-Reply-To: <9B9F7C7A-A3FB-4E6E-B686-45E7AA452607@oracle.com> Content-Type: multipart/alternative; boundary="------------090408050602050604030207" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [scim] Searching with POST instead of GET 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: Thu, 28 Jun 2012 00:18:09 -0000 This is a multi-part message in MIME format. --------------090408050602050604030207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Why not pass the search query parameters in the POST data block? Igor | | On 6/27/2012 7:30 PM, Phil Hunt wrote: > The requirement is to do a search without using GET. IOW a non-url based search where the URL only shows /Users or /Users/id. > > I know what the spec currently says. What I'm trying to do is open the possibility for POST to do a search. Hopefully that clarifies. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2012-06-27, at 4:27 PM, Anthony Nadalin wrote: > >> PUT could be a replace object, or create a named object, when applicable >> POST could be create a new object based on data provided, or submit a command >> >> >> -----Original Message----- >> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt >> Sent: Wednesday, June 27, 2012 12:35 PM >> To: scim@ietf.org >> Subject: [scim] Searching with POST instead of GET >> >> Has any consideration been given to allowing searching in SCIM with a POST operation? The reason is, that the URL based approach in GET means high-risk filters can be caught up in logs and is generally something to be avoided. We have a security concern about passing parameters in many cases using GET. >> >> In thinking about how to do this, could we allow/reserve POST for queries and BULK, and expand PUT to support add/replace. Such as with /Users for an add, and /Users/identifier for a replace. Right now POST is used for replace and for Bulk. >> >> If this was discussed in the consortium, maybe someone could summarize the current position on the IETF list here? >> >> Another alternative is to allow GET parameters to be passed in the header. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> >> >> _______________________________________________ >> 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 --------------090408050602050604030207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Why not pass the search query parameters in the POST data block?

Igor



On 6/27/2012 7:30 PM, Phil Hunt wrote: 
The requirement is to do a search without using GET.  IOW a non-url based search where the URL only shows /Users or /Users/id.

I know what the spec currently says. What I'm trying to do is open the possibility for POST to do a search.  Hopefully that clarifies.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-06-27, at 4:27 PM, Anthony Nadalin wrote:


PUT could be a replace object, or create a named object, when applicable
POST  could be create a new object based on data provided, or submit a command


-----Original Message-----
From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, June 27, 2012 12:35 PM
To: scim@ietf.org
Subject: [scim] Searching with POST instead of GET

Has any consideration been given to allowing searching in SCIM with a POST operation? The reason is, that the URL based approach in GET means high-risk filters can be caught up in logs and is generally something to be avoided. We have a security concern about passing parameters in many cases using GET.  

In thinking about how to do this, could we allow/reserve POST for queries and BULK, and expand PUT to support add/replace. Such as with /Users for an add, and /Users/identifier for a replace.  Right now POST is used for replace and for Bulk.

If this was discussed in the consortium, maybe someone could summarize the current position on the IETF list here?

Another alternative is to allow GET parameters to be passed in the header.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





_______________________________________________
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
--------------090408050602050604030207-- From tonynad@microsoft.com Wed Jun 27 17:19:14 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 03C8C21F84DA for ; Wed, 27 Jun 2012 17:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.634 X-Spam-Level: X-Spam-Status: No, score=-0.634 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 d9sjXAyWbqDe for ; Wed, 27 Jun 2012 17:19:13 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id CCC6B11E810A for ; Wed, 27 Jun 2012 16:49:20 -0700 (PDT) Received: from mail79-db3-R.bigfish.com (10.3.81.247) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Jun 2012 23:47:35 +0000 Received: from mail79-db3 (localhost [127.0.0.1]) by mail79-db3-R.bigfish.com (Postfix) with ESMTP id 1461B1802B7 for ; Wed, 27 Jun 2012 23:47:35 +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: -26 X-BigFish: VS-26(zz98dI9371I936eI542M1432Izz1202h1082kzz1033IL8275bh8275dhz2fh2a8h683h839h944hd25hf0ah) Received-SPF: pass (mail79-db3: 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:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail79-db3 (localhost.localdomain [127.0.0.1]) by mail79-db3 (MessageSwitch) id 1340840853782356_12113; Wed, 27 Jun 2012 23:47:33 +0000 (UTC) Received: from DB3EHSMHS016.bigfish.com (unknown [10.3.81.234]) by mail79-db3.bigfish.com (Postfix) with ESMTP id BD02F4C004A for ; Wed, 27 Jun 2012 23:47:33 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS016.bigfish.com (10.3.87.116) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 27 Jun 2012 23:47:33 +0000 Received: from am1outboundpool.messaging.microsoft.com (157.54.51.81) by mail.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.2.298.5; Wed, 27 Jun 2012 23:49:13 +0000 Received: from mail65-am1-R.bigfish.com (10.3.201.225) by AM1EHSOBE009.bigfish.com (10.3.204.29) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Jun 2012 23:38:28 +0000 Received: from mail65-am1 (localhost [127.0.0.1]) by mail65-am1-R.bigfish.com (Postfix) with ESMTP id 5FA852400DC for ; Wed, 27 Jun 2012 23:38:28 +0000 (UTC) Received: from mail65-am1 (localhost.localdomain [127.0.0.1]) by mail65-am1 (MessageSwitch) id 1340840305511254_1931; Wed, 27 Jun 2012 23:38:25 +0000 (UTC) Received: from AM1EHSMHS013.bigfish.com (unknown [10.3.201.247]) by mail65-am1.bigfish.com (Postfix) with ESMTP id 71057340048; Wed, 27 Jun 2012 23:38:25 +0000 (UTC) Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by AM1EHSMHS013.bigfish.com (10.3.207.151) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 27 Jun 2012 23:38:25 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.10.205]) by BL2PRD0310HT001.namprd03.prod.outlook.com ([10.255.97.36]) with mapi id 14.16.0164.004; Wed, 27 Jun 2012 23:40:08 +0000 From: Anthony Nadalin To: Phil Hunt Thread-Topic: [scim] Searching with POST instead of GET Thread-Index: AQHNVJv8g0QR19A2hU6fZWmcUh7Iu5cOzmzggAACFoCAAAJTIA== Date: Wed, 27 Jun 2012 23:40:08 +0000 Message-ID: References: <67261554-7E01-4FBD-B7E5-4EF6F3487BAE@oracle.com> <9B9F7C7A-A3FB-4E6E-B686-45E7AA452607@oracle.com> In-Reply-To: <9B9F7C7A-A3FB-4E6E-B686-45E7AA452607@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.57] 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-CrossPremisesHeadersPromoted: TK5EX14MLTC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC101.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: "scim@ietf.org" 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, 28 Jun 2012 00:19:14 -0000 I would hope that the POST is not limited to SEARCH but is just a COMMAND o= f which SEARCH is one of the COMMANDS -----Original Message----- From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 Sent: Wednesday, June 27, 2012 4:31 PM To: Anthony Nadalin Cc: scim@ietf.org Subject: Re: [scim] Searching with POST instead of GET The requirement is to do a search without using GET. IOW a non-url based s= earch where the URL only shows /Users or /Users/id. I know what the spec currently says. What I'm trying to do is open the poss= ibility for POST to do a search. Hopefully that clarifies. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-06-27, at 4:27 PM, Anthony Nadalin wrote: > PUT could be a replace object, or create a named object, when=20 > applicable POST could be create a new object based on data provided,=20 > or submit a command >=20 >=20 > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf=20 > Of Phil Hunt > Sent: Wednesday, June 27, 2012 12:35 PM > To: scim@ietf.org > Subject: [scim] Searching with POST instead of GET >=20 > Has any consideration been given to allowing searching in SCIM with a POS= T operation? The reason is, that the URL based approach in GET means high-r= isk filters can be caught up in logs and is generally something to be avoid= ed. We have a security concern about passing parameters in many cases using= GET. =20 >=20 > In thinking about how to do this, could we allow/reserve POST for queries= and BULK, and expand PUT to support add/replace. Such as with /Users for a= n add, and /Users/identifier for a replace. Right now POST is used for rep= lace and for Bulk. >=20 > If this was discussed in the consortium, maybe someone could summarize th= e current position on the IETF list here? >=20 > Another alternative is to allow GET parameters to be passed in the header= . >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From phil.hunt@oracle.com Wed Jun 27 19:25:32 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 E8AB721F8616 for ; Wed, 27 Jun 2012 19:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.471 X-Spam-Level: X-Spam-Status: No, score=-10.471 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] 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 RUI6gSrpA9-k for ; Wed, 27 Jun 2012 19:25:30 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id A611C21F8615 for ; Wed, 27 Jun 2012 19:25:30 -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 q5S2PTqh015458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Jun 2012 02:25:30 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 q5S2PSxu019373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2012 02:25:29 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q5S2PSqf027662; Wed, 27 Jun 2012 21:25:28 -0500 Received: from dhcp-amer-vpn-rmdc-anyconnect-10-159-178-218.vpn.oracle.com (/10.159.178.218) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 27 Jun 2012 19:25:28 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: Date: Wed, 27 Jun 2012 19:25:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2956CC8D-B9B9-4443-9AA7-4BF7B2A1D82A@oracle.com> References: <67261554-7E01-4FBD-B7E5-4EF6F3487BAE@oracle.com> <9B9F7C7A-A3FB-4E6E-B686-45E7AA452607@oracle.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.1278) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "scim@ietf.org" 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, 28 Jun 2012 02:25:32 -0000 agreed. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-06-27, at 4:40 PM, Anthony Nadalin wrote: > I would hope that the POST is not limited to SEARCH but is just a = COMMAND of which SEARCH is one of the COMMANDS >=20 > -----Original Message----- > From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Wednesday, June 27, 2012 4:31 PM > To: Anthony Nadalin > Cc: scim@ietf.org > Subject: Re: [scim] Searching with POST instead of GET >=20 > The requirement is to do a search without using GET. IOW a non-url = based search where the URL only shows /Users or /Users/id. >=20 > I know what the spec currently says. What I'm trying to do is open the = possibility for POST to do a search. Hopefully that clarifies. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2012-06-27, at 4:27 PM, Anthony Nadalin wrote: >=20 >> PUT could be a replace object, or create a named object, when=20 >> applicable POST could be create a new object based on data provided,=20= >> or submit a command >>=20 >>=20 >> -----Original Message----- >> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf=20= >> Of Phil Hunt >> Sent: Wednesday, June 27, 2012 12:35 PM >> To: scim@ietf.org >> Subject: [scim] Searching with POST instead of GET >>=20 >> Has any consideration been given to allowing searching in SCIM with a = POST operation? The reason is, that the URL based approach in GET means = high-risk filters can be caught up in logs and is generally something to = be avoided. We have a security concern about passing parameters in many = cases using GET. =20 >>=20 >> In thinking about how to do this, could we allow/reserve POST for = queries and BULK, and expand PUT to support add/replace. Such as with = /Users for an add, and /Users/identifier for a replace. Right now POST = is used for replace and for Bulk. >>=20 >> If this was discussed in the consortium, maybe someone could = summarize the current position on the IETF list here? >>=20 >> Another alternative is to allow GET parameters to be passed in the = header. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From phil.hunt@oracle.com Wed Jun 27 19:25:55 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 A100321F862F for ; Wed, 27 Jun 2012 19:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.481 X-Spam-Level: X-Spam-Status: No, score=-10.481 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] 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 N0RozEM9A3lp for ; Wed, 27 Jun 2012 19:25:54 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id C7CFA21F8621 for ; Wed, 27 Jun 2012 19:25:54 -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 q5S2PqmW015589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Jun 2012 02:25:53 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q5S2PpTw002252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2012 02:25:52 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q5S2PpF0027843; Wed, 27 Jun 2012 21:25:51 -0500 Received: from dhcp-amer-vpn-rmdc-anyconnect-10-159-178-218.vpn.oracle.com (/10.159.178.218) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 27 Jun 2012 19:25:51 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_EA5BA02C-A1D4-4084-9162-E425631BDBB6" From: Phil Hunt In-Reply-To: <4FEBA2BE.2050006@alcatel-lucent.com> Date: Wed, 27 Jun 2012 19:25:56 -0700 Message-Id: References: <67261554-7E01-4FBD-B7E5-4EF6F3487BAE@oracle.com> <9B9F7C7A-A3FB-4E6E-B686-45E7AA452607@oracle.com> <4FEBA2BE.2050006@alcatel-lucent.com> To: igor.faynberg@alcatel-lucent.com X-Mailer: Apple Mail (2.1278) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: scim@ietf.org 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, 28 Jun 2012 02:25:55 -0000 --Apple-Mail=_EA5BA02C-A1D4-4084-9162-E425631BDBB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Yes. That's what I would like to do. The concern is that POST is = already used for replace and bulk. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-06-27, at 5:18 PM, Igor Faynberg wrote: > Why not pass the search query parameters in the POST data block? >=20 > Igor >=20 >=20 >=20 > On 6/27/2012 7:30 PM, Phil Hunt wrote: >>=20 >> The requirement is to do a search without using GET. IOW a non-url = based search where the URL only shows /Users or /Users/id. >>=20 >> I know what the spec currently says. What I'm trying to do is open = the possibility for POST to do a search. Hopefully that clarifies. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2012-06-27, at 4:27 PM, Anthony Nadalin wrote: >>=20 >>> PUT could be a replace object, or create a named object, when = applicable >>> POST could be create a new object based on data provided, or submit = a command >>>=20 >>>=20 >>> -----Original Message----- >>> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Phil Hunt >>> Sent: Wednesday, June 27, 2012 12:35 PM >>> To: scim@ietf.org >>> Subject: [scim] Searching with POST instead of GET >>>=20 >>> Has any consideration been given to allowing searching in SCIM with = a POST operation? The reason is, that the URL based approach in GET = means high-risk filters can be caught up in logs and is generally = something to be avoided. We have a security concern about passing = parameters in many cases using GET. =20 >>>=20 >>> In thinking about how to do this, could we allow/reserve POST for = queries and BULK, and expand PUT to support add/replace. Such as with = /Users for an add, and /Users/identifier for a replace. Right now POST = is used for replace and for Bulk. >>>=20 >>> If this was discussed in the consortium, maybe someone could = summarize the current position on the IETF list here? >>>=20 >>> Another alternative is to allow GET parameters to be passed in the = header. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>>=20 >>>=20 >>>=20 >>>=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 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_EA5BA02C-A1D4-4084-9162-E425631BDBB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Yes. =  That's what I would like to do. The concern is that POST is = already used for replace and bulk.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-06-27, at 5:18 PM, Igor Faynberg wrote:

=20 =20
Why not pass the search query parameters in the POST data block?

Igor



On 6/27/2012 7:30 PM, Phil Hunt wrote: 
The requirement is to do a search without using =
GET.  IOW a non-url based search where the URL only shows /Users or =
/Users/id.

I know what the spec currently says. What I'm trying to do is open the =
possibility for POST to do a search.  Hopefully that clarifies.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-06-27, at 4:27 PM, Anthony Nadalin wrote:


PUT could be a replace object, or create a named =
object, when applicable
POST  could be create a new object based on data provided, or submit a =
command


-----Original Message-----
From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] =
On Behalf Of Phil Hunt
Sent: Wednesday, June 27, 2012 12:35 PM
To: scim@ietf.org
Subject: [scim] Searching with POST instead of GET

Has any consideration been given to allowing searching in SCIM with a =
POST operation? The reason is, that the URL based approach in GET means =
high-risk filters can be caught up in logs and is generally something to =
be avoided. We have a security concern about passing parameters in many =
cases using GET. =20

In thinking about how to do this, could we allow/reserve POST for =
queries and BULK, and expand PUT to support add/replace. Such as with =
/Users for an add, and /Users/identifier for a replace.  Right now POST =
is used for replace and for Bulk.

If this was discussed in the consortium, maybe someone could summarize =
the current position on the IETF list here?

Another alternative is to allow GET parameters to be passed in the =
header.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/m=
ailman/listinfo/scim





_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/m=
ailman/listinfo/scim

_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/m=
ailman/listinfo/scim
_______________________________________________
scim mailing = list
scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim

= --Apple-Mail=_EA5BA02C-A1D4-4084-9162-E425631BDBB6-- From michael.brenner@alcatel-lucent.com Thu Jun 28 05:18:10 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 AAB0921F8565 for ; Thu, 28 Jun 2012 05:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 yiQgIXrG9G8l for ; Thu, 28 Jun 2012 05:18:08 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3D621F8564 for ; Thu, 28 Jun 2012 05:18:04 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q5SCI079024404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Jun 2012 07:18:01 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q5SCI0fF027651 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 28 Jun 2012 07:18:00 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Thu, 28 Jun 2012 07:18:00 -0500 From: "Brenner, Michael Ralf (Michael)" To: Phil Hunt , "Faynberg, Igor (Igor)" Date: Thu, 28 Jun 2012 07:17:59 -0500 Thread-Topic: [scim] Searching with POST instead of GET Thread-Index: Ac1U4pV8eBbbacGLT6i2AQcrdR/Z7gARDudw Message-ID: <219947F0B2242843A0A1E62FDB510DC026CED44475@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <67261554-7E01-4FBD-B7E5-4EF6F3487BAE@oracle.com> <9B9F7C7A-A3FB-4E6E-B686-45E7AA452607@oracle.com> <4FEBA2BE.2050006@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_219947F0B2242843A0A1E62FDB510DC026CED44475USNAVSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "scim@ietf.org" 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, 28 Jun 2012 12:18:10 -0000 --_000_219947F0B2242843A0A1E62FDB510DC026CED44475USNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That should not be an impediment, and it is RSTful. You can use the POST re= quest body as a container for passing a command (e.g. SEARCH, REPLACE, BULK= ) and it's respective attributes. It's being done in many other standard RE= STful API (e.g. OMA Payment - where you can create different transactions u= sing POST (e.g. reserve amount, charge against reservation, reserve additio= nal amount, release reservation, etc). An example that emulates a GET is the POST request used in long-polling (se= e Bayeux protocol or OMA Notification Channel API standard, partially model= ed after Bayeux). Michael From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phi= l Hunt Sent: Wednesday, June 27, 2012 10:26 PM To: Faynberg, Igor (Igor) Cc: scim@ietf.org Subject: Re: [scim] Searching with POST instead of GET Yes. That's what I would like to do. The concern is that POST is already u= sed for replace and bulk. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-06-27, at 5:18 PM, Igor Faynberg wrote: Why not pass the search query parameters in the POST data block? Igor On 6/27/2012 7:30 PM, Phil Hunt wrote: The requirement is to do a search without using GET. IOW a non-url based s= earch where the URL only shows /Users or /Users/id. I know what the spec currently says. What I'm trying to do is open the poss= ibility for POST to do a search. Hopefully that clarifies. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-06-27, at 4:27 PM, Anthony Nadalin wrote: PUT could be a replace object, or create a named object, when applicable POST could be create a new object based on data provided, or submit a comm= and -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Phil Hunt Sent: Wednesday, June 27, 2012 12:35 PM To: scim@ietf.org Subject: [scim] Searching with POST instead of GET Has any consideration been given to allowing searching in SCIM with a POST = operation? The reason is, that the URL based approach in GET means high-ris= k filters can be caught up in logs and is generally something to be avoided= . We have a security concern about passing parameters in many cases using G= ET. In thinking about how to do this, could we allow/reserve POST for queries a= nd BULK, and expand PUT to support add/replace. Such as with /Users for an = add, and /Users/identifier for a replace. Right now POST is used for repla= ce and for Bulk. If this was discussed in the consortium, maybe someone could summarize the = current position on the IETF list here? Another alternative is to allow GET parameters to be passed in the header. Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ 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 _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_219947F0B2242843A0A1E62FDB510DC026CED44475USNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That should not be an impediment, and it is RSTful. You can use = the POST request body as a container for passing a command (e.g. SEARCH, RE= PLACE, BULK) and it’s respective attributes. It’s being done in= many other standard RESTful API (e.g. OMA Payment – where you can cr= eate different transactions using POST (e.g. reserve amount, charge against= reservation, reserve additional amount, release reservation, etc).

An example that emulates a GET is= the POST request used in long-polling (see Bayeux protocol or OMA Notifica= tion Channel API standard, partially modeled after Bayeux).

 

Michael

 

From: scim-bounc= es@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phil HuntSent: Wednesday, June 27, 2012 10:26 PM
To: Faynberg, Igo= r (Igor)
Cc: scim@ietf.org
Subject: Re: [scim] Searchin= g with POST instead of GET

 

Yes.  That's what I wo= uld like to do. The concern is that POST is already used for replace and bu= lk.

 

=

Phil<= /p>

 

=

@independentid

<= div>

www= .independentid.com

phil.hunt@oracle.com

 



&nbs= p;

On 2012-06-27, at 5:18 PM, Igor = Faynberg wrote:



Why not pass = the search query parameters in the POST data block?

Igor<= /p>

=  


On 6/27/2012 7:30 PM, = Phil Hunt wrote: 

The requirement is to do a search with=
out using GET.  IOW a non-url based search where the URL only shows /U=
sers or /Users/id.
 
I know =
what the spec currently says. What I'm trying to do is open the possibility=
 for POST to do a search.  Hopefully that clarifies.
<= pre> 
Phil
 =

@independentid
www.independentid.com
phil.hunt@oracle.com
 
 
 
 
 
On 2012-06-27=
, at 4:27 PM, Anthony Nadalin wrote:
 =

PUT c=
ould be a replace object, or create a named object, when applicable
POST  could be create a new object based on data provide=
d, or submit a command
 
 
-----Original Message-----
Fr=
om: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On =
Behalf Of Phil Hunt
Sent: Wednesday, June 27, 2012 12:=
35 PM
To: scim@ietf.o=
rg
Subject: [scim] Searching with POST instead of =
GET
 
Has any consideration =
been given to allowing searching in SCIM with a POST operation? The reason =
is, that the URL based approach in GET means high-risk filters can be caugh=
t up in logs and is generally something to be avoided. We have a security c=
oncern about passing parameters in many cases using GET.  <=
/pre>
 
In thinking about how to do this, cou=
ld we allow/reserve POST for queries and BULK, and expand PUT to support ad=
d/replace. Such as with /Users for an add, and /Users/identifier for a repl=
ace.  Right now POST is used for replace and for Bulk.
 
If this was discussed in the consortium, =
maybe someone could summarize the current position on the IETF list here?
 
Another alternative is to a=
llow GET parameters to be passed in the header.
&=
nbsp;
Phil
 
@independentid
www.independentid.com
phil.hunt@oracle.com
 
 
 
 
 
_______________________=
________________________
scim mailing list<=
/pre>
scim@ietf.org
https://www.i=
etf.org/mailman/listinfo/scim
 
 
 
 =

 
______________________________=
_________________
scim mailing list
scim@ietf.org
=
https://www.ietf.org=
/mailman/listinfo/scim
______________=
_________________________________
scim mailing list
scim@ietf.org<=
/o:p>
http=
s://www.ietf.org/mailman/listinfo/scim

_______________________________________________
scim mailin= g list
scim@ietf.org
https://www= .ietf.org/mailman/listinfo/scim

 

= --_000_219947F0B2242843A0A1E62FDB510DC026CED44475USNAVSXCHMBSA_-- From kelly.grizzle@sailpoint.com Fri Jun 29 08:35:17 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 799A221F877E for ; Fri, 29 Jun 2012 08:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 S0P5e4zJ00uc for ; Fri, 29 Jun 2012 08:35:09 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id CB65C21F8776 for ; Fri, 29 Jun 2012 08:35:08 -0700 (PDT) Received: from mail104-am1-R.bigfish.com (10.3.201.241) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Fri, 29 Jun 2012 15:33:18 +0000 Received: from mail104-am1 (localhost [127.0.0.1]) by mail104-am1-R.bigfish.com (Postfix) with ESMTP id 4C6914A02E9; Fri, 29 Jun 2012 15:33:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.241.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0411HT001.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: PS-29(zzbb2dI98dI9371I936eIc85fh542Mzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail104-am1: domain of sailpoint.com designates 157.56.241.133 as permitted sender) client-ip=157.56.241.133; envelope-from=kelly.grizzle@sailpoint.com; helo=BL2PRD0411HT001.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail104-am1 (localhost.localdomain [127.0.0.1]) by mail104-am1 (MessageSwitch) id 1340983995569634_26897; Fri, 29 Jun 2012 15:33:15 +0000 (UTC) Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.251]) by mail104-am1.bigfish.com (Postfix) with ESMTP id 87C3E14004C; Fri, 29 Jun 2012 15:33:15 +0000 (UTC) Received: from BL2PRD0411HT001.namprd04.prod.outlook.com (157.56.241.133) by AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 29 Jun 2012 15:33:14 +0000 Received: from BL2PRD0411MB397.namprd04.prod.outlook.com ([169.254.10.116]) by BL2PRD0411HT001.namprd04.prod.outlook.com ([10.255.130.36]) with mapi id 14.16.0164.004; Fri, 29 Jun 2012 15:35:01 +0000 From: Kelly Grizzle To: "Brenner, Michael Ralf (Michael)" , Phil Hunt , "Faynberg, Igor (Igor)" Thread-Topic: [scim] Searching with POST instead of GET Thread-Index: AQHNVJvyiLbL6e9nYkuaangiWLLcFpcOz4AAgAABA4CAAA0/AIAAI7cAgACla4CAAcdI0A== Date: Fri, 29 Jun 2012 15:35:00 +0000 Message-ID: <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> In-Reply-To: <219947F0B2242843A0A1E62FDB510DC026CED44475@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.226.147.242] Content-Type: multipart/alternative; boundary="_000_56C3C758F9D6534CA3778EAA1E0C343722AB03F8BL2PRD0411MB397_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" 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: Fri, 29 Jun 2012 15:35:18 -0000 --_000_56C3C758F9D6534CA3778EAA1E0C343722AB03F8BL2PRD0411MB397_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't know how often there will be a security concern over GET parameters= , 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 B= ulk requests (it is currently the only excluded method). Clients that are = not worried can use a normal GET request and others could use a POST to /Bu= lk with a GET request in the payload. --Kelly From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Bre= nner, Michael Ralf (Michael) Sent: Thursday, June 28, 2012 7:18 AM To: Phil Hunt; Faynberg, Igor (Igor) Cc: scim@ietf.org Subject: Re: [scim] Searching with POST instead of GET That should not be an impediment, and it is RSTful. You can use the POST re= quest body as a container for passing a command (e.g. SEARCH, REPLACE, BULK= ) and it's respective attributes. It's being done in many other standard RE= STful API (e.g. OMA Payment - where you can create different transactions u= sing POST (e.g. reserve amount, charge against reservation, reserve additio= nal amount, release reservation, etc). An example that emulates a GET is the POST request used in long-polling (se= e Bayeux protocol or OMA Notification Channel API standard, partially model= ed after Bayeux). Michael From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Phil Hunt Sent: Wednesday, June 27, 2012 10:26 PM To: Faynberg, Igor (Igor) Cc: scim@ietf.org Subject: Re: [scim] Searching with POST instead of GET Yes. That's what I would like to do. The concern is that POST is already u= sed for replace and bulk. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-06-27, at 5:18 PM, Igor Faynberg wrote: Why not pass the search query parameters in the POST data block? Igor On 6/27/2012 7:30 PM, Phil Hunt wrote: The requirement is to do a search without using GET. IOW a non-url based s= earch where the URL only shows /Users or /Users/id. I know what the spec currently says. What I'm trying to do is open the poss= ibility for POST to do a search. Hopefully that clarifies. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-06-27, at 4:27 PM, Anthony Nadalin wrote: PUT could be a replace object, or create a named object, when applicable POST could be create a new object based on data provided, or submit a comm= and -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Phil Hunt Sent: Wednesday, June 27, 2012 12:35 PM To: scim@ietf.org Subject: [scim] Searching with POST instead of GET Has any consideration been given to allowing searching in SCIM with a POST = operation? The reason is, that the URL based approach in GET means high-ris= k filters can be caught up in logs and is generally something to be avoided= . We have a security concern about passing parameters in many cases using G= ET. In thinking about how to do this, could we allow/reserve POST for queries a= nd BULK, and expand PUT to support add/replace. Such as with /Users for an = add, and /Users/identifier for a replace. Right now POST is used for repla= ce and for Bulk. If this was discussed in the consortium, maybe someone could summarize the = current position on the IETF list here? Another alternative is to allow GET parameters to be passed in the header. Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ 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 _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_56C3C758F9D6534CA3778EAA1E0C343722AB03F8BL2PRD0411MB397_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don’t know how of= ten there will be a security concern over GET parameters, although I can se= e some of the more security conscious worrying about this.  My vote would be to simply add official support for the GET method in Bulk re= quests (it is currently the only excluded method).  Clients that are n= ot worried can use a normal GET request and others could use a POST to /Bul= k with a GET request in the payload.

 <= /p>

--Kelly=

 <= /p>

From: scim-bou= nces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Brenner, Michael Ralf (Michael)
Sent: Thursday, June 28, 2012 7:18 AM
To: Phil Hunt; Faynberg, Igor (Igor)
Cc: scim@ietf.org
Subject: Re: [scim] Searching with POST instead of GET

 

That should not be an imp= ediment, and it is RSTful. You can use the POST request body as a container= for passing a command (e.g. SEARCH, REPLACE, BULK) and it’s respective attributes. It’s being done in many other stan= dard RESTful API (e.g. OMA Payment – where you can create different t= ransactions using POST (e.g. reserve amount, charge against reservation, re= serve additional amount, release reservation, etc).

An example that emulates = a GET is the POST request used in long-polling (see Bayeux protocol or OMA = Notification Channel API standard, partially modeled after Bayeux).

 <= /p>

Michael=

 <= /p>

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, June 27, 2012 10:26 PM
To: Faynberg, Igor (Igor)
Cc: scim@ietf.org
Subject: Re: [scim] Searching with POST instead of GET

 

Yes.  That's what I would like to do. The conce= rn is that POST is already used for replace and bulk.

 

Phil

 

@independentid<= /span>

phil.hunt@oracle.com=

 <= /p>

 

 

On 2012-06-27, at 5:18 PM, Igor Faynberg wrote:=

 

Why not pass the sear= ch query parameters in the POST data block?

Igor

 


On 6/27/2012 7:30 PM, Phil Hunt wrote: 

The requirement is to do a search without using GET.  IOW a non-u=
rl based search where the URL only shows /Users or /Users/id.

 


I know what the spec currently says. What I'm trying to do is open the=
 possibility for POST to do a search.  Hopefully that clarifies.<=
/o:p>


 


Phil


 


@independentid


www.independentid.com


phil.hunt@oracle.com<=
/o:p>


 


 


 


 


 


On 2012-06-27, at 4:27 PM, Anthony Nadalin wrote:


 




PUT could be a replace object, or create a named object, when applicab=
le


POST  could be create a new object based on data provided, or sub=
mit a command


 


 


-----Original Message-----


From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt


Sent: Wednesday, June 27, 2012 12:35 PM


To: scim@ietf.org

Subject: [scim] Searching with POST instead of GET


 


Has any consideration been given to allowing searching in SCIM with a =
POST operation? The reason is, that the URL based approach in GET means hig=
h-risk filters can be caught up in logs and is generally something to be av=
oided. We have a security concern about passing parameters in many cases us=
ing GET.  


 


In thinking about how to do this, could we allow/reserve POST for quer=
ies and BULK, and expand PUT to support add/replace. Such as with /Users fo=
r an add, and /Users/identifier for a replace.  Right now POST is used=
 for replace and for Bulk.


 


If this was discussed in the consortium, maybe someone could summarize=
 the current position on the IETF list here?


 


Another alternative is to allow GET parameters to be passed in the hea=
der.


 


Phil


 


@independentid


www.independentid.com


phil.hunt@oracle.com<=
/o:p>


 


 


 


 


 


_______________________________________________


scim mailing list


scim@ietf.org


https://www.iet=
f.org/mailman/listinfo/scim


 


 


 


 


 


_______________________________________________


scim mailing list


scim@ietf.org


https://www.iet=
f.org/mailman/listinfo/scim




_______________________________________________


scim mailing list


scim@ietf.org


https://www.iet=
f.org/mailman/listinfo/scim

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

 

--_000_56C3C758F9D6534CA3778EAA1E0C343722AB03F8BL2PRD0411MB397_--