From nobody Tue Jul 1 06:55:13 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682511A04F8 for ; Tue, 1 Jul 2014 06:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXzpNibGWgk9 for ; Tue, 1 Jul 2014 06:55:02 -0700 (PDT) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A31901A055D for ; Tue, 1 Jul 2014 06:53:27 -0700 (PDT) Received: from NG-EX04.ad.nexusgroup.com (10.75.28.9) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 1 Jul 2014 15:53:18 +0200 Received: from NG-EX02.ad.nexusgroup.com (10.75.28.43) by NG-EX04.ad.nexusgroup.com (10.75.28.9) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 1 Jul 2014 15:53:18 +0200 Received: from NG-EX02.ad.nexusgroup.com ([fe80::2839:3494:59f1:44d]) by NG-EX02.ad.nexusgroup.com ([fe80::2839:3494:59f1:44d%12]) with mapi id 15.00.0847.030; Tue, 1 Jul 2014 15:53:18 +0200 From: =?Windows-1252?Q?Erik_Wahlstr=F6m?= To: Phil Hunt Thread-Topic: [scim] Proposed Detail Errors Thread-Index: AQHPkla1XO3s6kYrbk+gyaWTwU2cbJuIZfSAgAAE3ICAATM9AIAAE3GAgAAmcoCAABOcAIAAAwOAgAAkAACAABOzAIAABXMAgABNSgCAAKhpAA== Date: Tue, 1 Jul 2014 13:53:17 +0000 Message-ID: <1272F486-DC54-4456-B4E4-061D134DD9BD@nexusgroup.com> References: <348F75D5-7C0F-4B93-A7B7-88E0B2FFD4ED@oracle.com> <232fc398cb76462088c589f6244f3bf9@BN1PR04MB392.namprd04.prod.outlook.com> <42A78180-7AA1-40FD-B257-DD6ECF06784E@oracle.com> <9075316269e949418386ee90ebedee42@BN1PR04MB392.namprd04.prod.outlook.com> <3B339C76-F410-41EF-A574-EA3FA85D8590@oracle.com> <29451b18f13248d1834c27b71b006df5@BLUPR03MB309.namprd03.prod.outlook.com> <53B1EA9E.4070101@mnt.se> 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.76.132.21] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/DL1U2x_kA9Tt2sgMQkNQh_mrfdI Cc: Leif Johansson , "scim@ietf.org" , Kelly Grizzle Subject: Re: [scim] Proposed Detail Errors X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 13:55:06 -0000 Limiting the error codes works for me. As scimType is optional should a gen= eral =93400 bad request=94 just not add the scimType or should we also spec= ify a =93general=94 scimType to make it clear? Otherwise we should write it= in bit more detail in the text "For HTTP Status 400 (Bad Request) response= s, the following detail error types are defined and is optional to return f= or the Service Provider:=94 / Erik On 01 Jul 2014, at 05:50, Phil Hunt wrote: > My worry is that if service providers implement non-standard codes and th= an do not register them, then they can expect that clients shall ignore the= ir proprietary custom codes. >=20 > Still, service providers should also expect that not every client will im= plement registered codes either. >=20 > Clients will need to keep in mind that many service providers will likely= only return a general 400 bad request for *any* error as they may be cauti= ous about proving attacks. >=20 > I recommend we limit error codes to protocol and schema issues only in or= der to get to a final draft in Toronto. >=20 > I understand the value of detailed error codes to coding smart UIs. But I= would prefer to deal with these fine-grained errors in a future charter. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 > On Jun 30, 2014, at 4:13 PM, Kelly Grizzle = wrote: >=20 >> I don't know that service providers should have to register codes that a= re specific to their implementation ... that kind of seems like overkill to= me. What benefit does that provide other than possibly preventing collisi= ons? >>=20 >> As long as the SP can provide information to the client about what error= occurred, it feels like that is enough. The error code sent in the respon= se could either be one of the SCIM-defined errors (mutability, etc...) or a= provider-defined error (eg - an error code number, etc...). >>=20 >>=20 >> -----Original Message----- >> From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Leif Johansson >> Sent: Monday, June 30, 2014 5:54 PM >> To: scim@ietf.org >> Subject: Re: [scim] Proposed Detail Errors >>=20 >> On 2014-06-30 23:43, Anthony Nadalin wrote: >>> Concern is that this can cause continuous code changes in different=20 >>> codes being registered, ideally there would only be a couple and they=20 >>> would be from the start but this could grow and cause interoperability= =20 >>> issues with folks registering error codes >>=20 >> Thats going to be true for any extension though, right? Errors are no wo= rse in this respect. >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Tue Jul 1 09:27:46 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E291B2830 for ; Tue, 1 Jul 2014 09:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76ESejVpqtM2 for ; Tue, 1 Jul 2014 09:27:30 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0182.outbound.protection.outlook.com [207.46.163.182]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 879951B2841 for ; Tue, 1 Jul 2014 09:27:29 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) with Microsoft SMTP Server (TLS) id 15.0.974.11; Tue, 1 Jul 2014 16:27:27 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0974.002; Tue, 1 Jul 2014 16:27:27 +0000 From: Anthony Nadalin To: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= , "Phil Hunt" Thread-Topic: [scim] Proposed Detail Errors Thread-Index: AQHPkjhIzbP18zhaFUGCaYkX6dnJmZuIh7iAgAAE3ICAATM9AIAAE3GAgAAmcoCAABN/MIAAAyCAgAAjebCAABQ6AIAABXMAgABNSgCAAKhqgIAAKw4w Date: Tue, 1 Jul 2014 16:27:27 +0000 Message-ID: References: <348F75D5-7C0F-4B93-A7B7-88E0B2FFD4ED@oracle.com> <232fc398cb76462088c589f6244f3bf9@BN1PR04MB392.namprd04.prod.outlook.com> <42A78180-7AA1-40FD-B257-DD6ECF06784E@oracle.com> <9075316269e949418386ee90ebedee42@BN1PR04MB392.namprd04.prod.outlook.com> <3B339C76-F410-41EF-A574-EA3FA85D8590@oracle.com> <29451b18f13248d1834c27b71b006df5@BLUPR03MB309.namprd03.prod.outlook.com> <53B1EA9E.4070101@mnt.se> <1272F486-DC54-4456-B4E4-061D134DD9BD@nexusgroup.com> In-Reply-To: <1272F486-DC54-4456-B4E4-061D134DD9BD@nexusgroup.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02596AB7DA x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(24454002)(189002)(199002)(13464003)(377424004)(377454003)(51704005)(19580405001)(83322001)(76176999)(15975445006)(54356999)(64706001)(77982001)(85306003)(19580395003)(50986999)(99396002)(20776003)(76482001)(80022001)(79102001)(81342001)(81542001)(46102001)(74502001)(107046002)(33646001)(21056001)(74662001)(86362001)(4396001)(95666004)(101416001)(105586002)(83072002)(76576001)(85852003)(87936001)(15974865002)(106116001)(106356001)(74316001)(99286002)(2656002)(108616002)(42262001)(3826002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB309; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/XopGCSeRRRlPJQEoqvzqvb1GXCQ Cc: Leif Johansson , Kelly Grizzle , "scim@ietf.org" Subject: Re: [scim] Proposed Detail Errors X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 16:27:32 -0000 +1 -----Original Message----- From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Erik Wahlstr=F6m Sent: Tuesday, July 1, 2014 6:53 AM To: Phil Hunt Cc: Leif Johansson; scim@ietf.org; Kelly Grizzle Subject: Re: [scim] Proposed Detail Errors Limiting the error codes works for me. As scimType is optional should a gen= eral "400 bad request" just not add the scimType or should we also specify = a "general" scimType to make it clear? Otherwise we should write it in bit = more detail in the text "For HTTP Status 400 (Bad Request) responses, the f= ollowing detail error types are defined and is optional to return for the S= ervice Provider:" / Erik On 01 Jul 2014, at 05:50, Phil Hunt wrote: > My worry is that if service providers implement non-standard codes and th= an do not register them, then they can expect that clients shall ignore the= ir proprietary custom codes. >=20 > Still, service providers should also expect that not every client will im= plement registered codes either. >=20 > Clients will need to keep in mind that many service providers will likely= only return a general 400 bad request for *any* error as they may be cauti= ous about proving attacks. >=20 > I recommend we limit error codes to protocol and schema issues only in or= der to get to a final draft in Toronto. >=20 > I understand the value of detailed error codes to coding smart UIs. But I= would prefer to deal with these fine-grained errors in a future charter. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 > On Jun 30, 2014, at 4:13 PM, Kelly Grizzle = wrote: >=20 >> I don't know that service providers should have to register codes that a= re specific to their implementation ... that kind of seems like overkill to= me. What benefit does that provide other than possibly preventing collisi= ons? >>=20 >> As long as the SP can provide information to the client about what error= occurred, it feels like that is enough. The error code sent in the respon= se could either be one of the SCIM-defined errors (mutability, etc...) or a= provider-defined error (eg - an error code number, etc...). >>=20 >>=20 >> -----Original Message----- >> From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Leif Johansson >> Sent: Monday, June 30, 2014 5:54 PM >> To: scim@ietf.org >> Subject: Re: [scim] Proposed Detail Errors >>=20 >> On 2014-06-30 23:43, Anthony Nadalin wrote: >>> Concern is that this can cause continuous code changes in different=20 >>> codes being registered, ideally there would only be a couple and=20 >>> they would be from the start but this could grow and cause=20 >>> interoperability issues with folks registering error codes >>=20 >> Thats going to be true for any extension though, right? Errors are no wo= rse in this respect. >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From nobody Tue Jul 1 09:53:36 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF511B2854 for ; Tue, 1 Jul 2014 09:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBp2CJrO5Wmw for ; Tue, 1 Jul 2014 09:53:31 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 297611B2853 for ; Tue, 1 Jul 2014 09:53:31 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s61GrTid002855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Jul 2014 16:53:30 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s61GrRhp015168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jul 2014 16:53:28 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s61GrR5A007778; Tue, 1 Jul 2014 16:53:27 GMT Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Jul 2014 09:53:27 -0700 References: <348F75D5-7C0F-4B93-A7B7-88E0B2FFD4ED@oracle.com> <232fc398cb76462088c589f6244f3bf9@BN1PR04MB392.namprd04.prod.outlook.com> <42A78180-7AA1-40FD-B257-DD6ECF06784E@oracle.com> <9075316269e949418386ee90ebedee42@BN1PR04MB392.namprd04.prod.outlook.com> <3B339C76-F410-41EF-A574-EA3FA85D8590@oracle.com> <29451b18f13248d1834c27b71b006df5@BLUPR03MB309.namprd03.prod.outlook.com> <53B1EA9E.4070101@mnt.se> <1272F486-DC54-4456-B4E4-061D134DD9BD@nexusgroup.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <6965D67A-7489-47D7-A957-FD35B43D87D4@oracle.com> X-Mailer: iPhone Mail (11D201) From: Phil Hunt Date: Tue, 1 Jul 2014 09:53:24 -0700 To: Anthony Nadalin X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/PFZqJYNwcH5FfEFuLBDrwAD2IEI Cc: Leif Johansson , =?utf-8?Q?Erik_Wahlstr=C3=B6m?= , "scim@ietf.org" , Kelly Grizzle Subject: Re: [scim] Proposed Detail Errors X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 16:53:34 -0000 +1 I think scimType should be omitted if the server is not prepared to share th= e detail.=20 We should keep in mind a request might be rejected by a non-scim provider su= ch as a gateway. In these cases there may be no body either. This shouldn't h= e surprising--just normal http stuff.=20 Phil > On Jul 1, 2014, at 9:27, Anthony Nadalin wrote: >=20 > +1 >=20 > -----Original Message----- > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Erik Wahlstr=C3=B6m= > Sent: Tuesday, July 1, 2014 6:53 AM > To: Phil Hunt > Cc: Leif Johansson; scim@ietf.org; Kelly Grizzle > Subject: Re: [scim] Proposed Detail Errors >=20 > Limiting the error codes works for me. As scimType is optional should a ge= neral "400 bad request" just not add the scimType or should we also specify a= "general" scimType to make it clear? Otherwise we should write it in bit mo= re detail in the text "For HTTP Status 400 (Bad Request) responses, the foll= owing detail error types are defined and is optional to return for the Servi= ce Provider:" >=20 > / Erik >=20 >> On 01 Jul 2014, at 05:50, Phil Hunt wrote: >>=20 >> My worry is that if service providers implement non-standard codes and th= an do not register them, then they can expect that clients shall ignore thei= r proprietary custom codes. >>=20 >> Still, service providers should also expect that not every client will im= plement registered codes either. >>=20 >> Clients will need to keep in mind that many service providers will likely= only return a general 400 bad request for *any* error as they may be cautio= us about proving attacks. >>=20 >> I recommend we limit error codes to protocol and schema issues only in or= der to get to a final draft in Toronto. >>=20 >> I understand the value of detailed error codes to coding smart UIs. But I= would prefer to deal with these fine-grained errors in a future charter. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>> On Jun 30, 2014, at 4:13 PM, Kelly Grizzle = wrote: >>>=20 >>> I don't know that service providers should have to register codes that a= re specific to their implementation ... that kind of seems like overkill to m= e. What benefit does that provide other than possibly preventing collisions= ? >>>=20 >>> As long as the SP can provide information to the client about what error= occurred, it feels like that is enough. The error code sent in the respons= e could either be one of the SCIM-defined errors (mutability, etc...) or a p= rovider-defined error (eg - an error code number, etc...). >>>=20 >>>=20 >>> -----Original Message----- >>> From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Leif Johansson >>> Sent: Monday, June 30, 2014 5:54 PM >>> To: scim@ietf.org >>> Subject: Re: [scim] Proposed Detail Errors >>>=20 >>>> On 2014-06-30 23:43, Anthony Nadalin wrote: >>>> Concern is that this can cause continuous code changes in different=20 >>>> codes being registered, ideally there would only be a couple and=20 >>>> they would be from the start but this could grow and cause=20 >>>> interoperability issues with folks registering error codes >>>=20 >>> Thats going to be true for any extension though, right? Errors are no wo= rse in this respect. >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Tue Jul 1 10:22:06 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8EA1B2899 for ; Tue, 1 Jul 2014 10:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-zKGKG_LIA2 for ; Tue, 1 Jul 2014 10:22:00 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D63D1B288D for ; Tue, 1 Jul 2014 10:22:00 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) with Microsoft SMTP Server (TLS) id 15.0.980.8; Tue, 1 Jul 2014 17:21:58 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.122]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.122]) with mapi id 15.00.0974.002; Tue, 1 Jul 2014 17:21:57 +0000 From: Kelly Grizzle To: Phil Hunt Thread-Topic: [scim] Proposed Detail Errors Thread-Index: AQHPkjhB1v2CfJQHskiODjem+S8OQ5uIh3KAgAAFIoCAATHUYIAAFNqAgAAmcoCAABOcAIAAAwOAgAAkAACAABOzAIAAAusggABP0gCAAOCCYA== Date: Tue, 1 Jul 2014 17:21:57 +0000 Message-ID: <200413b8e9774452bc49d82787c35fe5@BN1PR04MB392.namprd04.prod.outlook.com> References: <348F75D5-7C0F-4B93-A7B7-88E0B2FFD4ED@oracle.com> <232fc398cb76462088c589f6244f3bf9@BN1PR04MB392.namprd04.prod.outlook.com> <42A78180-7AA1-40FD-B257-DD6ECF06784E@oracle.com> <9075316269e949418386ee90ebedee42@BN1PR04MB392.namprd04.prod.outlook.com> <3B339C76-F410-41EF-A574-EA3FA85D8590@oracle.com> <29451b18f13248d1834c27b71b006df5@BLUPR03MB309.namprd03.prod.outlook.com> <53B1EA9E.4070101@mnt.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: EDDEB368007884EDDEB4B5 x-originating-ip: [2605:6000:0:8::f:9] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02596AB7DA x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(24454002)(13464003)(51704005)(377454003)(377424004)(83072002)(15974865002)(101416001)(15975445006)(4396001)(19580405001)(19580395003)(85852003)(86362001)(83322001)(87936001)(2656002)(74662001)(79102001)(33646001)(74502001)(77982001)(106116001)(107046002)(106356001)(21056001)(74316001)(76482001)(77096002)(76176999)(50986999)(46102001)(99396002)(54356999)(85306003)(105586002)(95666004)(80022001)(99286002)(81342001)(81542001)(20776003)(64706001)(76576001)(108616002)(3826002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Qq3XGMUMZufjy69sj1TieDt06-E Cc: Leif Johansson , "scim@ietf.org" Subject: Re: [scim] Proposed Detail Errors X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 17:22:03 -0000 > My worry is that if service providers implement non-standard codes and th= an do not register > them, then they can expect that clients shall ignore their proprietary cu= stom codes. I don't agree with this. My thinking is not that the client needs to have = a smart UI that can deal with these error codes, but that they need a way t= o know specifically what went wrong from a debugging perspective. More tha= n likely the error code will just get shoved into a log file, but it gives = the sys admin of the client the ability to know why a request failed. This type of information could be returned in the description of the error,= but if clients want to be able to handle these smartly they will have to s= tart parsing error messages. This was one of the key things to be answered in ticket 46: 3) If a service provider wants to transmit a more detailed error cod= e, how would it do this? Does this have to fit into the formatted description or can another = sub-attribute be added to the error reponse? --Kelly -----Original Message----- From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 Sent: Monday, June 30, 2014 10:51 PM To: Kelly Grizzle Cc: Leif Johansson; scim@ietf.org Subject: Re: [scim] Proposed Detail Errors My worry is that if service providers implement non-standard codes and than= do not register them, then they can expect that clients shall ignore their= proprietary custom codes. Still, service providers should also expect that not every client will impl= ement registered codes either. Clients will need to keep in mind that many service providers will likely o= nly return a general 400 bad request for *any* error as they may be cautiou= s about proving attacks. I recommend we limit error codes to protocol and schema issues only in orde= r to get to a final draft in Toronto. I understand the value of detailed error codes to coding smart UIs. But I w= ould prefer to deal with these fine-grained errors in a future charter. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jun 30, 2014, at 4:13 PM, Kelly Grizzle wr= ote: > I don't know that service providers should have to register codes that ar= e specific to their implementation ... that kind of seems like overkill to = me. What benefit does that provide other than possibly preventing collisio= ns? >=20 > As long as the SP can provide information to the client about what error = occurred, it feels like that is enough. The error code sent in the respons= e could either be one of the SCIM-defined errors (mutability, etc...) or a = provider-defined error (eg - an error code number, etc...). >=20 >=20 > -----Original Message----- > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Leif Johansson > Sent: Monday, June 30, 2014 5:54 PM > To: scim@ietf.org > Subject: Re: [scim] Proposed Detail Errors >=20 > On 2014-06-30 23:43, Anthony Nadalin wrote: >> Concern is that this can cause continuous code changes in different=20 >> codes being registered, ideally there would only be a couple and they=20 >> would be from the start but this could grow and cause=20 >> interoperability issues with folks registering error codes >=20 > Thats going to be true for any extension though, right? Errors are no wor= se in this respect. >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Wed Jul 2 10:12:31 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A5A1A05C3 for ; Wed, 2 Jul 2014 10:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLGupSs3_Gtu for ; Wed, 2 Jul 2014 10:12:25 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F60E1A039B for ; Wed, 2 Jul 2014 10:12:25 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s62HCO05008932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 2 Jul 2014 17:12:24 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s62HCNPq011738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Jul 2014 17:12:24 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s62HCN12017717 for ; Wed, 2 Jul 2014 17:12:23 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 Jul 2014 10:12:23 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_9B0336C5-8F28-4AF6-88A2-BCCEA377F233" Message-Id: <715BABD4-91D5-45FA-874A-FD14AEBC1577@oracle.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Date: Wed, 2 Jul 2014 10:12:21 -0700 References: <348F75D5-7C0F-4B93-A7B7-88E0B2FFD4ED@oracle.com> To: Scim WG In-Reply-To: <348F75D5-7C0F-4B93-A7B7-88E0B2FFD4ED@oracle.com> X-Mailer: Apple Mail (2.1878.2) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/x1tUj4e_WScMHv19YMtuFVT3qVw Subject: Re: [scim] Proposed Detail Errors X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 17:12:27 -0000 --Apple-Mail=_9B0336C5-8F28-4AF6-88A2-BCCEA377F233 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Folks, We=92ve had quite a lot of discussion on this thread. It seems that the = list of errors (below) is well accepted but the question of = extensibility still needs to be resolved. I propose to publish the errors (shown below) with an editorial comment = that extensibility is being discussed and that these may change to URIs = (depending on how we resolve). The reason I would like to have this published is so that attendees can = have all the information in context for the meeting and the deadline is = Friday.=20 Any objections? Phil @independentid www.independentid.com phil.hunt@oracle.com On Jun 27, 2014, at 11:47 AM, Phil Hunt wrote: > After reviewing the API and Schema docs, here is a first cut of the = detailed error codes. >=20 > For HTTP Status 400 (Bad Request) responses, the following detail > error types are defined: >=20 > +--------------+------------------------------+---------------------+ > | scimType | Description | Applicability | > +--------------+------------------------------+---------------------+ > | invalidFilte | The specified filter syntax | GET(Section 3.2.2), | > | r | was invalid (does not comply | POST (Search - | > | | with Figure 1) or the | Section 3.2.3), | > | | specified attribute and | PATCH (Path Filter | > | | filter comparison | - Section 3.3.2) | > | | combination is not | | > | | supported. | | > | uniqueness | One or more of attribute | POST (Create - | > | | values is already in use or | Section 3.1), PUT | > | | is reserved. | (Section 3.3.1), | > | | | PATCH (Section | > | | | 3.3.2) | > | mutability | The attempted modification | PUT (Section | > | | is not compatible with the | 3.3.1), PATCH | > | | target attributes mutability | (Section 3.3.2) | > | | or current state (e.g. | | > | | modification of an immutable | | > | | attribute with an existing | | > | | value). | | > | invalidSynta | The request body message | POST (Search - | > | x | structure was invalid or did | Section 3.2.2, | > | | not conform to the request | Create - Section | > | | schema. | 3.1, Bulk - Section | > | | | 3.5), PUT (Section | > | | | 3.3.1) | > | invalidPath | The path attribute was | PATCH (Section | > | | invalid or malformed (see | 3.3.2) | > | | Figure 4). | | > | noTarget | The specified "path" did not | PATCH (Section | > | | yield an attribute or | 3.3.2) | > | | attribute value that could | | > | | be operated on. This occurs | | > | | when the specified "path" | | > | | value contains a filter that | | > | | yields no match. | | > | invalidValue | A required value was | GET (Section | > | | missing, or the value | 3.2.2), POST | > | | specified was not compatible | (Create - Section | > | | with the operation or | 3.1, Search - | > | | attribute type (see Section | Section 3.2.2), PUT | > | | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1), | > | | ma]). | PATCH (Section | > | | | 3.3.2) | > | invalidVers | The specified API version is | GET (Section | > | | not supported (see Section | 3.2.2), POST (ALL), | > | | 3.11). | PUT (Section | > | | | 3.3.1), PATCH | > | | | (Section 3.3.2), | > | | | DELETE (Section | > | | | 3.4) | > +--------------+------------------------------+---------------------+ > I plan to put these into draft 07 of the API and will publish over the = weekend. >=20 > As always, feedback welcome! >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 --Apple-Mail=_9B0336C5-8F28-4AF6-88A2-BCCEA377F233 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Folks,

We=92ve had quite a lot of = discussion on this thread. It seems that the list of errors (below) is = well accepted but the question of extensibility still needs to be = resolved.

I propose to publish the errors = (shown below) with an editorial comment that extensibility is being = discussed and that these may change to URIs (depending on how we = resolve).

The reason I would like to have this = published is so that attendees can have all the information in context = for the meeting and the deadline is = Friday. 

Any = objections?


On Jun 27, 2014, at 11:47 AM, Phil Hunt <phil.hunt@oracle.com> = wrote:

After = reviewing the API and Schema docs, here is a first cut of the detailed = error codes.

For HTTP Status 400 (Bad Request) responses, the =
following detail
   error types are defined:

+--------------+------------------------------+---------------------+
| scimType     | Description                  | Applicability       |
+--------------+------------------------------+---------------------+
| invalidFilte | The specified filter syntax  | GET(Section 3.2.2), |
| r            | was invalid (does not comply | POST (Search -      |
|              | with Figure 1) or the        | Section 3.2.3),     |
|              | specified attribute and      | PATCH (Path Filter  |
|              | filter comparison            | - Section 3.3.2)    |
|              | combination is not           |                     |
|              | supported.                   |                     |
| uniqueness   | One or more of attribute     | POST (Create -      |
|              | values is already in use or  | Section 3.1), PUT   |
|              | is reserved.                 | (Section 3.3.1),    |
|              |                              | PATCH (Section      |
|              |                              | 3.3.2)              |
| mutability   | The attempted modification   | PUT (Section        |
|              | is not compatible with the   | 3.3.1), PATCH       |
|              | target attributes mutability | (Section 3.3.2)     |
|              | or current state (e.g.       |                     |
|              | modification of an immutable |                     |
|              | attribute with an existing   |                     |
|              | value).                      |                     |
| invalidSynta | The request body message     | POST (Search -      |
| x            | structure was invalid or did | Section 3.2.2,      |
|              | not conform to the request   | Create - Section    |
|              | schema.                      | 3.1, Bulk - Section |
|              |                              | 3.5), PUT (Section  |
|              |                              | 3.3.1)              |
| invalidPath  | The path attribute was       | PATCH (Section      |
|              | invalid or malformed (see    | 3.3.2)              |
|              | Figure 4).                   |                     |
| noTarget     | The specified "path" did not | PATCH (Section      |
|              | yield an attribute or        | 3.3.2)              |
|              | attribute value that could   |                     |
|              | be operated on. This occurs  |                     |
|              | when the specified "path"    |                     |
|              | value contains a filter that |                     |
|              | yields no match.             |                     |
| invalidValue | A required value was         | GET (Section        |
|              | missing, or the value        | 3.2.2), POST        |
|              | specified was not compatible | (Create - Section   |
|              | with the operation or        | 3.1, Search -       |
|              | attribute type (see Section  | Section 3.2.2), PUT |
|              | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1),    |
|              | ma]).                        | PATCH (Section      |
|              |                              | 3.3.2)              |
| invalidVers  | The specified API version is | GET (Section        |
|              | not supported (see Section   | 3.2.2), POST (ALL), |
|              | 3.11).                       | PUT (Section        |
|              |                              | 3.3.1), PATCH       |
|              |                              | (Section 3.3.2),    |
|              |                              | DELETE (Section     |
|              |                              | 3.4)                |
+--------------+------------------------------+---------------------+
I plan to put these into draft 07 of the API and will publish = over the weekend.

As always, feedback = welcome!


= --Apple-Mail=_9B0336C5-8F28-4AF6-88A2-BCCEA377F233-- From nobody Wed Jul 2 10:16:55 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D081A034D for ; Wed, 2 Jul 2014 10:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmJhnUYDLdtE for ; Wed, 2 Jul 2014 10:16:48 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D35A11A01BD for ; Wed, 2 Jul 2014 10:16:47 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB311.namprd03.prod.outlook.com (10.141.48.26) with Microsoft SMTP Server (TLS) id 15.0.974.11; Wed, 2 Jul 2014 17:16:45 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0974.002; Wed, 2 Jul 2014 17:16:45 +0000 From: Anthony Nadalin To: Phil Hunt , Scim WG Thread-Topic: [scim] Proposed Detail Errors Thread-Index: AQHPkjhIzbP18zhaFUGCaYkX6dnJmZuNDSGAgAABJwA= Date: Wed, 2 Jul 2014 17:16:45 +0000 Message-ID: <883b731b17a344abb68052135954702d@BLUPR03MB309.namprd03.prod.outlook.com> References: <348F75D5-7C0F-4B93-A7B7-88E0B2FFD4ED@oracle.com> <715BABD4-91D5-45FA-874A-FD14AEBC1577@oracle.com> In-Reply-To: <715BABD4-91D5-45FA-874A-FD14AEBC1577@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.1] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-forefront-prvs: 0260457E99 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(24454002)(199002)(189002)(4396001)(50986999)(54356999)(79102001)(83322001)(19580405001)(19625215002)(19580395003)(101416001)(66066001)(80022001)(21056001)(76482001)(46102001)(81542001)(99396002)(64706001)(81342001)(15202345003)(19300405004)(95666004)(99286002)(77982001)(105586002)(74316001)(74502001)(15975445006)(85306003)(106116001)(20776003)(33646001)(83072002)(76576001)(76176999)(2656002)(85852003)(86612001)(107046002)(16601075003)(16236675004)(74662001)(106356001)(107886001)(86362001)(31966008)(92566001)(87936001)(19609705001)(108616002)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB311; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_883b731b17a344abb68052135954702dBLUPR03MB309namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/tkRRA1hf0Jms7rzN3aaaXfAxMsk Subject: Re: [scim] Proposed Detail Errors X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 17:16:52 -0000 --_000_883b731b17a344abb68052135954702dBLUPR03MB309namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fine, let's move this forward From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Wednesday, July 2, 2014 10:12 AM To: Scim WG Subject: Re: [scim] Proposed Detail Errors Folks, We've had quite a lot of discussion on this thread. It seems that the list = of errors (below) is well accepted but the question of extensibility still = needs to be resolved. I propose to publish the errors (shown below) with an editorial comment tha= t extensibility is being discussed and that these may change to URIs (depen= ding on how we resolve). The reason I would like to have this published is so that attendees can hav= e all the information in context for the meeting and the deadline is Friday= . Any objections? Phil @independentid www.independentid.com phil.hunt@oracle.com On Jun 27, 2014, at 11:47 AM, Phil Hunt > wrote: After reviewing the API and Schema docs, here is a first cut of the detaile= d error codes. For HTTP Status 400 (Bad Request) responses, the following detail error types are defined: +--------------+------------------------------+---------------------+ | scimType | Description | Applicability | +--------------+------------------------------+---------------------+ | invalidFilte | The specified filter syntax | GET(Section 3.2.2), | | r | was invalid (does not comply | POST (Search - | | | with Figure 1) or the | Section 3.2.3), | | | specified attribute and | PATCH (Path Filter | | | filter comparison | - Section 3.3.2) | | | combination is not | | | | supported. | | | uniqueness | One or more of attribute | POST (Create - | | | values is already in use or | Section 3.1), PUT | | | is reserved. | (Section 3.3.1), | | | | PATCH (Section | | | | 3.3.2) | | mutability | The attempted modification | PUT (Section | | | is not compatible with the | 3.3.1), PATCH | | | target attributes mutability | (Section 3.3.2) | | | or current state (e.g. | | | | modification of an immutable | | | | attribute with an existing | | | | value). | | | invalidSynta | The request body message | POST (Search - | | x | structure was invalid or did | Section 3.2.2, | | | not conform to the request | Create - Section | | | schema. | 3.1, Bulk - Section | | | | 3.5), PUT (Section | | | | 3.3.1) | | invalidPath | The path attribute was | PATCH (Section | | | invalid or malformed (see | 3.3.2) | | | Figure 4). | | | noTarget | The specified "path" did not | PATCH (Section | | | yield an attribute or | 3.3.2) | | | attribute value that could | | | | be operated on. This occurs | | | | when the specified "path" | | | | value contains a filter that | | | | yields no match. | | | invalidValue | A required value was | GET (Section | | | missing, or the value | 3.2.2), POST | | | specified was not compatible | (Create - Section | | | with the operation or | 3.1, Search - | | | attribute type (see Section | Section 3.2.2), PUT | | | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1), | | | ma]). | PATCH (Section | | | | 3.3.2) | | invalidVers | The specified API version is | GET (Section | | | not supported (see Section | 3.2.2), POST (ALL), | | | 3.11). | PUT (Section | | | | 3.3.1), PATCH | | | | (Section 3.3.2), | | | | DELETE (Section | | | | 3.4) | +--------------+------------------------------+---------------------+ I plan to put these into draft 07 of the API and will publish over the week= end. As always, feedback welcome! Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_883b731b17a344abb68052135954702dBLUPR03MB309namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Fine, let’s move th= is forward

 

From: scim [= mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, July 2, 2014 10:12 AM
To: Scim WG
Subject: Re: [scim] Proposed Detail Errors

 

Folks,

 

We’ve had quite a lot of discussion on this th= read. It seems that the list of errors (below) is well accepted but the que= stion of extensibility still needs to be resolved.

 

I propose to publish the errors (shown below) with a= n editorial comment that extensibility is being discussed and that these ma= y change to URIs (depending on how we resolve).

 

The reason I would like to have this published is so= that attendees can have all the information in context for the meeting and= the deadline is Friday. 

 

Any objections?

 

Phil

 

@independentid<= /span>

ph= il.hunt@oracle.com

 

 

 

On Jun 27, 2014, at 11:47 AM, Phil Hunt <phil.hunt@oracle.com> wrote:



After reviewing the API and Schema docs, here is a f= irst cut of the detailed error codes.

 

For HTTP Status 4=
00 (Bad Request) responses, the following detail
   error types are defined:
 
+--------------+------------------------------+-----------=
----------+
| scimType     | Description   &nbs=
p;            &=
nbsp; | Applicability       |

+--------------+------------------------------+-----------=
----------+


| invalidFilte | The specified filter syntax  | GET(Section 3.2.2=
), |


| r            =
| was invalid (does not comply | POST (Search -    &nbs=
p; |


|           &nb=
sp;  | with Figure 1) or the       =
 | Section 3.2.3),     |


|           &nb=
sp;  | specified attribute and      | PATCH (=
Path Filter  |


|           &nb=
sp;  | filter comparison       &nbs=
p;    | - Section 3.3.2)    |

|           &nb=
sp;  | combination is not       &nb=
sp;   |         &nbs=
p;           |=



|           &nb=
sp;  | supported.         =
;          |   =
            &nb=
sp;     |


| uniqueness   | One or more of attribute   &=
nbsp; | POST (Create -      |


|           &nb=
sp;  | values is already in use or  | Section 3.1), PUT &nbs=
p; |


|           &nb=
sp;  | is reserved.        &nb=
sp;        | (Section 3.3.1),  =
;  |


|           &nb=
sp;  |           &nb=
sp;            =
      | PATCH (Section    =
;  |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | 3.3.2)     &=
nbsp;        |


| mutability   | The attempted modification   | PU=
T (Section        |


|           &nb=
sp;  | is not compatible with the   | 3.3.1), PATCH &nb=
sp;     |


|           &nb=
sp;  | target attributes mutability | (Section 3.3.2)   =
;  |


|           &nb=
sp;  | or current state (e.g.       |&nb=
sp;            =
        |


|           &nb=
sp;  | modification of an immutable |     &nb=
sp;            =
   |


|           &nb=
sp;  | attribute with an existing   |    =
;            &n=
bsp;    |


|           &nb=
sp;  | value).         &n=
bsp;            |&nb=
sp;            =
        |


| invalidSynta | The request body message     | PO=
ST (Search -      |


| x            =
| structure was invalid or did | Section 3.2.2,    &nbs=
p; |


|           &nb=
sp;  | not conform to the request   | Create - Section =
   |


|           &nb=
sp;  | schema.         &n=
bsp;            | 3.=
1, Bulk - Section |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | 3.5), PUT (Section  |=



|           &nb=
sp;  |          &nbs=
p;             =
      | 3.3.1)     &=
nbsp;        |


| invalidPath  | The path attribute was    &n=
bsp;  | PATCH (Section      |

|           &nb=
sp;  | invalid or malformed (see    | 3.3.2)  =
;            |<=
/o:p>


|           &nb=
sp;  | Figure 4).         =
;          |   =
            &nb=
sp;     |


| noTarget     | The specified "path" di=
d not | PATCH (Section      |


|           &nb=
sp;  | yield an attribute or       =
 | 3.3.2)           =
   |


|           &nb=
sp;  | attribute value that could   |    =
;            &n=
bsp;    |


|           &nb=
sp;  | be operated on. This occurs  |    &nbs=
p;             =
   |


|           &nb=
sp;  | when the specified "path"    | &n=
bsp;            =
;       |


|           &nb=
sp;  | value contains a filter that |     &nb=
sp;            =
   |


|           &nb=
sp;  | yields no match.        =
;     |        =
             |<=
o:p>


| invalidValue | A required value was     &nb=
sp;   | GET (Section        |<=
o:p>


|           &nb=
sp;  | missing, or the value       =
 | 3.2.2), POST        |

|           &nb=
sp;  | specified was not compatible | (Create - Section   |<=
o:p>


|           &nb=
sp;  | with the operation or       =
 | 3.1, Search -       |


|            &n=
bsp; | attribute type (see Section  | Section 3.2.2), PUT |<=
/o:p>


|           &nb=
sp;  | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1),  &nbs=
p; |


|           &nb=
sp;  | ma]).         &nbs=
p;            &=
nbsp; | PATCH (Section      |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | 3.3.2)      =
        |


| invalidVers  | The specified API version is | GET (Section =
;       |


|           &nb=
sp;  | not supported (see Section   | 3.2.2), POST (ALL), |<=
o:p>


|           &nb=
sp;  | 3.11).         &nb=
sp;            =
 | PUT (Section        |

|           &nb=
sp;  |          &nbs=
p;             =
      | 3.3.1), PATCH    =
   |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | (Section 3.3.2),    |<=
o:p>


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | DELETE (Section   &nbs=
p; |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | 3.4)     &nb=
sp;          |

+--------------+------------------------------+-----------=
----------+




I plan to put these into draft 07 of the API and wil=
l publish over the weekend.






 






As always, feedback welcome!






 





















 
















 




 

 

--_000_883b731b17a344abb68052135954702dBLUPR03MB309namprd03pro_-- From nobody Wed Jul 2 10:43:50 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D95D1A0527 for ; Wed, 2 Jul 2014 10:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxlSKibPnJ3U for ; Wed, 2 Jul 2014 10:43:46 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0186.outbound.protection.outlook.com [207.46.163.186]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2BAF1A03B4 for ; Wed, 2 Jul 2014 10:43:45 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) with Microsoft SMTP Server (TLS) id 15.0.980.8; Wed, 2 Jul 2014 17:43:43 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.122]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.122]) with mapi id 15.00.0974.002; Wed, 2 Jul 2014 17:43:43 +0000 From: Kelly Grizzle To: Anthony Nadalin , Phil Hunt , Scim WG Thread-Topic: [scim] Proposed Detail Errors Thread-Index: AQHPkjhB1v2CfJQHskiODjem+S8OQ5uNDSGAgAABOoCAAAd+4A== Date: Wed, 2 Jul 2014 17:43:42 +0000 Message-ID: References: <348F75D5-7C0F-4B93-A7B7-88E0B2FFD4ED@oracle.com> <715BABD4-91D5-45FA-874A-FD14AEBC1577@oracle.com> <883b731b17a344abb68052135954702d@BLUPR03MB309.namprd03.prod.outlook.com> In-Reply-To: <883b731b17a344abb68052135954702d@BLUPR03MB309.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 01050DDA0078A401050F27 x-originating-ip: [2605:6000:0:8::f:9] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0260457E99 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(199002)(189002)(24454002)(85306003)(54356999)(81342001)(80022001)(99286002)(76576001)(95666004)(105586002)(99396002)(76176999)(50986999)(46102001)(64706001)(20776003)(16601075003)(81542001)(86362001)(92566001)(19625215002)(19580405001)(85852003)(19580395003)(87936001)(83322001)(2656002)(19609705001)(15975445006)(83072002)(15202345003)(101416001)(19300405004)(4396001)(107886001)(76482001)(106356001)(21056001)(74316001)(77096002)(31966008)(79102001)(74662001)(16236675004)(107046002)(1511001)(106116001)(74502001)(77982001)(33646001)(108616002)(3826002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_b68c715fb15e4ccb829589f21d37ea4eBN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/C2-42UFCKNrOz0eJb-4OJcJ8Wp8 Subject: Re: [scim] Proposed Detail Errors X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 17:43:48 -0000 --_000_b68c715fb15e4ccb829589f21d37ea4eBN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Works for me. From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Anthony Nadalin Sent: Wednesday, July 02, 2014 12:17 PM To: Phil Hunt; Scim WG Subject: Re: [scim] Proposed Detail Errors Fine, let's move this forward From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Wednesday, July 2, 2014 10:12 AM To: Scim WG Subject: Re: [scim] Proposed Detail Errors Folks, We've had quite a lot of discussion on this thread. It seems that the list = of errors (below) is well accepted but the question of extensibility still = needs to be resolved. I propose to publish the errors (shown below) with an editorial comment tha= t extensibility is being discussed and that these may change to URIs (depen= ding on how we resolve). The reason I would like to have this published is so that attendees can hav= e all the information in context for the meeting and the deadline is Friday= . Any objections? Phil @independentid www.independentid.com phil.hunt@oracle.com On Jun 27, 2014, at 11:47 AM, Phil Hunt > wrote: After reviewing the API and Schema docs, here is a first cut of the detaile= d error codes. For HTTP Status 400 (Bad Request) responses, the following detail error types are defined: +--------------+------------------------------+---------------------+ | scimType | Description | Applicability | +--------------+------------------------------+---------------------+ | invalidFilte | The specified filter syntax | GET(Section 3.2.2), | | r | was invalid (does not comply | POST (Search - | | | with Figure 1) or the | Section 3.2.3), | | | specified attribute and | PATCH (Path Filter | | | filter comparison | - Section 3.3.2) | | | combination is not | | | | supported. | | | uniqueness | One or more of attribute | POST (Create - | | | values is already in use or | Section 3.1), PUT | | | is reserved. | (Section 3.3.1), | | | | PATCH (Section | | | | 3.3.2) | | mutability | The attempted modification | PUT (Section | | | is not compatible with the | 3.3.1), PATCH | | | target attributes mutability | (Section 3.3.2) | | | or current state (e.g. | | | | modification of an immutable | | | | attribute with an existing | | | | value). | | | invalidSynta | The request body message | POST (Search - | | x | structure was invalid or did | Section 3.2.2, | | | not conform to the request | Create - Section | | | schema. | 3.1, Bulk - Section | | | | 3.5), PUT (Section | | | | 3.3.1) | | invalidPath | The path attribute was | PATCH (Section | | | invalid or malformed (see | 3.3.2) | | | Figure 4). | | | noTarget | The specified "path" did not | PATCH (Section | | | yield an attribute or | 3.3.2) | | | attribute value that could | | | | be operated on. This occurs | | | | when the specified "path" | | | | value contains a filter that | | | | yields no match. | | | invalidValue | A required value was | GET (Section | | | missing, or the value | 3.2.2), POST | | | specified was not compatible | (Create - Section | | | with the operation or | 3.1, Search - | | | attribute type (see Section | Section 3.2.2), PUT | | | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1), | | | ma]). | PATCH (Section | | | | 3.3.2) | | invalidVers | The specified API version is | GET (Section | | | not supported (see Section | 3.2.2), POST (ALL), | | | 3.11). | PUT (Section | | | | 3.3.1), PATCH | | | | (Section 3.3.2), | | | | DELETE (Section | | | | 3.4) | +--------------+------------------------------+---------------------+ I plan to put these into draft 07 of the API and will publish over the week= end. As always, feedback welcome! Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_b68c715fb15e4ccb829589f21d37ea4eBN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Works for me.<= /span>

 <= /p>

From: scim [ma= ilto:scim-bounces@ietf.org] On Behalf Of Anthony Nadalin
Sent: Wednesday, July 02, 2014 12:17 PM
To: Phil Hunt; Scim WG
Subject: Re: [scim] Proposed Detail Errors

 

Fine, let’s move th= is forward

 

From: scim [= mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, July 2, 2014 10:12 AM
To: Scim WG
Subject: Re: [scim] Proposed Detail Errors

 

Folks,

 

We’ve had quite a lot of discussion on this th= read. It seems that the list of errors (below) is well accepted but the que= stion of extensibility still needs to be resolved.

 

I propose to publish the errors (shown below) with a= n editorial comment that extensibility is being discussed and that these ma= y change to URIs (depending on how we resolve).

 

The reason I would like to have this published is so= that attendees can have all the information in context for the meeting and= the deadline is Friday. 

 

Any objections?

 

Phil

 

@independentid<= /span>

ph= il.hunt@oracle.com

 

 

 

On Jun 27, 2014, at 11:47 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

 

After reviewing the API and Schema docs, here is a f= irst cut of the detailed error codes.

 

For HTTP Status 4=
00 (Bad Request) responses, the following detail
   error types are defined:
 
+--------------+------------------------------+-----------=
----------+
| scimType     | Description   &nbs=
p;            &=
nbsp; | Applicability       |

+--------------+------------------------------+-----------=
----------+


| invalidFilte | The specified filter syntax  | GET(Section 3.2.2=
), |


| r            =
| was invalid (does not comply | POST (Search -    &nbs=
p; |


|           &nb=
sp;  | with Figure 1) or the       =
 | Section 3.2.3),     |


|           &nb=
sp;  | specified attribute and      | PATCH (=
Path Filter  |


|           &nb=
sp;  | filter comparison       &nbs=
p;    | - Section 3.3.2)    |

|           &nb=
sp;  | combination is not       &nb=
sp;   |         &nbs=
p;           |=



|           &nb=
sp;  | supported.         =
;          |   =
            &nb=
sp;     |


| uniqueness   | One or more of attribute   &=
nbsp; | POST (Create -      |


|           &nb=
sp;  | values is already in use or  | Section 3.1), PUT &nbs=
p; |


|           &nb=
sp;  | is reserved.        &nb=
sp;        | (Section 3.3.1),  =
;  |


|           &nb=
sp;  |           &nb=
sp;            =
      | PATCH (Section    =
;  |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | 3.3.2)     &=
nbsp;        |


| mutability   | The attempted modification   | PU=
T (Section        |


|           &nb=
sp;  | is not compatible with the   | 3.3.1), PATCH &nb=
sp;     |


|           &nb=
sp;  | target attributes mutability | (Section 3.3.2)   =
;  |


|           &nb=
sp;  | or current state (e.g.       |&nb=
sp;            =
        |


|           &nb=
sp;  | modification of an immutable |     &nb=
sp;            =
   |


|           &nb=
sp;  | attribute with an existing   |    =
;            &n=
bsp;    |


|           &nb=
sp;  | value).         &n=
bsp;            |&nb=
sp;            =
        |


| invalidSynta | The request body message     | PO=
ST (Search -      |


| x            =
| structure was invalid or did | Section 3.2.2,    &nbs=
p; |


|           &nb=
sp;  | not conform to the request   | Create - Section =
   |


|           &nb=
sp;  | schema.         &n=
bsp;            | 3.=
1, Bulk - Section |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | 3.5), PUT (Section  |=



|           &nb=
sp;  |          &nbs=
p;             =
      | 3.3.1)     &=
nbsp;        |


| invalidPath  | The path attribute was    &n=
bsp;  | PATCH (Section      |

|           &nb=
sp;  | invalid or malformed (see    | 3.3.2)  =
;            |<=
/o:p>


|           &nb=
sp;  | Figure 4).         =
;          |   =
            &nb=
sp;     |


| noTarget     | The specified "path" di=
d not | PATCH (Section      |


|           &nb=
sp;  | yield an attribute or       =
 | 3.3.2)           =
   |


|           &nb=
sp;  | attribute value that could   |    =
;            &n=
bsp;    |


|           &nb=
sp;  | be operated on. This occurs  |    &nbs=
p;             =
   |


|           &nb=
sp;  | when the specified "path"    | &n=
bsp;            =
;       |


|           &nb=
sp;  | value contains a filter that |     &nb=
sp;            =
   |


|           &nb=
sp;  | yields no match.        =
;     |        =
             |<=
o:p>


| invalidValue | A required value was     &nb=
sp;   | GET (Section        |<=
o:p>


|           &nb=
sp;  | missing, or the value       =
 | 3.2.2), POST        |

|           &nb=
sp;  | specified was not compatible | (Create - Section   |<=
o:p>


|           &nb=
sp;  | with the operation or       =
 | 3.1, Search -       |


|            &n=
bsp; | attribute type (see Section  | Section 3.2.2), PUT |<=
/o:p>


|           &nb=
sp;  | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1),  &nbs=
p; |


|           &nb=
sp;  | ma]).         &nbs=
p;            &=
nbsp; | PATCH (Section      |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | 3.3.2)      =
        |


| invalidVers  | The specified API version is | GET (Section =
;       |


|           &nb=
sp;  | not supported (see Section   | 3.2.2), POST (ALL), |<=
o:p>


|           &nb=
sp;  | 3.11).         &nb=
sp;            =
 | PUT (Section        |

|           &nb=
sp;  |          &nbs=
p;             =
      | 3.3.1), PATCH    =
   |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | (Section 3.3.2),    |<=
o:p>


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | DELETE (Section   &nbs=
p; |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | 3.4)     &nb=
sp;          |

+--------------+------------------------------+-----------=
----------+




I plan to put these into draft 07 of the API and wil=
l publish over the weekend.






 






As always, feedback welcome!






 





















 
















 




 

 

--_000_b68c715fb15e4ccb829589f21d37ea4eBN1PR04MB392namprd04pro_-- From nobody Wed Jul 2 11:12:35 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1BA1B2852 for ; Wed, 2 Jul 2014 11:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dGznzreZtEZ for ; Wed, 2 Jul 2014 11:12:31 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16B761B280D for ; Wed, 2 Jul 2014 11:12:31 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s62ICT4O012503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 2 Jul 2014 18:12:30 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s62ICTM9027604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Jul 2014 18:12:29 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s62ICSTb018569 for ; Wed, 2 Jul 2014 18:12:28 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 Jul 2014 11:12:28 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_FD916F0F-DDA7-4C8B-9412-5A3337A84872" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Date: Wed, 2 Jul 2014 11:12:24 -0700 References: <348F75D5-7C0F-4B93-A7B7-88E0B2FFD4ED@oracle.com> To: Scim WG In-Reply-To: <348F75D5-7C0F-4B93-A7B7-88E0B2FFD4ED@oracle.com> X-Mailer: Apple Mail (2.1878.2) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/l1f6OS8DXtF-WlYgtBVohBw-9l4 Subject: Re: [scim] Proposed Detail Errors X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 18:12:33 -0000 --Apple-Mail=_FD916F0F-DDA7-4C8B-9412-5A3337A84872 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 One item missed. Reviewing ticket 37, I see I missed the case where the filter specified = yields too many matches. I will add a code =93tooMany=94 to describe this condition. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jun 27, 2014, at 11:47 AM, Phil Hunt wrote: > After reviewing the API and Schema docs, here is a first cut of the = detailed error codes. >=20 > For HTTP Status 400 (Bad Request) responses, the following detail > error types are defined: >=20 > +--------------+------------------------------+---------------------+ > | scimType | Description | Applicability | > +--------------+------------------------------+---------------------+ > | invalidFilte | The specified filter syntax | GET(Section 3.2.2), | > | r | was invalid (does not comply | POST (Search - | > | | with Figure 1) or the | Section 3.2.3), | > | | specified attribute and | PATCH (Path Filter | > | | filter comparison | - Section 3.3.2) | > | | combination is not | | > | | supported. | | > | uniqueness | One or more of attribute | POST (Create - | > | | values is already in use or | Section 3.1), PUT | > | | is reserved. | (Section 3.3.1), | > | | | PATCH (Section | > | | | 3.3.2) | > | mutability | The attempted modification | PUT (Section | > | | is not compatible with the | 3.3.1), PATCH | > | | target attributes mutability | (Section 3.3.2) | > | | or current state (e.g. | | > | | modification of an immutable | | > | | attribute with an existing | | > | | value). | | > | invalidSynta | The request body message | POST (Search - | > | x | structure was invalid or did | Section 3.2.2, | > | | not conform to the request | Create - Section | > | | schema. | 3.1, Bulk - Section | > | | | 3.5), PUT (Section | > | | | 3.3.1) | > | invalidPath | The path attribute was | PATCH (Section | > | | invalid or malformed (see | 3.3.2) | > | | Figure 4). | | > | noTarget | The specified "path" did not | PATCH (Section | > | | yield an attribute or | 3.3.2) | > | | attribute value that could | | > | | be operated on. This occurs | | > | | when the specified "path" | | > | | value contains a filter that | | > | | yields no match. | | > | invalidValue | A required value was | GET (Section | > | | missing, or the value | 3.2.2), POST | > | | specified was not compatible | (Create - Section | > | | with the operation or | 3.1, Search - | > | | attribute type (see Section | Section 3.2.2), PUT | > | | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1), | > | | ma]). | PATCH (Section | > | | | 3.3.2) | > | invalidVers | The specified API version is | GET (Section | > | | not supported (see Section | 3.2.2), POST (ALL), | > | | 3.11). | PUT (Section | > | | | 3.3.1), PATCH | > | | | (Section 3.3.2), | > | | | DELETE (Section | > | | | 3.4) | > +--------------+------------------------------+---------------------+ > I plan to put these into draft 07 of the API and will publish over the = weekend. >=20 > As always, feedback welcome! >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_FD916F0F-DDA7-4C8B-9412-5A3337A84872 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 One = item missed.

Reviewing ticket 37, I see I missed the = case where the filter specified yields too many = matches.

I will add a code =93tooMany=94 to = describe this condition.

=

On Jun 27, 2014, at 11:47 AM, Phil Hunt <phil.hunt@oracle.com> = wrote:

After = reviewing the API and Schema docs, here is a first cut of the detailed = error codes.

For HTTP Status 400 (Bad Request) responses, the =
following detail
   error types are defined:

+--------------+------------------------------+---------------------+
| scimType     | Description                  | Applicability       |
+--------------+------------------------------+---------------------+
| invalidFilte | The specified filter syntax  | GET(Section 3.2.2), |
| r            | was invalid (does not comply | POST (Search -      |
|              | with Figure 1) or the        | Section 3.2.3),     |
|              | specified attribute and      | PATCH (Path Filter  |
|              | filter comparison            | - Section 3.3.2)    |
|              | combination is not           |                     |
|              | supported.                   |                     |
| uniqueness   | One or more of attribute     | POST (Create -      |
|              | values is already in use or  | Section 3.1), PUT   |
|              | is reserved.                 | (Section 3.3.1),    |
|              |                              | PATCH (Section      |
|              |                              | 3.3.2)              |
| mutability   | The attempted modification   | PUT (Section        |
|              | is not compatible with the   | 3.3.1), PATCH       |
|              | target attributes mutability | (Section 3.3.2)     |
|              | or current state (e.g.       |                     |
|              | modification of an immutable |                     |
|              | attribute with an existing   |                     |
|              | value).                      |                     |
| invalidSynta | The request body message     | POST (Search -      |
| x            | structure was invalid or did | Section 3.2.2,      |
|              | not conform to the request   | Create - Section    |
|              | schema.                      | 3.1, Bulk - Section |
|              |                              | 3.5), PUT (Section  |
|              |                              | 3.3.1)              |
| invalidPath  | The path attribute was       | PATCH (Section      |
|              | invalid or malformed (see    | 3.3.2)              |
|              | Figure 4).                   |                     |
| noTarget     | The specified "path" did not | PATCH (Section      |
|              | yield an attribute or        | 3.3.2)              |
|              | attribute value that could   |                     |
|              | be operated on. This occurs  |                     |
|              | when the specified "path"    |                     |
|              | value contains a filter that |                     |
|              | yields no match.             |                     |
| invalidValue | A required value was         | GET (Section        |
|              | missing, or the value        | 3.2.2), POST        |
|              | specified was not compatible | (Create - Section   |
|              | with the operation or        | 3.1, Search -       |
|              | attribute type (see Section  | Section 3.2.2), PUT |
|              | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1),    |
|              | ma]).                        | PATCH (Section      |
|              |                              | 3.3.2)              |
| invalidVers  | The specified API version is | GET (Section        |
|              | not supported (see Section   | 3.2.2), POST (ALL), |
|              | 3.11).                       | PUT (Section        |
|              |                              | 3.3.1), PATCH       |
|              |                              | (Section 3.3.2),    |
|              |                              | DELETE (Section     |
|              |                              | 3.4)                |
+--------------+------------------------------+---------------------+
I plan to put these into draft 07 of the API and will publish = over the weekend.

As always, feedback = welcome!

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

= --Apple-Mail=_FD916F0F-DDA7-4C8B-9412-5A3337A84872-- From nobody Wed Jul 2 11:15:42 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B7A1B2852 for ; Wed, 2 Jul 2014 11:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5xli6eZ3Gq8 for ; Wed, 2 Jul 2014 11:15:37 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0188.outbound.protection.outlook.com [207.46.163.188]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A8A81B2A01 for ; Wed, 2 Jul 2014 11:15:32 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) with Microsoft SMTP Server (TLS) id 15.0.980.8; Wed, 2 Jul 2014 18:15:29 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.122]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.122]) with mapi id 15.00.0974.002; Wed, 2 Jul 2014 18:15:29 +0000 From: Kelly Grizzle To: Phil Hunt , Scim WG Thread-Topic: [scim] Proposed Detail Errors Thread-Index: AQHPkjhB1v2CfJQHskiODjem+S8OQ5uNHegAgAAArWA= Date: Wed, 2 Jul 2014 18:15:28 +0000 Message-ID: References: <348F75D5-7C0F-4B93-A7B7-88E0B2FFD4ED@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 012226D70078AC01222824 x-originating-ip: [2605:6000:0:8::f:9] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0260457E99 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(199002)(189002)(24454002)(85306003)(54356999)(81342001)(80022001)(99286002)(76576001)(95666004)(105586002)(99396002)(76176999)(50986999)(46102001)(64706001)(20776003)(16601075003)(81542001)(86362001)(19625215002)(92566001)(19580405001)(85852003)(19580395003)(87936001)(83322001)(2656002)(19609705001)(15975445006)(83072002)(15202345003)(101416001)(19300405004)(4396001)(107886001)(76482001)(106356001)(21056001)(74316001)(77096002)(31966008)(79102001)(74662001)(16236675004)(107046002)(106116001)(74502001)(77982001)(33646001)(108616002)(3826002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_e700365c0c354acf82e91ea73232c91eBN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/sk67WMareq-Dgq51Gkj1I1Q8KRI Subject: Re: [scim] Proposed Detail Errors X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 18:15:39 -0000 --_000_e700365c0c354acf82e91ea73232c91eBN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable How about maxResultsExceeded so it will match up with the filter.maxResults= attribute in ServiceProviderConfig? From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Wednesday, July 02, 2014 1:12 PM To: Scim WG Subject: Re: [scim] Proposed Detail Errors One item missed. Reviewing ticket 37, I see I missed the case where the filter specified yie= lds too many matches. I will add a code "tooMany" to describe this condition. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jun 27, 2014, at 11:47 AM, Phil Hunt > wrote: After reviewing the API and Schema docs, here is a first cut of the detaile= d error codes. For HTTP Status 400 (Bad Request) responses, the following detail error types are defined: +--------------+------------------------------+---------------------+ | scimType | Description | Applicability | +--------------+------------------------------+---------------------+ | invalidFilte | The specified filter syntax | GET(Section 3.2.2), | | r | was invalid (does not comply | POST (Search - | | | with Figure 1) or the | Section 3.2.3), | | | specified attribute and | PATCH (Path Filter | | | filter comparison | - Section 3.3.2) | | | combination is not | | | | supported. | | | uniqueness | One or more of attribute | POST (Create - | | | values is already in use or | Section 3.1), PUT | | | is reserved. | (Section 3.3.1), | | | | PATCH (Section | | | | 3.3.2) | | mutability | The attempted modification | PUT (Section | | | is not compatible with the | 3.3.1), PATCH | | | target attributes mutability | (Section 3.3.2) | | | or current state (e.g. | | | | modification of an immutable | | | | attribute with an existing | | | | value). | | | invalidSynta | The request body message | POST (Search - | | x | structure was invalid or did | Section 3.2.2, | | | not conform to the request | Create - Section | | | schema. | 3.1, Bulk - Section | | | | 3.5), PUT (Section | | | | 3.3.1) | | invalidPath | The path attribute was | PATCH (Section | | | invalid or malformed (see | 3.3.2) | | | Figure 4). | | | noTarget | The specified "path" did not | PATCH (Section | | | yield an attribute or | 3.3.2) | | | attribute value that could | | | | be operated on. This occurs | | | | when the specified "path" | | | | value contains a filter that | | | | yields no match. | | | invalidValue | A required value was | GET (Section | | | missing, or the value | 3.2.2), POST | | | specified was not compatible | (Create - Section | | | with the operation or | 3.1, Search - | | | attribute type (see Section | Section 3.2.2), PUT | | | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1), | | | ma]). | PATCH (Section | | | | 3.3.2) | | invalidVers | The specified API version is | GET (Section | | | not supported (see Section | 3.2.2), POST (ALL), | | | 3.11). | PUT (Section | | | | 3.3.1), PATCH | | | | (Section 3.3.2), | | | | DELETE (Section | | | | 3.4) | +--------------+------------------------------+---------------------+ I plan to put these into draft 07 of the API and will publish over the week= end. As always, feedback welcome! Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_e700365c0c354acf82e91ea73232c91eBN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

How about maxResultsExcee= ded so it will match up with the filter.maxResults attribute in ServiceProv= iderConfig?

 <= /p>

 <= /p>

From: scim [ma= ilto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, July 02, 2014 1:12 PM
To: Scim WG
Subject: Re: [scim] Proposed Detail Errors

 

One item missed.

 

Reviewing ticket 37, I see I missed the case where t= he filter specified yields too many matches.

 

I will add a code “tooMany” to describe = this condition.

 

Phil

 

@independentid<= /span>

ph= il.hunt@oracle.com

 

 

 

On Jun 27, 2014, at 11:47 AM, Phil Hunt <phil.hunt@oracle.com> wrote:



After reviewing the API and Schema docs, here is a f= irst cut of the detailed error codes.

 

For HTTP Status 4=
00 (Bad Request) responses, the following detail
   error types are defined:
 
+--------------+------------------------------+-----------=
----------+
| scimType     | Description   &nbs=
p;            &=
nbsp; | Applicability       |

+--------------+------------------------------+-----------=
----------+


| invalidFilte | The specified filter syntax  | GET(Section 3.2.2=
), |


| r            =
| was invalid (does not comply | POST (Search -    &nbs=
p; |


|           &nb=
sp;  | with Figure 1) or the       =
 | Section 3.2.3),     |


|           &nb=
sp;  | specified attribute and      | PATCH (=
Path Filter  |


|           &nb=
sp;  | filter comparison       &nbs=
p;    | - Section 3.3.2)    |

|           &nb=
sp;  | combination is not       &nb=
sp;   |         &nbs=
p;           |=



|           &nb=
sp;  | supported.         =
;          |   =
            &nb=
sp;     |


| uniqueness   | One or more of attribute    =
 | POST (Create -      |


|           &nb=
sp;  | values is already in use or  | Section 3.1), PUT &nbs=
p; |


|           &nb=
sp;  | is reserved.        &nb=
sp;        | (Section 3.3.1),  =
;  |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | PATCH (Section    =
;  |


|           &nb=
sp;  |           &nb=
sp;            =
      | 3.3.2)     &=
nbsp;        |


| mutability   | The attempted modification   | PU=
T (Section        |


|           &nb=
sp;  | is not compatible with the   | 3.3.1), PATCH &nb=
sp;     |


|           &nb=
sp;  | target attributes mutability | (Section 3.3.2)   &nbs=
p; |


|           &nb=
sp;  | or current state (e.g.       |&nb=
sp;            =
        |


|           &nb=
sp;  | modification of an immutable |     &nb=
sp;            =
   |


|           &nb=
sp;  | attribute with an existing   |    =
;            &n=
bsp;    |


|           &nb=
sp;  | value).         &n=
bsp;            |&nb=
sp;            =
        |


| invalidSynta | The request body message     | PO=
ST (Search -      |


| x            =
| structure was invalid or did | Section 3.2.2,    &nbs=
p; |


|           &nb=
sp;  | not conform to the request   | Create - Section =
   |


|           &nb=
sp;  | schema.         &n=
bsp;            | 3.=
1, Bulk - Section |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | 3.5), PUT (Section  |=



|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | 3.3.1)     &=
nbsp;        |


| invalidPath  | The path attribute was    &n=
bsp;  | PATCH (Section      |

|           &nb=
sp;  | invalid or malformed (see    | 3.3.2)  =
;            |<=
/o:p>


|           &nb=
sp;  | Figure 4).         =
;          |   =
            &nb=
sp;     |


| noTarget     | The specified "path" di=
d not | PATCH (Section      |


|           &nb=
sp;  | yield an attribute or       =
 | 3.3.2)           =
   |


|           &nb=
sp;  | attribute value that could   |    =
;            &n=
bsp;    |


|           &nb=
sp;  | be operated on. This occurs  |    &nbs=
p;            &=
nbsp;   |


|           &nb=
sp;  | when the specified "path"    | &n=
bsp;            =
;       |


|            &n=
bsp; | value contains a filter that |     &nb=
sp;            =
   |


|           &nb=
sp;  | yields no match.        =
;     |        =
             |<=
o:p>


| invalidValue | A required value was     &nb=
sp;   | GET (Section        |<=
o:p>


|           &nb=
sp;  | missing, or the value       =
 | 3.2.2), POST        |

|           &nb=
sp;  | specified was not compatible | (Create - Section   |<=
o:p>


|           &nb=
sp;  | with the operation or       =
 | 3.1, Search -       |


|           &nb=
sp;  | attribute type (see Section  | Section 3.2.2), PUT |<=
/o:p>


|           &nb=
sp;  | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1),  &nbs=
p; |


|           &nb=
sp;  | ma]).         &nbs=
p;            &=
nbsp; | PATCH (Section      |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | 3.3.2)     &=
nbsp;        |


| invalidVers  | The specified API version is | GET (Section =
;       |


|            &n=
bsp; | not supported (see Section   | 3.2.2), POST (ALL), |<=
o:p>


|           &nb=
sp;  | 3.11).         &nb=
sp;            =
 | PUT (Section        |

|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | 3.3.1), PATCH    =
   |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | (Section 3.3.2),    |<=
o:p>


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | DELETE (Section   &nbs=
p; |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | 3.4)     &nb=
sp;          |

+--------------+------------------------------+-----------=
----------+




I plan to put these into draft 07 of the API and wil=
l publish over the weekend.






 






As always, feedback welcome!






 





















 
















 




 

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

 

--_000_e700365c0c354acf82e91ea73232c91eBN1PR04MB392namprd04pro_-- From nobody Wed Jul 2 11:44:52 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C271A03C3 for ; Wed, 2 Jul 2014 11:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.25 X-Spam-Level: X-Spam-Status: No, score=-6.25 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjEz6xux1Yqe for ; Wed, 2 Jul 2014 11:44:46 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89ED31A0395 for ; Wed, 2 Jul 2014 11:44:46 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s62IijHK015459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Jul 2014 18:44:45 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s62Iii3s023610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jul 2014 18:44:45 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s62Iii3h027525; Wed, 2 Jul 2014 18:44:44 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 Jul 2014 11:44:43 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_943003FD-E0AC-4350-86EC-13FBD91BC8CC" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Phil Hunt In-Reply-To: Date: Wed, 2 Jul 2014 11:44:42 -0700 Message-Id: <1AE6DE7A-26EC-4EB8-A96A-A153B83DA746@oracle.com> References: <348F75D5-7C0F-4B93-A7B7-88E0B2FFD4ED@oracle.com> To: Kelly Grizzle X-Mailer: Apple Mail (2.1878.2) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Wr0vylnDeLzJbk2x276jK5O0nlc Cc: Scim WG Subject: Re: [scim] Proposed Detail Errors X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 18:44:49 -0000 --Apple-Mail=_943003FD-E0AC-4350-86EC-13FBD91BC8CC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 It could be tied to that number. However, I didn=92t want to assume that max number of matches was = limited to maxResults. You could have a 1000 matches but limit returns = to 100 at a time. In other cases, the server may return the error immediately without = actually doing much calculation since it has determined the filter is = just too small. For example, in a search-as-you-type scenario, having a = couple of letters, may just be ignored. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 2, 2014, at 11:15 AM, Kelly Grizzle = wrote: > How about maxResultsExceeded so it will match up with the = filter.maxResults attribute in ServiceProviderConfig? > =20 > =20 > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Wednesday, July 02, 2014 1:12 PM > To: Scim WG > Subject: Re: [scim] Proposed Detail Errors > =20 > One item missed. > =20 > Reviewing ticket 37, I see I missed the case where the filter = specified yields too many matches. > =20 > I will add a code =93tooMany=94 to describe this condition. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 > On Jun 27, 2014, at 11:47 AM, Phil Hunt wrote: >=20 >=20 > After reviewing the API and Schema docs, here is a first cut of the = detailed error codes. > =20 > For HTTP Status 400 (Bad Request) responses, the following detail > error types are defined: > =20 > +--------------+------------------------------+---------------------+ > | scimType | Description | Applicability | > +--------------+------------------------------+---------------------+ > | invalidFilte | The specified filter syntax | GET(Section 3.2.2), | > | r | was invalid (does not comply | POST (Search - | > | | with Figure 1) or the | Section 3.2.3), | > | | specified attribute and | PATCH (Path Filter | > | | filter comparison | - Section 3.3.2) | > | | combination is not | | > | | supported. | | > | uniqueness | One or more of attribute | POST (Create - | > | | values is already in use or | Section 3.1), PUT | > | | is reserved. | (Section 3.3.1), | > | | | PATCH (Section | > | | | 3.3.2) | > | mutability | The attempted modification | PUT (Section | > | | is not compatible with the | 3.3.1), PATCH | > | | target attributes mutability | (Section 3.3.2) | > | | or current state (e.g. | | > | | modification of an immutable | | > | | attribute with an existing | | > | | value). | | > | invalidSynta | The request body message | POST (Search - | > | x | structure was invalid or did | Section 3.2.2, | > | | not conform to the request | Create - Section | > | | schema. | 3.1, Bulk - Section | > | | | 3.5), PUT (Section | > | | | 3.3.1) | > | invalidPath | The path attribute was | PATCH (Section | > | | invalid or malformed (see | 3.3.2) | > | | Figure 4). | | > | noTarget | The specified "path" did not | PATCH (Section | > | | yield an attribute or | 3.3.2) | > | | attribute value that could | | > | | be operated on. This occurs | | > | | when the specified "path" | | > | | value contains a filter that | | > | | yields no match. | | > | invalidValue | A required value was | GET (Section | > | | missing, or the value | 3.2.2), POST | > | | specified was not compatible | (Create - Section | > | | with the operation or | 3.1, Search - | > | | attribute type (see Section | Section 3.2.2), PUT | > | | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1), | > | | ma]). | PATCH (Section | > | | | 3.3.2) | > | invalidVers | The specified API version is | GET (Section | > | | not supported (see Section | 3.2.2), POST (ALL), | > | | 3.11). | PUT (Section | > | | | 3.3.1), PATCH | > | | | (Section 3.3.2), | > | | | DELETE (Section | > | | | 3.4) | > +--------------+------------------------------+---------------------+ > I plan to put these into draft 07 of the API and will publish over the = weekend. > =20 > As always, feedback welcome! > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_943003FD-E0AC-4350-86EC-13FBD91BC8CC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
It could be tied to that = number.

However, I didn=92t want to assume that = max number of matches was limited to maxResults.  You could have a = 1000 matches but limit returns to 100 at a = time.

In other cases, the server may return the = error immediately without actually doing much calculation since it has = determined the filter is just too small. For example, in a = search-as-you-type scenario, having a couple of letters, may just be = ignored.

=

On Jul 2, 2014, at 11:15 AM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

How about maxResultsExceeded so it will match up = with the filter.maxResults attribute in = ServiceProviderConfig?

 

 

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, July 02, 2014 1:12 PM
To: Scim WG
Subject: Re: [scim] Proposed Detail Errors

 

One item missed.

 

Reviewing ticket 37, I see I missed the case = where the filter specified yields too many matches.

 

I will add a code =93tooMany=94 to describe = this condition.

 

 

 

 

On Jun 27, 2014, at 11:47 AM, Phil Hunt = <phil.hunt@oracle.com> = wrote:



After reviewing the API and Schema docs, = here is a first cut of the detailed error codes.

 

For HTTP =
Status 400 (Bad Request) responses, the following =
detail
   error types are defined:
 
= 
+--------------+------------------------------+---------------------+=

| scimType     | =
Description          &nb=
sp;       | =
Applicability       |
= 
+--------------+------------------------------+---------------------+=

| invalidFilte | The specified filter syntax  | GET(Section =
3.2.2), |
| =
r            | =
was invalid (does not comply | POST (Search =
-      |
= 
|           &n=
bsp;  | with Figure 1) or =
the        | Section =
3.2.3),     |
= 
|           &n=
bsp;  | specified attribute and      | =
PATCH (Path Filter  |
= 
|           &n=
bsp;  | filter =
comparison          &nbs=
p; | - Section 3.3.2)    |
= 
|           &n=
bsp;  | combination is =
not           =
|            &=
nbsp;        |
= 
|           &n=
bsp;  | =
supported.          &nbs=
p;        =
|            &=
nbsp;        |
| uniqueness   | One or more of attribute =
    | POST (Create -      =
|
= 
|           &n=
bsp;  | values is already in use or  | Section 3.1), =
PUT   |
= 
|           &n=
bsp;  | is =
reserved.           =
;      | (Section 3.3.1),    =
|
= 
|           &n=
bsp;  =
|            &=
nbsp;           &nb=
sp;     | PATCH =
(Section      |
= 
|           &n=
bsp;  |  =
            &n=
bsp;           &nbs=
p;   | =
3.3.2)           &n=
bsp;  |
| mutability   | The attempted modification   | =
PUT (Section        =
|
= 
|           &n=
bsp;  | is not compatible with the   | 3.3.1), =
PATCH       |
= 
|           &n=
bsp;  | target attributes mutability | (Section 3.3.2) =
    |
= 
|           &n=
bsp;  | or current state (e.g.       =
|            &=
nbsp;        |
= 
|           &n=
bsp;  | modification of an immutable =
|            &=
nbsp;        |
= 
|           &n=
bsp;  | attribute with an existing   =
|            &=
nbsp;        |
= 
|           &n=
bsp;  | =
value).           &=
nbsp;    =
      |      &=
nbsp;           &nb=
sp;  |
| invalidSynta | The request body message     | =
POST (Search -      |
| =
x            | =
structure was invalid or did | Section =
3.2.2,      |
= 
|           &n=
bsp;  | not conform to the request   | Create - =
Section    |
= 
|           &n=
bsp;  | =
schema.           &=
nbsp;          | 3.1, Bulk =
- Section |
= 
|           &n=
bsp;  =
|            &=
nbsp;           &nb=
sp;     | 3.5), PUT (Section  =
|
= 
|           &n=
bsp;  =
|            &=
nbsp;           &nb=
sp;     | =
3.3.1)           &n=
bsp;  |
| invalidPath  | The path attribute =
was       | PATCH =
(Section      |
= 
|           &n=
bsp;  | invalid or malformed (see    | =
3.3.2)           &n=
bsp;  |
= 
|           &n=
bsp;  | Figure =
4).            =
;       =
|            &=
nbsp;        |
| noTarget     | The specified "path" did not | =
PATCH (Section      |
= 
|           &n=
bsp;  | yield an attribute =
or        | =
3.3.2)           &n=
bsp;  |
= 
|           &n=
bsp;  | attribute value that could   =
|            &=
nbsp;        |
= 
|           &n=
bsp;  | be operated on. This occurs  =
|            &=
nbsp;        |
= 
|           &n=
bsp;  | when the specified "path"    =
|            &=
nbsp;        |
|            =
  | value contains a filter that =
|            &=
nbsp;        |
= 
|           &n=
bsp;  | yields no =
match.           &n=
bsp; =
|            &=
nbsp;        |
| invalidValue | A required value =
was         | GET =
(Section        |
= 
|           &n=
bsp;  | missing, or the =
value        | 3.2.2), =
POST        |
= 
|           &n=
bsp;  | specified was not compatible | (Create - =
Section   |
= 
|           &n=
bsp;  | with the operation =
or        | 3.1, Search =
-       |
= 
|           &n=
bsp;  | attribute type (see Section  | Section 3.2.2), PUT =
|
= 
|           &n=
bsp;  | 2.1 [I-D.ietf-scim-core-sche | (Section =
3.3.1),    |
= 
|           &n=
bsp;  | =
ma]).           &nb=
sp;            | =
PATCH (Section      |
= 
|           &n=
bsp;  =
|            &=
nbsp;           &nb=
sp;     | =
3.3.2)           &n=
bsp;  |
| invalidVers  | The specified API version is | GET =
(Section        |
|          =
    | not supported (see Section   | =
3.2.2), POST (ALL), |
= 
|           &n=
bsp;  | =
3.11).           &n=
bsp;           | PUT =
(Section        |
= 
|           &n=
bsp;  =
|            &=
nbsp;           &nb=
sp;     | 3.3.1), =
PATCH       |
= 
|           &n=
bsp;  =
|            &=
nbsp;           &nb=
sp;     | (Section 3.3.2),    =
|
= 
|           &n=
bsp;  =
|            &=
nbsp;           &nb=
sp;     | DELETE (Section     =
|
= 
|           &n=
bsp;  =
|            &=
nbsp;           &nb=
sp;     | =
3.4)           &nbs=
p;    |
= 
+--------------+------------------------------+---------------------+=

I plan to put these into draft 07 of the API = and will publish over the weekend.

 

As always, feedback welcome!

 

 <= /span>

 

 

_______________________________________________
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=_943003FD-E0AC-4350-86EC-13FBD91BC8CC-- From nobody Wed Jul 2 14:42:28 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD791A07A1 for ; Wed, 2 Jul 2014 14:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-igFlf4D9TZ for ; Wed, 2 Jul 2014 14:42:22 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0142.outbound.protection.outlook.com [207.46.163.142]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DFEA1B2AC2 for ; Wed, 2 Jul 2014 14:42:22 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) with Microsoft SMTP Server (TLS) id 15.0.980.8; Wed, 2 Jul 2014 21:42:19 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.122]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.122]) with mapi id 15.00.0974.002; Wed, 2 Jul 2014 21:42:19 +0000 From: Kelly Grizzle To: Phil Hunt Thread-Topic: [scim] Proposed Detail Errors Thread-Index: AQHPkjhB1v2CfJQHskiODjem+S8OQ5uNHegAgAAArWCAAAhZAIAAMW4A Date: Wed, 2 Jul 2014 21:42:18 +0000 Message-ID: References: <348F75D5-7C0F-4B93-A7B7-88E0B2FFD4ED@oracle.com> <1AE6DE7A-26EC-4EB8-A96A-A153B83DA746@oracle.com> In-Reply-To: <1AE6DE7A-26EC-4EB8-A96A-A153B83DA746@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 01DF742F0078AC01DF757C x-originating-ip: [2605:6000:0:8::f:9] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0260457E99 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(199002)(189002)(24454002)(85306003)(105586002)(54356999)(76576001)(95666004)(81342001)(99286002)(80022001)(76176999)(99396002)(46102001)(50986999)(20776003)(64706001)(16601075003)(81542001)(86362001)(92566001)(19625215002)(93886003)(19580395003)(19580405001)(85852003)(87936001)(83322001)(2656002)(19609705001)(15975445006)(83072002)(15202345003)(101416001)(19300405004)(4396001)(21056001)(106356001)(76482001)(74316001)(77096002)(31966008)(107046002)(79102001)(74662001)(16236675004)(106116001)(74502001)(77982001)(33646001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_f8833124687d4e3596c31bf513bf24a1BN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/aqjG6TGWyHl4yj73Rr_8VcO7JQw Cc: Scim WG Subject: Re: [scim] Proposed Detail Errors X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 21:42:26 -0000 --_000_f8833124687d4e3596c31bf513bf24a1BN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not sure that I understand what you're saying. Are you saying that in = some cases a server might return an exception and other times it might just= not return any results or a limited result set? From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Wednesday, July 02, 2014 1:45 PM To: Kelly Grizzle Cc: Scim WG Subject: Re: [scim] Proposed Detail Errors It could be tied to that number. However, I didn't want to assume that max number of matches was limited to = maxResults. You could have a 1000 matches but limit returns to 100 at a ti= me. In other cases, the server may return the error immediately without actuall= y doing much calculation since it has determined the filter is just too sma= ll. For example, in a search-as-you-type scenario, having a couple of lette= rs, may just be ignored. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 2, 2014, at 11:15 AM, Kelly Grizzle > wrote: How about maxResultsExceeded so it will match up with the filter.maxResults= attribute in ServiceProviderConfig? From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Wednesday, July 02, 2014 1:12 PM To: Scim WG Subject: Re: [scim] Proposed Detail Errors One item missed. Reviewing ticket 37, I see I missed the case where the filter specified yie= lds too many matches. I will add a code "tooMany" to describe this condition. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jun 27, 2014, at 11:47 AM, Phil Hunt > wrote: After reviewing the API and Schema docs, here is a first cut of the detaile= d error codes. For HTTP Status 400 (Bad Request) responses, the following detail error types are defined: +--------------+------------------------------+---------------------+ | scimType | Description | Applicability | +--------------+------------------------------+---------------------+ | invalidFilte | The specified filter syntax | GET(Section 3.2.2), | | r | was invalid (does not comply | POST (Search - | | | with Figure 1) or the | Section 3.2.3), | | | specified attribute and | PATCH (Path Filter | | | filter comparison | - Section 3.3.2) | | | combination is not | | | | supported. | | | uniqueness | One or more of attribute | POST (Create - | | | values is already in use or | Section 3.1), PUT | | | is reserved. | (Section 3.3.1), | | | | PATCH (Section | | | | 3.3.2) | | mutability | The attempted modification | PUT (Section | | | is not compatible with the | 3.3.1), PATCH | | | target attributes mutability | (Section 3.3.2) | | | or current state (e.g. | | | | modification of an immutable | | | | attribute with an existing | | | | value). | | | invalidSynta | The request body message | POST (Search - | | x | structure was invalid or did | Section 3.2.2, | | | not conform to the request | Create - Section | | | schema. | 3.1, Bulk - Section | | | | 3.5), PUT (Section | | | | 3.3.1) | | invalidPath | The path attribute was | PATCH (Section | | | invalid or malformed (see | 3.3.2) | | | Figure 4). | | | noTarget | The specified "path" did not | PATCH (Section | | | yield an attribute or | 3.3.2) | | | attribute value that could | | | | be operated on. This occurs | | | | when the specified "path" | | | | value contains a filter that | | | | yields no match. | | | invalidValue | A required value was | GET (Section | | | missing, or the value | 3.2.2), POST | | | specified was not compatible | (Create - Section | | | with the operation or | 3.1, Search - | | | attribute type (see Section | Section 3.2.2), PUT | | | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1), | | | ma]). | PATCH (Section | | | | 3.3.2) | | invalidVers | The specified API version is | GET (Section | | | not supported (see Section | 3.2.2), POST (ALL), | | | 3.11). | PUT (Section | | | | 3.3.1), PATCH | | | | (Section 3.3.2), | | | | DELETE (Section | | | | 3.4) | +--------------+------------------------------+---------------------+ I plan to put these into draft 07 of the API and will publish over the week= end. As always, feedback welcome! 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 --_000_f8833124687d4e3596c31bf513bf24a1BN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m not sure that I= understand what you’re saying.  Are you saying that in some cas= es a server might return an exception and other times it might just not ret= urn any results or a limited result set?

 <= /p>

From: Phil Hun= t [mailto:phil.hunt@oracle.com]
Sent: Wednesday, July 02, 2014 1:45 PM
To: Kelly Grizzle
Cc: Scim WG
Subject: Re: [scim] Proposed Detail Errors

 

It could be tied to that number.

 

However, I didn’t want to assume that max numb= er of matches was limited to maxResults.  You could have a 1000 matche= s but limit returns to 100 at a time.

 

In other cases, the server may return the error imme= diately without actually doing much calculation since it has determined the= filter is just too small. For example, in a search-as-you-type scenario, h= aving a couple of letters, may just be ignored.

 

Phil

 

@independentid<= /span>

ph= il.hunt@oracle.com

 

 

 

On Jul 2, 2014, at 11:15 AM, Kelly Grizzle <kelly.grizzle@sailpoint.com&g= t; wrote:



How about maxResultsExcee= ded so it will match up with the filter.maxResults attribute in ServiceProv= iderConfig?

 <= /p>

 <= /p>

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, July 02, 2014 1:12 PM
To: Scim WG
Subject: Re: [scim] Proposed Detail Errors

 

One item missed.

 

Reviewing ticket 37, I see I missed the case where t= he filter specified yields too many matches.

 

I will add a code “tooMany” to describe = this condition.

 

 

 

 

On Jun 27, 2014, at 11:47 AM, Phil Hunt <phil.hunt@oracle.com> wrote:




After reviewing the API and Schema docs, here is a f= irst cut of the detailed error codes.

 

For HTTP Status 4=
00 (Bad Request) responses, the following detail
   error types are defined:
 
+--------------+------------------------------+-----------=
----------+
| scimType     | Description   &nbs=
p;            &=
nbsp; | Applicability       |

+--------------+------------------------------+-----------=
----------+


| invalidFilte | The specified filter syntax  | GET(Section 3.2.2=
), |


| r            =
| was invalid (does not comply | POST (Search -    &nbs=
p; |


|           &nb=
sp;  | with Figure 1) or the       =
 | Section 3.2.3),     |


|           &nb=
sp;  | specified attribute and      | PATCH (=
Path Filter  |


|           &nb=
sp;  | filter comparison       &nbs=
p;    | - Section 3.3.2)    |

|           &nb=
sp;  | combination is not       &nb=
sp;   |         &nbs=
p;           |=



|           &nb=
sp;  | supported.         =
;          |   =
            &nb=
sp;     |


| uniqueness   | One or more of attribute    =
 | POST (Create -      |


|           &nb=
sp;  | values is already in use or  | Section 3.1), PUT &nbs=
p; |


|           &nb=
sp;  | is reserved.        &nb=
sp;        | (Section 3.3.1),  =
;  |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | PATCH (Section    =
;  |


|           &nb=
sp;  |           &nb=
sp;            =
      | 3.3.2)     &=
nbsp;        |


| mutability   | The attempted modification   | PU=
T (Section        |


|           &nb=
sp;  | is not compatible with the   | 3.3.1), PATCH &nb=
sp;     |


|           &nb=
sp;  | target attributes mutability | (Section 3.3.2)   &nbs=
p; |


|           &nb=
sp;  | or current state (e.g.       |&nb=
sp;            =
        |


|           &nb=
sp;  | modification of an immutable |     &nb=
sp;            =
   |


|           &nb=
sp;  | attribute with an existing   |    =
;            &n=
bsp;    |


|           &nb=
sp;  | value).         &n=
bsp;            |&nb=
sp;            =
        |


| invalidSynta | The request body message     | PO=
ST (Search -      |


| x            =
| structure was invalid or did | Section 3.2.2,    &nbs=
p; |


|           &nb=
sp;  | not conform to the request   | Create - Section =
   |


|           &nb=
sp;  | schema.         &n=
bsp;            | 3.=
1, Bulk - Section |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | 3.5), PUT (Section  |=



|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | 3.3.1)     &=
nbsp;        |


| invalidPath  | The path attribute was    &n=
bsp;  | PATCH (Section      |

|           &nb=
sp;  | invalid or malformed (see    | 3.3.2)  =
;            |<=
/o:p>


|           &nb=
sp;  | Figure 4).         =
;          |   =
            &nb=
sp;     |


| noTarget     | The specified "path" di=
d not | PATCH (Section      |


|           &nb=
sp;  | yield an attribute or       =
 | 3.3.2)           =
   |


|           &nb=
sp;  | attribute value that could   |    =
;            &n=
bsp;    |


|           &nb=
sp;  | be operated on. This occurs  |    &nbs=
p;            &=
nbsp;   |


|           &nb=
sp;  | when the specified "path"    | &n=
bsp;            =
;       |


|            &n=
bsp; | value contains a filter that |     &nb=
sp;            =
   |


|           &nb=
sp;  | yields no match.        =
;     |        =
             |<=
o:p>


| invalidValue | A required value was     &nb=
sp;   | GET (Section        |<=
o:p>


|           &nb=
sp;  | missing, or the value       =
 | 3.2.2), POST        |

|           &nb=
sp;  | specified was not compatible | (Create - Section   |<=
o:p>


|           &nb=
sp;  | with the operation or       =
 | 3.1, Search -       |


|           &nb=
sp;  | attribute type (see Section  | Section 3.2.2), PUT |<=
/o:p>


|           &nb=
sp;  | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1),  &nbs=
p; |


|           &nb=
sp;  | ma]).         &nbs=
p;            &=
nbsp; | PATCH (Section      |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | 3.3.2)     &=
nbsp;        |


| invalidVers  | The specified API version is | GET (Section =
;       |


|            &n=
bsp; | not supported (see Section   | 3.2.2), POST (ALL), |<=
o:p>


|           &nb=
sp;  | 3.11).         &nb=
sp;            =
 | PUT (Section        |

|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | 3.3.1), PATCH    =
   |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | (Section 3.3.2),    |<=
o:p>


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | DELETE (Section   &nbs=
p; |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | 3.4)     &nb=
sp;          |

+--------------+------------------------------+-----------=
----------+




I plan to put these into draft 07 of the API and wil=
l publish over the weekend.






 






As always, feedback welcome!






 





















 
















 




 

_______________________________________________
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_f8833124687d4e3596c31bf513bf24a1BN1PR04MB392namprd04pro_-- From nobody Wed Jul 2 15:18:48 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B99D1B2AF8 for ; Wed, 2 Jul 2014 15:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.25 X-Spam-Level: X-Spam-Status: No, score=-6.25 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvLq39YRXTKJ for ; Wed, 2 Jul 2014 15:18:41 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 848931B2AEE for ; Wed, 2 Jul 2014 15:18:41 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s62MIeUi026984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Jul 2014 22:18:40 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s62MIcIu018302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Jul 2014 22:18:39 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s62MIcUM011412; Wed, 2 Jul 2014 22:18:38 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 Jul 2014 15:18:37 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_3E6A55FF-AA96-4499-8054-4B2C66FB8103" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Phil Hunt In-Reply-To: Date: Wed, 2 Jul 2014 15:18:36 -0700 Message-Id: <30989016-CC29-4EDF-B736-F751FFEEDABD@oracle.com> References: <348F75D5-7C0F-4B93-A7B7-88E0B2FFD4ED@oracle.com> <1AE6DE7A-26EC-4EB8-A96A-A153B83DA746@oracle.com> To: Kelly Grizzle X-Mailer: Apple Mail (2.1878.2) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/QbKSMcURIyVzzwoCfAhgfrqYlxw Cc: Scim WG Subject: Re: [scim] Proposed Detail Errors X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 22:18:47 -0000 --Apple-Mail=_3E6A55FF-AA96-4499-8054-4B2C66FB8103 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 There server might decide not to process the request at all as it would = return too many results (the amount undefined). Example bad request: GET /Users?filter=3DuseName eq =93*=94&sortby=3Dname This would essentially cause the server to do an incredible amount of = work only to dump 99.9% of it to return a relatively small maxResults = set of results. in this case, the filter syntax is valid, but the server is simply not = willing to do the query. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 2, 2014, at 2:42 PM, Kelly Grizzle = wrote: > I=92m not sure that I understand what you=92re saying. Are you saying = that in some cases a server might return an exception and other times it = might just not return any results or a limited result set? > =20 > From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Wednesday, July 02, 2014 1:45 PM > To: Kelly Grizzle > Cc: Scim WG > Subject: Re: [scim] Proposed Detail Errors > =20 > It could be tied to that number. > =20 > However, I didn=92t want to assume that max number of matches was = limited to maxResults. You could have a 1000 matches but limit returns = to 100 at a time. > =20 > In other cases, the server may return the error immediately without = actually doing much calculation since it has determined the filter is = just too small. For example, in a search-as-you-type scenario, having a = couple of letters, may just be ignored. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 > On Jul 2, 2014, at 11:15 AM, Kelly Grizzle = wrote: >=20 >=20 > How about maxResultsExceeded so it will match up with the = filter.maxResults attribute in ServiceProviderConfig? > =20 > =20 > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Wednesday, July 02, 2014 1:12 PM > To: Scim WG > Subject: Re: [scim] Proposed Detail Errors > =20 > One item missed. > =20 > Reviewing ticket 37, I see I missed the case where the filter = specified yields too many matches. > =20 > I will add a code =93tooMany=94 to describe this condition. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 > On Jun 27, 2014, at 11:47 AM, Phil Hunt wrote: >=20 >=20 >=20 > After reviewing the API and Schema docs, here is a first cut of the = detailed error codes. > =20 > For HTTP Status 400 (Bad Request) responses, the following detail > error types are defined: > =20 > +--------------+------------------------------+---------------------+ > | scimType | Description | Applicability | > +--------------+------------------------------+---------------------+ > | invalidFilte | The specified filter syntax | GET(Section 3.2.2), | > | r | was invalid (does not comply | POST (Search - | > | | with Figure 1) or the | Section 3.2.3), | > | | specified attribute and | PATCH (Path Filter | > | | filter comparison | - Section 3.3.2) | > | | combination is not | | > | | supported. | | > | uniqueness | One or more of attribute | POST (Create - | > | | values is already in use or | Section 3.1), PUT | > | | is reserved. | (Section 3.3.1), | > | | | PATCH (Section | > | | | 3.3.2) | > | mutability | The attempted modification | PUT (Section | > | | is not compatible with the | 3.3.1), PATCH | > | | target attributes mutability | (Section 3.3.2) | > | | or current state (e.g. | | > | | modification of an immutable | | > | | attribute with an existing | | > | | value). | | > | invalidSynta | The request body message | POST (Search - | > | x | structure was invalid or did | Section 3.2.2, | > | | not conform to the request | Create - Section | > | | schema. | 3.1, Bulk - Section | > | | | 3.5), PUT (Section | > | | | 3.3.1) | > | invalidPath | The path attribute was | PATCH (Section | > | | invalid or malformed (see | 3.3.2) | > | | Figure 4). | | > | noTarget | The specified "path" did not | PATCH (Section | > | | yield an attribute or | 3.3.2) | > | | attribute value that could | | > | | be operated on. This occurs | | > | | when the specified "path" | | > | | value contains a filter that | | > | | yields no match. | | > | invalidValue | A required value was | GET (Section | > | | missing, or the value | 3.2.2), POST | > | | specified was not compatible | (Create - Section | > | | with the operation or | 3.1, Search - | > | | attribute type (see Section | Section 3.2.2), PUT | > | | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1), | > | | ma]). | PATCH (Section | > | | | 3.3.2) | > | invalidVers | The specified API version is | GET (Section | > | | not supported (see Section | 3.2.2), POST (ALL), | > | | 3.11). | PUT (Section | > | | | 3.3.1), PATCH | > | | | (Section 3.3.2), | > | | | DELETE (Section | > | | | 3.4) | > +--------------+------------------------------+---------------------+ > I plan to put these into draft 07 of the API and will publish over the = weekend. > =20 > As always, feedback welcome! > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_3E6A55FF-AA96-4499-8054-4B2C66FB8103 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 There = server might decide not to process the request at all as it would return = too many results (the amount undefined).   Example bad = request:

GET /Users?filter=3DuseName eq = =93*=94&sortby=3Dname

This would essentially = cause the server to do an incredible amount of work only to dump 99.9% = of it to return a relatively small maxResults set of = results.

in this case, the filter syntax is = valid, but the server is simply not willing to do the = query.


On Jul 2, 2014, at 2:42 PM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

I=92m not sure that I understand what you=92re = saying.  Are you saying that in some cases a server might return an = exception and other times it might just not return any results or a limited result set?

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Wednesday, July 02, 2014 1:45 PM
To: Kelly Grizzle
Cc: Scim WG
Subject: Re: [scim] Proposed Detail Errors

 

It could be tied to that = number.

 

However, I didn=92t want to assume that max = number of matches was limited to maxResults.  You could have a 1000 = matches but limit returns to 100 at a time.

 

In other cases, the server may return the = error immediately without actually doing much calculation since it has = determined the filter is just too small. For example, in a = search-as-you-type scenario, having a couple of letters, may just be ignored.

 

 

 

 

On Jul 2, 2014, at 11:15 AM, Kelly Grizzle = <kelly.grizzle@sailpoint.com> wrote:



How about maxResultsExceeded so it will match up = with the filter.maxResults attribute in = ServiceProviderConfig?

 

 

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, July 02, 2014 1:12 PM
To: Scim WG
Subject: Re: [scim] Proposed Detail Errors

 

One item missed.

 

Reviewing ticket 37, I see I missed the case = where the filter specified yields too many matches.

 

I will add a code =93tooMany=94 to describe = this condition.

 

Phil

 

@independentid

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

 <= /span>

 

 

On Jun 27, 2014, at 11:47 AM, Phil Hunt = <phil.hunt@oracle.com> = wrote:




After reviewing the API and Schema docs, = here is a first cut of the detailed error codes.

 

For HTTP =
Status 400 (Bad Request) responses, the following =
detail
   error types are defined:
 
= 
+--------------+------------------------------+---------------------+=

| scimType     | =
Description          &nb=
sp;       | =
Applicability       |
= 
+--------------+------------------------------+---------------------+=

| invalidFilte | The specified filter syntax  | GET(Section =
3.2.2), |
| =
r            | =
was invalid (does not comply | POST (Search =
-      |
= 
|           &n=
bsp;  | with Figure 1) or =
the        | Section =
3.2.3),     |
= 
|           &n=
bsp;  | specified attribute and      | =
PATCH (Path Filter  |
= 
|           &n=
bsp;  | filter =
comparison          &nbs=
p; | - Section 3.3.2)    |
= 
|           &n=
bsp;  | combination is =
not           =
|            &=
nbsp;        |
= 
|           &n=
bsp;  | =
supported.          &nbs=
p;        =
|            &=
nbsp;        |
| uniqueness   | One or more of attribute =
    | POST (Create -      =
|
= 
|           &n=
bsp;  | values is already in use or  | Section 3.1), =
PUT   |
= 
|           &n=
bsp;  | is =
reserved.           =
;      | (Section 3.3.1),    =
|
= 
|           &n=
bsp;  =
|            &=
nbsp;           &nb=
sp;     | PATCH =
(Section      |
= 
|           &n=
bsp;  |  =
            &n=
bsp;           &nbs=
p;   | =
3.3.2)           &n=
bsp;  |
| mutability   | The attempted modification   | =
PUT (Section        =
|
= 
|           &n=
bsp;  | is not compatible with the   | 3.3.1), =
PATCH       |
= 
|           &n=
bsp;  | target attributes mutability | (Section 3.3.2) =
    |
= 
|           &n=
bsp;  | or current state (e.g.       =
|            &=
nbsp;        |
= 
|           &n=
bsp;  | modification of an immutable =
|            &=
nbsp;        |
= 
|           &n=
bsp;  | attribute with an existing   =
|            &=
nbsp;        |
= 
|           &n=
bsp;  | =
value).           &=
nbsp;    =
      |      &=
nbsp;           &nb=
sp;  |
| invalidSynta | The request body message     | =
POST (Search -      |
| =
x            | =
structure was invalid or did | Section =
3.2.2,      |
= 
|           &n=
bsp;  | not conform to the request   | Create - =
Section    |
= 
|           &n=
bsp;  | =
schema.           &=
nbsp;          | 3.1, Bulk =
- Section |
= 
|           &n=
bsp;  =
|            &=
nbsp;           &nb=
sp;     | 3.5), PUT (Section  =
|
= 
|           &n=
bsp;  =
|            &=
nbsp;           &nb=
sp;     | =
3.3.1)           &n=
bsp;  |
| invalidPath  | The path attribute =
was       | PATCH =
(Section      |
= 
|           &n=
bsp;  | invalid or malformed (see    | =
3.3.2)           &n=
bsp;  |
= 
|           &n=
bsp;  | Figure =
4).            =
;       =
|            &=
nbsp;        |
| noTarget     | The specified "path" did not | =
PATCH (Section      |
= 
|           &n=
bsp;  | yield an attribute =
or        | =
3.3.2)           &n=
bsp;  |
= 
|           &n=
bsp;  | attribute value that could   =
|            &=
nbsp;        |
= 
|           &n=
bsp;  | be operated on. This occurs  =
|            &=
nbsp;        |
= 
|           &n=
bsp;  | when the specified "path"    =
|            &=
nbsp;        |
|            =
  | value contains a filter that =
|            &=
nbsp;        |
= 
|           &n=
bsp;  | yields no =
match.           &n=
bsp; =
|            &=
nbsp;        |
| invalidValue | A required value =
was         | GET =
(Section        |
= 
|           &n=
bsp;  | missing, or the =
value        | 3.2.2), =
POST        |
= 
|           &n=
bsp;  | specified was not compatible | (Create - =
Section   |
= 
|           &n=
bsp;  | with the operation =
or        | 3.1, Search =
-       |
= 
|           &n=
bsp;  | attribute type (see Section  | Section 3.2.2), PUT =
|
= 
|           &n=
bsp;  | 2.1 [I-D.ietf-scim-core-sche | (Section =
3.3.1),    |
= 
|           &n=
bsp;  | =
ma]).           &nb=
sp;            | =
PATCH (Section      |
= 
|           &n=
bsp;  =
|            &=
nbsp;           &nb=
sp;     | =
3.3.2)           &n=
bsp;  |
| invalidVers  | The specified API version is | GET =
(Section        |
|          =
    | not supported (see Section   | =
3.2.2), POST (ALL), |
= 
|           &n=
bsp;  | =
3.11).           &n=
bsp;           | PUT =
(Section        |
= 
|           &n=
bsp;  =
|            &=
nbsp;           &nb=
sp;     | 3.3.1), =
PATCH       |
= 
|           &n=
bsp;  =
|            &=
nbsp;           &nb=
sp;     | (Section 3.3.2),    =
|
= 
|           &n=
bsp;  =
|            &=
nbsp;           &nb=
sp;     | DELETE (Section     =
|
= 
|           &n=
bsp;  =
|            &=
nbsp;           &nb=
sp;     | =
3.4)           &nbs=
p;    |
= 
+--------------+------------------------------+---------------------+=

I plan to put these into draft 07 of the API = and will publish over the weekend.

 

As always, feedback welcome!

 

Phil

 

@independentid

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

 <= /span>

 

 

_______________________________________________
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=_3E6A55FF-AA96-4499-8054-4B2C66FB8103-- From nobody Wed Jul 2 21:36:20 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54B81A0643 for ; Wed, 2 Jul 2014 21:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mt_n7m8V9w-8 for ; Wed, 2 Jul 2014 21:36:16 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12DAE1A04C8 for ; Wed, 2 Jul 2014 21:36:15 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id cc10so10058106wib.3 for ; Wed, 02 Jul 2014 21:36:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+i5vw5mEstLu9miBrLGLUdF7CxgC6ZuJVebc2IFfbjs=; b=jtwGV82mcRjg2TG47a+tXhH+kprUIlr8CIFCDIjeR29reWDUKzlbHKsibqsL9cG0Yi VktN2eecWVfNmgAlHPEkpOMyjHQcH3qu6dVrUzjiZhIdigzNBc4BDOgBv0YVl6ZXj9ee isJd1kHeDw/+nkSkE7hPKAD4R36K+E6H3ZNJMiaKVc8CoKmGBRiYUXh/kj9JRl6oVs9F MtUCkMQDSgNEFFFbW6DSMKfr8K6JUUF6hnDpYtUdaLC5WocAYt5AI1HAxqIYq3xggYeW a3vHg2MD20M1TClafolJGERf5h0oZiIDaaIQUdm7jQbUFXsmCIMeGRF0JxYGjaiSiZ0q 1BiA== X-Gm-Message-State: ALoCoQnLQZYZzYyPS3eeFRHvJ2zbSSR8FUdJFcd6TO8LyMHNMCk13fTRycaoxTQ7jM2F3OjMy1nd X-Received: by 10.180.212.9 with SMTP id ng9mr11777638wic.46.1404362174433; Wed, 02 Jul 2014 21:36:14 -0700 (PDT) Received: from [192.168.0.107] (91-65-169-67-dynip.superkabel.de. [91.65.169.67]) by mx.google.com with ESMTPSA id ej2sm59384787wjd.21.2014.07.02.21.36.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 21:36:13 -0700 (PDT) Message-ID: <53B4DDBB.4050703@tarent.de> Date: Thu, 03 Jul 2014 06:36:11 +0200 From: =?windows-1252?Q?David_M=F6bius?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: scim@ietf.org References: <348F75D5-7C0F-4B93-A7B7-88E0B2FFD4ED@oracle.com> <715BABD4-91D5-45FA-874A-FD14AEBC1577@oracle.com> In-Reply-To: <715BABD4-91D5-45FA-874A-FD14AEBC1577@oracle.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/W7pkRJIvNKLbJoHUc790gtfklWc Subject: Re: [scim] Proposed Detail Errors X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 04:36:18 -0000 fine for me :) Am 02.07.2014 19:12, schrieb Phil Hunt: > Folks, > > We’ve had quite a lot of discussion on this thread. It seems that the > list of errors (below) is well accepted but the question of > extensibility still needs to be resolved. > > I propose to publish the errors (shown below) with an editorial comment > that extensibility is being discussed and that these may change to URIs > (depending on how we resolve). > > The reason I would like to have this published is so that attendees can > have all the information in context for the meeting and the deadline is > Friday. > > *Any objections?* > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On Jun 27, 2014, at 11:47 AM, Phil Hunt > wrote: > >> After reviewing the API and Schema docs, here is a first cut of the >> detailed error codes. >> >> For HTTP Status 400 (Bad Request) responses, the following detail >> error types are defined: >> >> +--------------+------------------------------+---------------------+ >> | scimType | Description | Applicability | >> +--------------+------------------------------+---------------------+ >> | invalidFilte | The specified filter syntax | GET(Section 3.2.2), | >> | r | was invalid (does not comply | POST (Search - | >> | | with Figure 1) or the | Section 3.2.3), | >> | | specified attribute and | PATCH (Path Filter | >> | | filter comparison | - Section 3.3.2) | >> | | combination is not | | >> | | supported. | | >> | uniqueness | One or more of attribute | POST (Create - | >> | | values is already in use or | Section 3.1), PUT | >> | | is reserved. | (Section 3.3.1), | >> | | | PATCH (Section | >> | | | 3.3.2) | >> | mutability | The attempted modification | PUT (Section | >> | | is not compatible with the | 3.3.1), PATCH | >> | | target attributes mutability | (Section 3.3.2) | >> | | or current state (e.g. | | >> | | modification of an immutable | | >> | | attribute with an existing | | >> | | value). | | >> | invalidSynta | The request body message | POST (Search - | >> | x | structure was invalid or did | Section 3.2.2, | >> | | not conform to the request | Create - Section | >> | | schema. | 3.1, Bulk - Section | >> | | | 3.5), PUT (Section | >> | | | 3.3.1) | >> | invalidPath | The path attribute was | PATCH (Section | >> | | invalid or malformed (see | 3.3.2) | >> | | Figure 4). | | >> | noTarget | The specified "path" did not | PATCH (Section | >> | | yield an attribute or | 3.3.2) | >> | | attribute value that could | | >> | | be operated on. This occurs | | >> | | when the specified "path" | | >> | | value contains a filter that | | >> | | yields no match. | | >> | invalidValue | A required value was | GET (Section | >> | | missing, or the value | 3.2.2), POST | >> | | specified was not compatible | (Create - Section | >> | | with the operation or | 3.1, Search - | >> | | attribute type (see Section | Section 3.2.2), PUT | >> | | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1), | >> | | ma]). | PATCH (Section | >> | | | 3.3.2) | >> | invalidVers | The specified API version is | GET (Section | >> | | not supported (see Section | 3.2.2), POST (ALL), | >> | | 3.11). | PUT (Section | >> | | | 3.3.1), PATCH | >> | | | (Section 3.3.2), | >> | | | DELETE (Section | >> | | | 3.4) | >> +--------------+------------------------------+---------------------+ >> I plan to put these into draft 07 of the API and will publish over the >> weekend. >> >> As always, feedback welcome! >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > From nobody Thu Jul 3 14:17:48 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2D71B282F; Thu, 3 Jul 2014 14:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhG1Uyj2gT2Q; Thu, 3 Jul 2014 14:17:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8481B2859; Thu, 3 Jul 2014 14:17:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140703211737.11706.52506.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 14:17:37 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/glGeAh3ZCnH7VG_-2-N1PbW15pw Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-api-07.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 21:17:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the System for Cross-domain Identity Management Working Group of the IETF. Title : System for Cross-Domain Identity Management:Protocol Authors : Phil Hunt Kelly Grizzle Morteza Ansari Erik Wahlstroem Chuck Mortimore Filename : draft-ietf-scim-api-07.txt Pages : 69 Date : 2014-07-03 Abstract: The System for Cross-Domain Identity Management (SCIM) specification is designed to make managing user identity in cloud based applications and services easier. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. It's intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols. In essence, make it fast, cheap, and easy to move users in to, out of, and around the cloud. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-api/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-scim-api-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-api-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 3 14:32:25 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0261A063F for ; Thu, 3 Jul 2014 14:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZJMb-BlRdzY for ; Thu, 3 Jul 2014 14:32:23 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCE221A04FA for ; Thu, 3 Jul 2014 14:32:23 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s63LWMVS009271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 3 Jul 2014 21:32:23 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s63LWLJl029269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 3 Jul 2014 21:32:22 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s63LWLjN020282 for ; Thu, 3 Jul 2014 21:32:21 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 Jul 2014 14:32:21 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Phil Hunt In-Reply-To: <20140703211737.11706.52506.idtracker@ietfa.amsl.com> Date: Thu, 3 Jul 2014 14:32:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <971B14A8-FABA-47E2-B6D2-86369815E5A7@oracle.com> References: <20140703211737.11706.52506.idtracker@ietfa.amsl.com> To: Scim WG X-Mailer: Apple Mail (2.1878.2) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/uvJFVI21hQMvn9fuKTPeP7kdmRE Subject: Re: [scim] I-D Action: draft-ietf-scim-api-07.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 21:32:25 -0000 As I mentioned in previous emails, draft 07 of the API now includes a = set of detail errors (see section 3.10).=20 There is still some discussion about whether the detail errors should be = URIs and extensible or whether they should be a fixed set of keywords. = As agreed, I=92ve included an editorial note to this effect. Except for the error URI discussion, I=92m very happy that we are close = to the last call draft and expect only minor clarifications etc going = forwards. All of the outstanding tickets have been addressed.=20 Thanks everyone for your help and thoughtful contributions! Looking forward to the Toronto meeting.=20 Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 3, 2014, at 2:17 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the System for Cross-domain Identity = Management Working Group of the IETF. >=20 > Title : System for Cross-Domain Identity = Management:Protocol > Authors : Phil Hunt > Kelly Grizzle > Morteza Ansari > Erik Wahlstroem > Chuck Mortimore > Filename : draft-ietf-scim-api-07.txt > Pages : 69 > Date : 2014-07-03 >=20 > Abstract: > The System for Cross-Domain Identity Management (SCIM) specification > is designed to make managing user identity in cloud based > applications and services easier. The specification suite seeks to > build upon experience with existing schemas and deployments, placing > specific emphasis on simplicity of development and integration, = while > applying existing authentication, authorization, and privacy models. > It's intent is to reduce the cost and complexity of user management > operations by providing a common user schema and extension model, as > well as binding documents to provide patterns for exchanging this > schema using standard protocols. In essence, make it fast, cheap, > and easy to move users in to, out of, and around the cloud. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-scim-api/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-scim-api-07 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-api-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Sun Jul 6 17:01:53 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9351A0056 for ; Sun, 6 Jul 2014 17:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfWoyHeK9AhP for ; Sun, 6 Jul 2014 17:01:50 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E53861A0010 for ; Sun, 6 Jul 2014 17:01:49 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6701nhH030116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 7 Jul 2014 00:01:49 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s6701m8q017142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 7 Jul 2014 00:01:48 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6701lMQ002856 for ; Mon, 7 Jul 2014 00:01:47 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 06 Jul 2014 17:01:47 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_688FE3A1-1CED-486D-B2EF-C5A3DB4843F7" Message-Id: <5601CDE0-17B5-4637-90D5-A53925568BD1@oracle.com> Date: Sun, 6 Jul 2014 17:01:44 -0700 To: Scim WG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/RONnwOtkuI_TgFkJqSUOsZo2mEE Subject: [scim] Clarification on schemas handling in PATCH operations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 00:01:51 -0000 --Apple-Mail=_688FE3A1-1CED-486D-B2EF-C5A3DB4843F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 A question came up regarding handling of schemas attribute during PATCH = operations. How is it specified/interpreted? One difference between PATCH vs POST/PUT is that the body of the message = is the actual object being manipulated. In contrast the body of the = PATCH request has an api specific schema (that describes the attributes = op, path, value, etc). For example: { "schemas": ["urn:scim:api:messages:2.0:PatchOp"], "op":"add", "path":"members", "value":[ { "display": "Babs Jensen", "$ref": "https://example.com/v2/Users/2819c223...413861904646", "value": "2819c223-7f76-453a-919d-413861904646" } ] } Thus how does a client indicate what schemas are in play for the data = object being manipulated? I propose the following clarification (added to the PATCH introduction = section): The attribute notation rules described in Section 3.8 apply for describing attribute paths. For all operations, the value of the "schemas" attribute on the service provider's representation of the resource SHALL be assumed by default. If one of the PATCH operations modifies the "schemas" attribute, subsequent operations SHALL assume the modified state of the "schemas" attribute. Clients MAY implicitly modify the "schemas" attribute by adding (or replacing) an attribute with its fully qualified name including schema URN. For example, adding the attribute "urn:scim:schemas:extension:enterprise:2.0:User:employeeNumber", automatically adds the value "urn:scim:schemas:extension:enterprise:2.0:User" to the resource's "schemas" attribute. For example the following two PATCHes are equivalent. Implicitly adding schema: { "schemas": ["urn:scim:api:messages:2.0:PatchOp"], "op":"add", = "path":"urn:scim:schemas:extension:enterprise:2.0:User:employeeNumber", "value=94:=940987654321" } Or explicit schemas update and new attribute: [ { "schemas": ["urn:scim:api:messages:2.0:PatchOp=94], "op":"add=94, "path=94:"schemas=94, "value=94:=94urn:scim:schemas:extension:enterprise:2.0:User=94 }, { "schemas": ["urn:scim:api:messages:2.0:PatchOp=94], "op":"add=94, "path":"employeeNumber=94, "value=94:=940987654321=94 } ] Any objections/refinements to the above paragraph? I will add this (or = some version close to it in the next draft. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_688FE3A1-1CED-486D-B2EF-C5A3DB4843F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 A = question came up regarding handling of schemas attribute during PATCH = operations. How is it specified/interpreted?

One = difference between PATCH vs POST/PUT is that the body of the message is = the actual object being manipulated. In contrast the body of the PATCH = request has an api specific schema (that describes the attributes op, = path, value, etc). For example:
{
  "schemas": ["urn:scim:api:messages:2.0:PatchOp"],
  "op":"add",
  "path":"members",
  "value":[
    {
      "display": "Babs Jensen",
      "$ref": "https://exam=
ple.com/v2/Users/2819c223...413861904646",
      "value": "2819c223-7f76-453a-919d-413861904646"
    }
  ]
}
Thus how does a client indicate what schemas are in = play for the data object being = manipulated?

I propose the following = clarification (added to the PATCH introduction section):
The attribute =
notation rules described in Section 3.8 apply for
describing attribute paths.  For all operations, the value of the
"schemas" attribute on the service provider's representation of the
resource SHALL be assumed by default.  If one of the PATCH operations
modifies the "schemas" attribute, subsequent operations SHALL assume
the modified state of the "schemas" attribute.  Clients MAY
implicitly modify the "schemas" attribute by adding (or replacing) an
attribute with its fully qualified name including schema URN.  For
example, adding the attribute
"urn:scim:schemas:extension:enterprise:2.0:User:employeeNumber",
automatically adds the value
"urn:scim:schemas:extension:enterprise:2.0:User" to the resource's
"schemas" attribute.
For example the following two PATCHes are =
equivalent.
Implicitly adding = schema:
{
  "schemas": ["urn:scim:api:messages:2.0:PatchOp"],
  "op":"add",
  =
"path":"urn:scim:schemas:extension:enterprise:2.0:User:employeeNumber",
  "value=94:=940987654321"
}
Or explicit schemas update and new = attribute:
[
  {
    "schemas": ["urn:scim:api:messages:2.0:PatchOp=94],
    "op":"add=94,
    "path=94:"schemas=94,
    =
"value=94:=94urn:scim:schemas:extension:enterprise:2.0:User=94
  },
  {
    "schemas": ["urn:scim:api:messages:2.0:PatchOp=94],
    "op":"add=94,
    "path":"employeeNumber=94,
    "value=94:=940987654321=94
 }
]
Any objections/refinements to the above = paragraph? I will add this (or some version close to it in the next = draft.

= --Apple-Mail=_688FE3A1-1CED-486D-B2EF-C5A3DB4843F7-- From nobody Mon Jul 7 15:34:37 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F4F1B281C for ; Mon, 7 Jul 2014 15:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U_BngwbjkTxQ for ; Mon, 7 Jul 2014 15:34:34 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 837371A0AAD for ; Mon, 7 Jul 2014 15:34:34 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s67MYXPg003134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 7 Jul 2014 22:34:34 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s67MYXlo018612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 7 Jul 2014 22:34:33 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s67MYV4s009022 for ; Mon, 7 Jul 2014 22:34:32 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 Jul 2014 15:34:31 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_22804ECC-32C7-4067-9AEF-187C454FD868" Message-Id: <0447CD1D-8277-4877-8873-C29040288A81@oracle.com> Date: Mon, 7 Jul 2014 15:34:30 -0700 To: Scim WG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/lrKjFzVb9xpcrBgZrXLAsXfmNV4 Subject: [scim] Use of [] brackets consistently in PATCH X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 22:34:36 -0000 --Apple-Mail=_22804ECC-32C7-4067-9AEF-187C454FD868 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It has been brought to my attention that in the API PATCH examples, when = there is a single operation, the operation looks like this: { "schemas": ["urn:scim:api:messages:2.0:PatchOp"], "op":"replace", "path":"addresses[type eq \"work\"].streetAddress", "value":"911 Universal City Plaza" } When there are multiple operations, square brackets are used to indicate = an array of operations: [ { "schemas": ["urn:scim:api:messages:2.0:PatchOp"], "op":"remove","path":"members"}, { "schemas": ["urn:scim:api:messages:2.0:PatchOp"], "op":"add", "path":"members", "value":[ { "display": "Babs Jensen", "$ref": "https://example.com/v2/Users/2819c223...413861904646", "value": "2819c223-7f76-453a-919d-413861904646" }, { "display": "James Smith", "$ref": "https://example.com/v2/Users/08e1d05d...473d93df9210", "value": "08e1d05d-121c-4561-8b96-473d93df9210" }] } ] While I believe this is technically ok for JSON, the question was that = the message format is not consistent. Should we insist that square brackets always be the outer most element = in a PATCH operation even when there is a single operation? Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_22804ECC-32C7-4067-9AEF-187C454FD868 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii It has = been brought to my attention that in the API PATCH examples, when there = is a single operation, the operation looks like this:
   {
     "schemas": ["urn:scim:api:messages:2.0:PatchOp"],
     "op":"replace",
     "path":"addresses[type eq \"work\"].streetAddress",
     "value":"911 Universal City Plaza"
   }

When there are multiple operations, square = brackets are used to indicate an array of operations:
   [
     { "schemas": ["urn:scim:api:messages:2.0:PatchOp"],
       "op":"remove","path":"members"},
     {
       "schemas": ["urn:scim:api:messages:2.0:PatchOp"],
       "op":"add",
       "path":"members",
       "value":[
       {
         "display": "Babs Jensen",
         "$ref": "https://exam=
ple.com/v2/Users/2819c223...413861904646",
         "value": "2819c223-7f76-453a-919d-413861904646"
       },
       {
         "display": "James Smith",
         "$ref": "https://exam=
ple.com/v2/Users/08e1d05d...473d93df9210",
         "value": "08e1d05d-121c-4561-8b96-473d93df9210"
       }]
     }
   ]

While I believe this is technically ok = for JSON, the question was that the message format is not = consistent.

Should we insist that square = brackets always be the outer most element in a PATCH operation even when = there is a single operation?

= --Apple-Mail=_22804ECC-32C7-4067-9AEF-187C454FD868-- From nobody Tue Jul 8 06:37:46 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D761B2837 for ; Tue, 8 Jul 2014 06:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yOjvlkybTOz for ; Tue, 8 Jul 2014 06:37:41 -0700 (PDT) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6E401B2823 for ; Tue, 8 Jul 2014 06:37:40 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id t60so5989423wes.32 for ; Tue, 08 Jul 2014 06:37:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=xuK2cbRwqbBrk78Pgm0O6KXsAvX2NVONJCrVcRdT4Os=; b=jM+xr3Fu4wbRsGOgdPGnhlxG//f/jINqMpA3Jrpni4gtgjD8FVGL+0MLIt5S+RXeAd yUFWiWwgZQJ9N7fH2uboPw2cBAltPhC4e2pJCpGHSprmkfHW7VjShNWgGMwyMjlRNhGv c4O/SN2OZ3fa282BShupD9Cw7/7/KrK+r/WMynnMPkqSK5w9cXDbVNLw8btGmPNwO5tW Pn+xhaz4wzOtSViO4UyOmsGw3YUnBwymRk9XX+m6oxgF60t0OQMVHeOPtkyeNt2I6yql sMK+8gFmdmEOJZwwr48t2D+S8nQr66xAgwI8Bij4txZUbe56QtW8AvliFFOmXNMhPiq1 L4WA== X-Gm-Message-State: ALoCoQnjX7+7CdGtcz6YMjLEfV5xWDS666xPFj2Hb5/euBUG7ljJWnSSl4Pi8KMq5dXi+YEkVuoy X-Received: by 10.180.103.228 with SMTP id fz4mr4024840wib.4.1404826656957; Tue, 08 Jul 2014 06:37:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.119.6 with HTTP; Tue, 8 Jul 2014 06:37:16 -0700 (PDT) In-Reply-To: <0447CD1D-8277-4877-8873-C29040288A81@oracle.com> References: <0447CD1D-8277-4877-8873-C29040288A81@oracle.com> From: Ian Glazer Date: Tue, 8 Jul 2014 09:37:16 -0400 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=f46d0418267adc08fe04fdaeb153 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/zrSiOh1y3eOuQ5usdDMPyxGi-y8 Cc: Scim WG Subject: Re: [scim] Use of [] brackets consistently in PATCH X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 13:37:43 -0000 --f46d0418267adc08fe04fdaeb153 Content-Type: text/plain; charset=UTF-8 Consistency is a good thing - I say even in the single op case use squares. On Mon, Jul 7, 2014 at 6:34 PM, Phil Hunt wrote: > It has been brought to my attention that in the API PATCH examples, when > there is a single operation, the operation looks like this: > > { > "schemas": ["urn:scim:api:messages:2.0:PatchOp"], > "op":"replace", > "path":"addresses[type eq \"work\"].streetAddress", > "value":"911 Universal City Plaza" > } > > > When there are multiple operations, square brackets are used to indicate > an array of operations: > > [ > { "schemas": ["urn:scim:api:messages:2.0:PatchOp"], > "op":"remove","path":"members"}, > { > "schemas": ["urn:scim:api:messages:2.0:PatchOp"], > "op":"add", > "path":"members", > "value":[ > { > "display": "Babs Jensen", > "$ref": "https://example.com/v2/Users/2819c223...413861904646", > "value": "2819c223-7f76-453a-919d-413861904646" > }, > { > "display": "James Smith", > "$ref": "https://example.com/v2/Users/08e1d05d...473d93df9210", > "value": "08e1d05d-121c-4561-8b96-473d93df9210" > }] > } > ] > > > While I believe this is technically ok for JSON, the question was that the > message format is not consistent. > > Should we insist that square brackets always be the outer most element in > a PATCH operation even when there is a single operation? > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --f46d0418267adc08fe04fdaeb153 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Consistency is a good thing - I say even in the single op = case use squares.


On Mon, Jul 7, 2014 at 6:34 PM, Phil Hunt <<= a href=3D"mailto:phil.hunt@oracle.com" target=3D"_blank">phil.hunt@oracle.c= om> wrote:
It has b= een brought to my attention that in the API PATCH examples, when there is a= single operation, the operation looks like this:
   {
     "schemas": ["urn:scim:api:messages:2.0:PatchOp"],
     "op":"replace",
     "path":"addresses[type eq \"work\"].streetAdd=
ress",
     "value":"911 Universal City Plaza"
   }

When there are multiple operations, square bracke= ts are used to indicate an array of operations:
   [
     { "schemas": ["urn:scim:api:messages:2.0:PatchOp"]=
,
       "op":"remove","path":"members&quo=
t;},
     {
       "schemas": ["urn:scim:api:messages:2.0:PatchOp"]=
,
       "op":"add",
       "path":"members",
       "value":[
       {
         "display": "Babs Jensen",
         "$ref": "https://example.com/v2/Users/2819c=
223...413861904646",
         "value": "2819c223-7f76-453a-919d-413861904646"=
;
       },
       {
         "display": "James Smith",
         "$ref": "https://example.com/v2/Users/08e1d=
05d...473d93df9210",
         "value": "08e1d05d-121c-4561-8b96-473d93df9210"=
;
       }]
     }
   ]

While I believe this is technically ok for = JSON, the question was that the message format is not consistent.

Should we insist that square brackets always be the outer m= ost element in a PATCH operation even when there is a single operation?



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




--
Ian Glazer
Senior Director, Identity
= +1 202 255 3166
--f46d0418267adc08fe04fdaeb153-- From nobody Tue Jul 8 06:40:41 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51E71B2A7A for ; Tue, 8 Jul 2014 06:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U_Td_-haOn26 for ; Tue, 8 Jul 2014 06:40:36 -0700 (PDT) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85C141B2AC5 for ; Tue, 8 Jul 2014 06:40:32 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id pn19so4002954lab.15 for ; Tue, 08 Jul 2014 06:40:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=D9hf/5OCbGVa4PTokTlwy3O7lNz2TLZtke1Ac2uS+x0=; b=W627nIujON2aVBStuDZ+5r06QCZa2gdkjpGgy1q9du2qJFxFXPThRH5u/HWqFZySxj hs6fOuwjzvj+H+JK4+Xu+qPZMdsfftQ/61Rf2S9xXec66bRffOov1qzvnlwbyxQP6Ftn vX4AHVw07rTnbm1rSshSHdzXojBVKXhsAiVUy1zzhCzCz8Nh90ROGl6lzrH4DF95Whc0 ZO35udsU6atkzBxUBIHdRP3OWr9iEngwqP/Qk19/KZpKxmWet9TYawhnQunmokspCmQg H2J4Tm7QzbgveiunGeFVBEvkJyqek3IQW28gtgYtCG0amiDfs1yfACBfkDIvv4VR0kWT x8vA== X-Gm-Message-State: ALoCoQlOT1xNeA1gHIuRbU7lu5s3YfaE8M7hHWQ1SgeDcfWu8JO7c9ZzDhfClXtCMf9l3aC8uMws X-Received: by 10.152.27.194 with SMTP id v2mr7143786lag.57.1404826829681; Tue, 08 Jul 2014 06:40:29 -0700 (PDT) Received: from [109.105.104.196] (dhcp62.se-tug.nordu.net. [109.105.104.196]) by mx.google.com with ESMTPSA id le5sm20259521lac.14.2014.07.08.06.40.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Jul 2014 06:40:29 -0700 (PDT) Message-ID: <53BBF4CC.5010505@mnt.se> Date: Tue, 08 Jul 2014 15:40:28 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: scim@ietf.org References: <0447CD1D-8277-4877-8873-C29040288A81@oracle.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/LKQrWMgaQGvea2GRAALT9srLxv4 Subject: Re: [scim] Use of [] brackets consistently in PATCH X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 13:40:39 -0000 On 2014-07-08 15:37, Ian Glazer wrote: > Consistency is a good thing - I say even in the single op case use squares. > > +1 as an individual! From nobody Tue Jul 8 06:47:30 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAAE1B2838 for ; Tue, 8 Jul 2014 06:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsZ0yfAgnuj4 for ; Tue, 8 Jul 2014 06:47:25 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 055A21B282B for ; Tue, 8 Jul 2014 06:47:24 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) with Microsoft SMTP Server (TLS) id 15.0.980.8; Tue, 8 Jul 2014 13:47:23 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.59]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.141]) with mapi id 15.00.0980.000; Tue, 8 Jul 2014 13:47:23 +0000 From: Kelly Grizzle To: Leif Johansson , "scim@ietf.org" Thread-Topic: [scim] Use of [] brackets consistently in PATCH Thread-Index: AQHPmjOlwb0IRny8/EW2OsaGmyFqW5uWLw8AgAAA5QCAAAHucA== Date: Tue, 8 Jul 2014 13:47:22 +0000 Message-ID: References: <0447CD1D-8277-4877-8873-C29040288A81@oracle.com> <53BBF4CC.5010505@mnt.se> In-Reply-To: <53BBF4CC.5010505@mnt.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 1F12F29B0079701F12F3E8 x-originating-ip: [70.114.158.171] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0266491E90 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(24454002)(13464003)(51704005)(377454003)(377424004)(77096002)(76176999)(85852003)(74316001)(54356999)(46102001)(106116001)(107886001)(79102001)(74662001)(21056001)(76482001)(33646001)(77982001)(107046002)(66066001)(85306003)(74502001)(105586002)(50986999)(106356001)(80022001)(81342001)(99286002)(76576001)(81542001)(86362001)(83322001)(87936001)(19580395003)(19580405001)(2656002)(31966008)(15975445006)(95666004)(4396001)(99396002)(20776003)(64706001)(92566001)(101416001)(83072002)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/MIr57ZswwqIAaJbvtpa68dE4Ang Subject: Re: [scim] Use of [] brackets consistently in PATCH X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 13:47:27 -0000 +1 -----Original Message----- From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Leif Johansson Sent: Tuesday, July 08, 2014 8:40 AM To: scim@ietf.org Subject: Re: [scim] Use of [] brackets consistently in PATCH On 2014-07-08 15:37, Ian Glazer wrote: > Consistency is a good thing - I say even in the single op case use square= s. >=20 >=20 +1 as an individual! _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From nobody Tue Jul 8 10:01:03 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2D01B2B29 for ; Tue, 8 Jul 2014 10:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFdVNeBYhOwx for ; Tue, 8 Jul 2014 10:00:45 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F29031B2B4A for ; Tue, 8 Jul 2014 10:00:44 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s68H0hFt014644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Jul 2014 17:00:44 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s68H0gDD025352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jul 2014 17:00:43 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s68H0e8t003043; Tue, 8 Jul 2014 17:00:41 GMT Received: from [10.248.248.227] (/173.180.46.27) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 Jul 2014 10:00:40 -0700 References: <0447CD1D-8277-4877-8873-C29040288A81@oracle.com> <53BBF4CC.5010505@mnt.se> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <489943BC-900C-4DCF-A122-71C7BEE256FB@oracle.com> X-Mailer: iPhone Mail (11D257) From: Phil Hunt Date: Tue, 8 Jul 2014 10:00:36 -0700 To: Kelly Grizzle X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/n2uYgobhhKUJrZlvIl8VckAHH0A Cc: Leif Johansson , "scim@ietf.org" Subject: Re: [scim] Use of [] brackets consistently in PATCH X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 17:00:49 -0000 Hey, I thought you folks could use a "t-ball" question in the mix.=20 Phil > On Jul 8, 2014, at 6:47, Kelly Grizzle wrote= : >=20 > +1 >=20 > -----Original Message----- > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Leif Johansson > Sent: Tuesday, July 08, 2014 8:40 AM > To: scim@ietf.org > Subject: Re: [scim] Use of [] brackets consistently in PATCH >=20 >> On 2014-07-08 15:37, Ian Glazer wrote: >> Consistency is a good thing - I say even in the single op case use square= s. > +1 as an individual! >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Tue Jul 8 10:43:45 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E861A036D for ; Tue, 8 Jul 2014 10:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abTPwgVYNrGq for ; Tue, 8 Jul 2014 10:43:39 -0700 (PDT) Received: from atl4mhob04.myregisteredsite.com (atl4mhob04.myregisteredsite.com [209.17.115.42]) by ietfa.amsl.com (Postfix) with ESMTP id 31F261A0368 for ; Tue, 8 Jul 2014 10:43:39 -0700 (PDT) Received: from mailpod1.hostingplatform.com (atl4obmail02pod1.mgt.hosting.qts.netsol.com [10.30.71.114]) by atl4mhob04.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s68HhbeC022194 for ; Tue, 8 Jul 2014 13:43:37 -0400 Received: (qmail 7116 invoked by uid 0); 8 Jul 2014 17:43:37 -0000 X-TCPREMOTEIP: 96.232.122.91 X-Authenticated-UID: sal@idmachines.com Received: from unknown (HELO salPC) (sal@idmachines.com@96.232.122.91) by 0 with ESMTPA; 8 Jul 2014 17:43:37 -0000 From: "Salvatore D'Agostino" To: "'Phil Hunt'" , "'Kelly Grizzle'" References: <0447CD1D-8277-4877-8873-C29040288A81@oracle.com> <53BBF4CC.5010505@mnt.se> <489943BC-900C-4DCF-A122-71C7BEE256FB@oracle.com> In-Reply-To: <489943BC-900C-4DCF-A122-71C7BEE256FB@oracle.com> Date: Tue, 8 Jul 2014 13:43:32 -0400 Message-ID: <072a01cf9ad4$230506f0$690f14d0$@com> X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+azjdfYIMjJbeJTfKWR/H1rU4VUwABdSyg Content-Language: en-us MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_0725_01CF9AB2.9B729E30"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/6d41ANdrYA3yw6nQv7zhTC_XOyM Cc: 'Leif Johansson' , scim@ietf.org Subject: Re: [scim] Use of [] brackets consistently in PATCH X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 17:43:42 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0725_01CF9AB2.9B729E30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yes, even I can hit this.. +1 -----Original Message----- From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Tuesday, July 08, 2014 1:01 PM To: Kelly Grizzle Cc: Leif Johansson; scim@ietf.org Subject: Re: [scim] Use of [] brackets consistently in PATCH Hey, I thought you folks could use a "t-ball" question in the mix. Phil > On Jul 8, 2014, at 6:47, Kelly Grizzle wrote: > > +1 > > -----Original Message----- > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Leif Johansson > Sent: Tuesday, July 08, 2014 8:40 AM > To: scim@ietf.org > Subject: Re: [scim] Use of [] brackets consistently in PATCH > >> On 2014-07-08 15:37, Ian Glazer wrote: >> Consistency is a good thing - I say even in the single op case use squares. > +1 as an individual! > > _______________________________________________ > 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 ------=_NextPart_000_0725_01CF9AB2.9B729E30 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITIjCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIEnTCC A4WgAwIBAgIQND3pK6wnNP+PyzSU+8xwVDANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoX DTIwMDUzMDEwNDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2Fs dCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk 8n2rQTtiRjeuzcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTE hb2FUTV5pE5okHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov 66yhs2qqty5nNYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8 goqOpA6l14lD/BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6h hX71R2XL+E1XKHTSNP8wtu72YjAUjCzrAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6 xCZU7wO94CTLVBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNo dHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYB BQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQABvJzjYyiw8zEBwt973WKgAZ0jMQ+cknNTUeofTPrWn8TKL2d+eDMPdBa5kYeR 9Yom+mRwANge+QsEYlCHk4HU2vUj2zS7hVa0cDRueIM3HoUcxREVkl+HF72sav3xwtHMiV+xfPA+ UfI183zsYJhrOivg79+zfYbrtRv1W+yifJgT1wBQudEtc94DeHThBYUxXsuauZ2UxrmUN3Vy3ET7 Z+jw+iUeUqfaJelH4KDHPKBOsQo2+3dIn++Xivu0/uOUFKiDvFwtP9JgcWDuwnGCDOmINuPaILSj oGyqlku4gI51ykkH9jsUut/cBdmf2+Cy5k2geCbn5y1uf1/GHogVMIIFGjCCBAKgAwIBAgIQbRnq pxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVU MRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmly c3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1 MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09N T0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU 4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHff sReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kAB W0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJk JpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IB SzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4 Y2QnwS/ioFu8ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQK MAgwBgYEVR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVRO LVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVu dF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcN AQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjB MCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8 H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5 OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggUlMIIEDaADAgECAhAw2ACH 8WF9ex+PZrGbouVEMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGlt aXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTEzMTAyMzAwMDAwMFoXDTE0MTAyMzIzNTk1OVowIzEhMB8GCSqGSIb3DQEJARYS c2FsQGlkbWFjaGluZXMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsuTZeTEH CNgvmi6wljJrkNJjs5Pz7V+XNThwN9N6MN4sYkjyfAOHLHSPKRHDGkOozLN5IyjGsSGRfDBP8N7x 0tWTujRlNCb5WSTPmiz+7YxjUaDQLPp6NC4k60p0l3uBTEblNLQ7jljkP54yzFDhKUBr4V34oGQr t8CYM/n4b1/H1NBThYMYwxY+fcgZeZLEXUCpCBxd+vZ40422Yp6fCVBNAn3g/6Ui7iOBnksNdqVd A7niqyfA3V95FBg8KdBn4hX0gFgGtf5rN3QKm62Vz18HOOwjAZKWkxKaxxNAu4TGOewDqV6a1pQD k0KQaul8ps6R8j4UXhEdNHojiSAhKwIDAQABo4IB4jCCAd4wHwYDVR0jBBgwFoAUehNOAHRbxnhj ZCfBL+KgW7x5xXswHQYDVR0OBBYEFCl0wCQjyTSoet4B/SWTNiEvviXrMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0cDovL2NybC5j b21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy bDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9D T01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHQYDVR0RBBYwFIESc2FsQGlkbWFjaGluZXMuY29t MA0GCSqGSIb3DQEBBQUAA4IBAQBTS8NQyx8WR+ty/qItwB45qj6/wDKwFJkoZPNhYjjM4XQC3UQd XhDnUeQGjxs6fy4sBt2vM7pKIfy6LBi4jkDgF6GOEs0w+3idXlZ3dfbcFmMoYjPUMGAYw9Xe3vNK 9IIVGmrO4lYexmo6AqITaESXwQqpjFn2+x7GlpaAkw6UpfSaiadDIwo9qH7OPZRAD3AUYlKj4yRq xfXUl6KuBBiqM0UpdmItFCec4oPVpcY42u+v00P5rxeaT5nOHBWGIsCNcHSkL1sZARkBtQGdLedR QB2BsmUaNT8ObqK1K1c4wNZts5uqomHFPWgReqe9dEQtlI2Ajtlp/KAdOqHwzxe5MYIEZTCCBGEC AQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8g Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDDYAIfxYX17H49msZui 5UQwCQYFKw4DAhoFAKCCApEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTQwNzA4MTc0MzMxWjAjBgkqhkiG9w0BCQQxFgQUv9dY64Bol63SyMr5VU8ZAY7Vfo4wgbcG CSqGSIb3DQEJDzGBqTCBpjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsG CWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZI hvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEw CgYIKoZIhvcNAgUwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQMNgAh/FhfXsfj2axm6LlRDCBuwYLKoZIhvcNAQkQAgsxgauggagwgZMxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDDYAIfxYX17H49msZui5UQwDQYJKoZIhvcN AQEBBQAEggEAoKavbQU32CMlbUs7ddhnhNjIxezAf2SgrsqbN4q5V6bKNEvHgUnoU/9wM0zMQ9Jh 1TWppwaSrk/sDIhLAI9KpumVTJXh1vH7y8Vywi+v+5JFnEJyvfHq4aPTMJcSxCy5iXyZl+X0MYx+ uvwTjD4+B+xxdFRoozNXeFRZCacttrspKllunMUxVWiLhMSuKKTJNB4jH9yVL5p1060E9inNR28o +mqWn/fNOIzHHanc6JdLvBA8SyMGw7mG21p1sQiWqeV4OL/y/0SkqHXVStIhBZo0NAxCBDI4Epp7 K8edZEDuUXfNhlqH30Obnr7pUM29WYbumrv7935OXKoyMHG8BgAAAAAAAA== ------=_NextPart_000_0725_01CF9AB2.9B729E30-- From nobody Tue Jul 8 13:12:10 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2B51A0032 for ; Tue, 8 Jul 2014 13:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFsnhLeNWufJ for ; Tue, 8 Jul 2014 13:11:56 -0700 (PDT) Received: from smtpauth4.wiscmail.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF47E1A000B for ; Tue, 8 Jul 2014 13:11:55 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_REOSU18USHtZxZzcMx+pQQ)" Received: from avs-daemon.smtpauth4.wiscmail.wisc.edu by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) id <0N8E00500T971M00@smtpauth4.wiscmail.wisc.edu> for scim@ietf.org; Tue, 08 Jul 2014 15:11:54 -0500 (CDT) X-Spam-PmxInfo: Server=avs-4, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.8.200331, SenderIP=0.0.0.0 Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0140.outbound.protection.outlook.com [207.46.163.140]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPS id <0N8E00JEITFUNN00@smtpauth4.wiscmail.wisc.edu> for scim@ietf.org; Tue, 08 Jul 2014 15:11:54 -0500 (CDT) Received: from BN1PR06MB423.namprd06.prod.outlook.com (10.141.58.154) by BN1PR06MB421.namprd06.prod.outlook.com (10.141.58.140) with Microsoft SMTP Server (TLS) id 15.0.980.8; Tue, 8 Jul 2014 20:11:51 +0000 Received: from BN1PR06MB423.namprd06.prod.outlook.com ([169.254.11.161]) by BN1PR06MB423.namprd06.prod.outlook.com ([169.254.11.148]) with mapi id 15.00.0980.000; Tue, 8 Jul 2014 20:11:51 +0000 Date: Tue, 08 Jul 2014 20:11:50 +0000 From: Keith Hazelton X-Originating-IP: [128.104.18.225] To: SCIM WG Message-id: Content-language: en-US Accept-Language: en-US Thread-topic: schema extension model question Thread-index: AQHPmujaswErWPuQQkOA+hlDrleTAQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0266491E90 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(83322001)(4396001)(107886001)(77096002)(95666004)(558084003)(89122001)(77982001)(83072002)(36756003)(54356999)(92566001)(99286002)(2656002)(88552001)(229853001)(75432001)(107046002)(92726001)(81542001)(105586002)(20776003)(101416001)(76482001)(74502001)(86362001)(64706001)(110136001)(99396002)(16236675004)(87936001)(106356001)(85852003)(50986999)(81342001)(80022001)(31966008)(21056001)(46102001)(85306003)(74662001)(79102001)(106116001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR06MB421; H:BN1PR06MB423.namprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; X-OriginatorOrg: wisc.edu Archived-At: http://mailarchive.ietf.org/arch/msg/scim/VwjIv38Z3FoQmJRzh0LH4avxGN4 Subject: [scim] schema extension model question X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 20:12:03 -0000 --Boundary_(ID_REOSU18USHtZxZzcMx+pQQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Core Schema draft 06 specifies how to define schema extensions to base objects like user and group. Is it permitted or not to define extensions to complex attributes within a base object, for example, to add custom sub-attributes to the complex attribute emails? -Keith Hazelton --Boundary_(ID_REOSU18USHtZxZzcMx+pQQ) Content-id: <1180771FA11B8B4AA14C26128377767D@namprd06.prod.outlook.com> Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT
Core Schema draft 06 specifies how to define schema extensions to base objects like user and group.  Is it permitted or not to define extensions to complex attributes within a base object, for example, to add custom sub-attributes to the complex attribute emails?

          —Keith Hazelton
--Boundary_(ID_REOSU18USHtZxZzcMx+pQQ)-- From nobody Tue Jul 8 13:21:28 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60771A002D for ; Tue, 8 Jul 2014 13:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgXDSSsK82Am for ; Tue, 8 Jul 2014 13:21:25 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CBFA1A000F for ; Tue, 8 Jul 2014 13:21:25 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s68KLON7003237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Jul 2014 20:21:24 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s68KLNMg026063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jul 2014 20:21:23 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s68KLMxi023150; Tue, 8 Jul 2014 20:21:22 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 Jul 2014 13:21:22 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_CC8AB6EE-D438-4E13-8BF8-5960DA6D4AF1" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Phil Hunt In-Reply-To: Date: Tue, 8 Jul 2014 13:21:21 -0700 Message-Id: <85E25954-4E03-4099-BA7E-C2F579E7E810@oracle.com> References: To: Keith Hazelton X-Mailer: Apple Mail (2.1878.2) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/mGz-sCzscFuVqV0OXUu8rwSftVo Cc: SCIM WG Subject: Re: [scim] schema extension model question X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 20:21:27 -0000 --Apple-Mail=_CC8AB6EE-D438-4E13-8BF8-5960DA6D4AF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Keith, I believe you may not. The reason is that schema extensions attributes are always added in = their own =93bag=94 within the JSON representation. This means you = could in fact use the same attribute name, but it would get passed = elsewhere. For example see the enterprise User extension below: { "schemas": [ "urn:scim:schemas:core:2.0:User", "urn:scim:schemas:extension:enterprise:2.0:User"], "id": "2819c223-7f76-453a-919d-413861904646", "externalId": "701984", "userName": "bjensen@example.com", "name": { "formatted": "Ms. Barbara J Jensen III", "familyName": "Jensen", "givenName": "Barbara", "middleName": "Jane", "honorificPrefix": "Ms.", "honorificSuffix": "III" }, =85=85=20 "displayName": "Babs Jensen", "urn:scim:schemas:extension:enterprise:2.0:User": { "employeeNumber": "701984", "costCenter": "4130", "organization": "Universal Studios", "division": "Theme Park", "department": "Tour Operations", "manager": { "managerId": "26118915-6090-4610-87e4-49d8ca9f808d", "$ref": "/Users/26118915-6090-4610-87e4-49d8ca9f808d", "displayName": "John Smith=94 } Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 8, 2014, at 1:11 PM, Keith Hazelton wrote: > Core Schema draft 06 specifies how to define schema extensions to base = objects like user and group. Is it permitted or not to define = extensions to complex attributes within a base object, for example, to = add custom sub-attributes to the complex attribute emails? >=20 > =97Keith Hazelton > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_CC8AB6EE-D438-4E13-8BF8-5960DA6D4AF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Keith,

I believe you may = not.

The reason is that schema extensions attributes = are always added in their own =93bag=94 within the JSON representation. =  This means you could in fact use the same attribute name, but it = would get passed elsewhere.  For example see the enterprise User = extension below:

{
  "schemas":
    [ "urn:scim:schemas:core:2.0:User",
      "urn:scim:schemas:extension:enterprise:2.0:User"],
  "id": "2819c223-7f76-453a-919d-413861904646",
  "externalId": "701984",
  "userName": "bjensen@example.com",
  "name": {
    "formatted": "Ms. Barbara J Jensen III",
    "familyName": "Jensen",
    "givenName": "Barbara",
    "middleName": "Jane",
    "honorificPrefix": "Ms.",
    "honorificSuffix": "III"
  },
 =85<snip>=85=20=

  "displayName": "Babs Jensen",

  "urn:scim:schemas:extension:enterprise:2.0:User": {
    "employeeNumber": "701984",
    "costCenter": "4130",
    "organization": "Universal Studios",
    "division": "Theme Park",
    "department": "Tour Operations",
    "manager": {
      "managerId": "26118915-6090-4610-87e4-49d8ca9f808d",
      "$ref": "/Users/26118915-6090-4610-87e4-49d8ca9f808d",
      "displayName": "John Smith=94
    }


On Jul 8, 2014, at 1:11 PM, Keith Hazelton <hazelton@wisc.edu> = wrote:

Core Schema draft 06 specifies how to define schema extensions to = base objects like user and group.  Is it permitted or not to define = extensions to complex attributes within a base object, for example, to = add custom sub-attributes to the complex attribute emails?

          =97Keith Hazelton
_______________________________________________
scim mailing = list
scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim

= --Apple-Mail=_CC8AB6EE-D438-4E13-8BF8-5960DA6D4AF1-- From nobody Wed Jul 9 02:02:01 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24831A03B7 for ; Wed, 9 Jul 2014 02:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YEC8XPyLiNW for ; Wed, 9 Jul 2014 02:01:58 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 462E11A03B6 for ; Wed, 9 Jul 2014 02:01:57 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id n3so2306354wiv.15 for ; Wed, 09 Jul 2014 02:01:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=dS5IXt/5Z9axCycqDKooou+h6dX1oDTdKeFkaIS1xhs=; b=k8MlTo6MdU9NDMJvOlFGxOn+PKgtzLPxxOYt7LXypTxmNIwVeVcn2+eypaGYdfhJP0 vIeFwhtR2wg4nIciO+EfuLhR5HgHzJzBXiUv4BUY3o041UqVFN8MVVgeioH5KEDxSW7E iCSPs5KtzquTBnFNyYXsRR8+MNGQyctgeqvsV0jWDSo7sXPObpW3h2L2/0uXXvix9f+P a/jufc9g9NssjgKkLRO7p+O4Un6qlEar8v+8XrQJznSU46p2N71WGWiYf0tEdjbrOG+C UBnjDYAgmL+Zk1ftjSkBz2dBGLBNwx48Rghe9BtAh9cAU6tWCOGkVgGypRxQE3K/NoBv B4BQ== X-Gm-Message-State: ALoCoQnfYdiK//E15zAnxNq4YJszo76YAiE1gUvZ0fSfT80U5JdEJJETGPnb4UGLvCC9dTdmIZGh X-Received: by 10.180.104.40 with SMTP id gb8mr9766414wib.59.1404896516213; Wed, 09 Jul 2014 02:01:56 -0700 (PDT) Received: from [172.24.12.173] (fb-n15-11.unbelievable-machine.net. [94.198.62.204]) by mx.google.com with ESMTPSA id ei3sm14380009wib.13.2014.07.09.02.01.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Jul 2014 02:01:55 -0700 (PDT) Message-ID: <53BD0502.6040405@tarent.de> Date: Wed, 09 Jul 2014 11:01:54 +0200 From: =?ISO-8859-15?Q?David_M=F6bius?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "scim@ietf.org WG" X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/RbWQxs12Y3JxLuwckdwF8Lm4uSY Subject: [scim] search case insensitiv X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 09:02:00 -0000 Hello, the normal search with scim is cas sensitive since we can't say it is not. Is their any possibility to say to the server that we want to do a case insensitive search? by David From nobody Wed Jul 9 09:22:06 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2AA1A040B for ; Wed, 9 Jul 2014 09:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFzad8QODKOV for ; Wed, 9 Jul 2014 09:22:05 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 971E51A0406 for ; Wed, 9 Jul 2014 09:22:04 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id s18so5158142lam.20 for ; Wed, 09 Jul 2014 09:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=z/SIr9FS9tZIXUIYXb1hPcOHDTF28JyefdBnE3ynpUo=; b=gBvGYZnASOivgikUBMsQ5alO3NQlejBuSJhj1G+BYnWYH+8pJqkxLEf4fj0km593m1 d7Z7l5VZKiXg+YIhHD3XV/TDWDNuKXY3no4NBbr4LZ3Jct/OU85Bu1lorD8ASGAKesdQ lY0xDuloK2f54ciJ3waWlzUptq3DQNeo9OQAM0odyOQ3b48WQIODs2CDzFC6dVQwDGLg clIN7oOa+zmjn9Zv+XshauXTP7XTMHr3giLJrqqh3fOqg3cvdNuVu3PvGFQcvDqkrtgQ +6t2Yul1pqEMl4BYlWi1bLwKaKLaiYX+uyzNDtxHKlawc1nEKMtdiaPUgJf2gYjO44aG 064A== MIME-Version: 1.0 X-Received: by 10.152.43.17 with SMTP id s17mr2184840lal.81.1404922922501; Wed, 09 Jul 2014 09:22:02 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.104.80 with HTTP; Wed, 9 Jul 2014 09:22:02 -0700 (PDT) Date: Wed, 9 Jul 2014 12:22:02 -0400 X-Google-Sender-Auth: D-IFSqCbAGrKTpjybe-qeDcO2W0 Message-ID: From: Barry Leiba To: "scim@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/A6J3HG7CLia0Yz1C_R4RwbN69_8 Subject: [scim] Protocol vs API X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 16:22:06 -0000 It seems y'all have a disagreement about whether you're proposing a protocol or an API, and that the document is inconsistent about what to call it. I think this is clearly a protocol, and *not* an API. As I see it, an API is something that says, "call this interface to do this, and call that interface to do that." Then people implement the API in their libraries, and you use the appropriate library for the platform you're programming for, and whatever. APIs might connect to proprietary stuff on the back end. The WG's main document is actually specifying bits on the wire, not programming interfaces. Someone could certainly build in API around this, but this isn't one. Barry From nobody Wed Jul 9 09:33:56 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE581A029D for ; Wed, 9 Jul 2014 09:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmsuWWmN7SSe for ; Wed, 9 Jul 2014 09:33:54 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED9661A0067 for ; Wed, 9 Jul 2014 09:33:53 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB390.namprd04.prod.outlook.com (10.141.60.147) with Microsoft SMTP Server (TLS) id 15.0.980.8; Wed, 9 Jul 2014 16:33:46 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.59]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.141]) with mapi id 15.00.0980.000; Wed, 9 Jul 2014 16:33:46 +0000 From: Kelly Grizzle To: Barry Leiba , "scim@ietf.org" Thread-Topic: [scim] Protocol vs API Thread-Index: AQHPm5Hxr3sOQ+l2XUGr3Jyue7aVHJuX7vfg Date: Wed, 9 Jul 2014 16:33:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 24D1ACD300798E24D1AE20 x-originating-ip: [24.55.12.91] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0267E514F9 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(189002)(199002)(13464003)(19580405001)(81342001)(106356001)(64706001)(66066001)(83322001)(87936001)(31966008)(76576001)(19580395003)(81542001)(79102001)(74316001)(21056001)(106116001)(83072002)(74662001)(20776003)(85852003)(74502001)(2656002)(33646001)(107046002)(105586002)(86362001)(92566001)(95666004)(54356999)(76176999)(46102001)(4396001)(99396002)(77982001)(101416001)(80022001)(107886001)(77096002)(15975445006)(76482001)(50986999)(99286002)(85306003)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB390; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/3KlrPaNOQucyooIUJTdkE2qKY48 Subject: Re: [scim] Protocol vs API X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 16:33:56 -0000 I don't know that I agree with this. Wikipedia has the following to say on= its API page: In some other cases, notably for SOAP and REST services, an API comes = as just a specification of remote calls exposed to the API consumers. This is pretty much what the SCIM API document does, and most things that I= have seen call REST endpoint documentation an API. That said ... I don't really care what we call it. If we do decide to go w= ith "protocol", it probably would make sense to rename the draft-ietf-scim-= api draft to something else. --Kelly -----Original Message----- From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Barry Leiba Sent: Wednesday, July 09, 2014 11:22 AM To: scim@ietf.org Subject: [scim] Protocol vs API It seems y'all have a disagreement about whether you're proposing a protoco= l or an API, and that the document is inconsistent about what to call it. I think this is clearly a protocol, and *not* an API. As I see it, an API is something that says, "call this interface to do this= , and call that interface to do that." Then people implement the API in th= eir libraries, and you use the appropriate library for the platform you're = programming for, and whatever. APIs might connect to proprietary stuff on = the back end. The WG's main document is actually specifying bits on the wire, not program= ming interfaces. Someone could certainly build in API around this, but thi= s isn't one. Barry _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From nobody Wed Jul 9 09:55:21 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5541A009E for ; Wed, 9 Jul 2014 09:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WHoRFNVzI5H for ; Wed, 9 Jul 2014 09:55:14 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91A1D1A0104 for ; Wed, 9 Jul 2014 09:55:14 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s69GtB9o029102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Jul 2014 16:55:13 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s69GtAPF024295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jul 2014 16:55:11 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s69GtAWp004947; Wed, 9 Jul 2014 16:55:10 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 09 Jul 2014 09:55:10 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: Date: Wed, 9 Jul 2014 09:55:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Barry Leiba X-Mailer: Apple Mail (2.1878.6) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/PlbUt5BTimRsoOQXoH1nJaHHBb8 Cc: "scim@ietf.org" Subject: Re: [scim] Protocol vs API X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 16:55:17 -0000 Ok. I see your distinction. You are defining =93API=94 as exclusive to = programming (how one accesses a protocol in code). My distinction was really in the layers: bits in the app layer (e.g. = payload) vs. bits related to a protocol on a network (IP). I will make it consistent around protocol then. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 9, 2014, at 9:22 AM, Barry Leiba wrote: > It seems y'all have a disagreement about whether you're proposing a > protocol or an API, and that the document is inconsistent about what > to call it. >=20 > I think this is clearly a protocol, and *not* an API. >=20 > As I see it, an API is something that says, "call this interface to do > this, and call that interface to do that." Then people implement the > API in their libraries, and you use the appropriate library for the > platform you're programming for, and whatever. APIs might connect to > proprietary stuff on the back end. >=20 > The WG's main document is actually specifying bits on the wire, not > programming interfaces. Someone could certainly build in API around > this, but this isn't one. >=20 > Barry >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Wed Jul 9 10:09:02 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8F11A0174 for ; Wed, 9 Jul 2014 10:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaHiM7eq32_i for ; Wed, 9 Jul 2014 10:08:57 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 628221A0062 for ; Wed, 9 Jul 2014 10:08:57 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id mc6so5299156lab.10 for ; Wed, 09 Jul 2014 10:08:54 -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:message-id:subject :from:to:content-type; bh=OA5hP2UGan786VLsXLOmwZKQKkIEHA3ixPrr4xzuI24=; b=PjjAChUiLao2kLEzIqNuJ/hfRQsMbrr6KM8jJ/BErEa+b2ekEmm+UjvS+Ycr+o52F4 eb1TSf0eDj0m4y7PVPbgp94M88Hx+xgNuKQ//5k79XZyFiMwKpTUPSqppM1YJzEd67TD pxAr47NksNdt1QFvEycvIfugZbME+hsNmaRt3DnzK3PJ+yCakVIcE09fymQBGtg3HSRS YrPjRd1q9CwNNgppyNtXZOWmyZEuddl0lSnUUspjXdRJNzRFwsNazabngIfvv2HMWd1J U+jZxiTb3KSHHZt59nnlJlMkQbUogLwBu+8mGM5Do+FqAWCLxdOMUz3DNXsuq+ukVsYE mdsw== MIME-Version: 1.0 X-Received: by 10.112.173.36 with SMTP id bh4mr1470743lbc.102.1404925734518; Wed, 09 Jul 2014 10:08:54 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.104.80 with HTTP; Wed, 9 Jul 2014 10:08:54 -0700 (PDT) In-Reply-To: References: Date: Wed, 9 Jul 2014 13:08:54 -0400 X-Google-Sender-Auth: 5h1o2D3OvOm-lp1_rGf8O3rndRQ Message-ID: From: Barry Leiba To: "scim@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/DwLoqLRqiy8CQae6zIQ9E762VoM Subject: Re: [scim] Protocol vs API X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 17:08:58 -0000 Kelly says that Wikipedia says... > In some other cases, notably for SOAP and REST services, an > API comes as just a specification of remote calls exposed to the > API consumers. Remote calls, yes. But here we're specifying bits on the wire. I think that part of the issue with, say, SOAP is that SOAP mixes the two, which blurs things. To me, the part of SOAP that specifies the bits on the wire is also a protocol. This might also be a case of IETF idiom vs idiom used elsewhere. To-MAY-to, to-MAH-to, or something like that. Kelly, directly now... > That said ... I don't really care what we call it. If we do decide to go > with "protocol", it probably would make sense to rename the > draft-ietf-scim-api draft to something else. The title of the document says "protocol", and at this point it's not worth the trouble to change the filename. The filename will disappear (except in the document history in the datatracker) when the RFC is published anyway. Phil says... > Ok. I see your distinction. You are defining "API" as exclusive to > programming (how one accesses a protocol in code). Right: Application Programming Interface. > My distinction was really in the layers: bits in the app layer > (e.g. payload) vs. bits related to a protocol on a network (IP). In the IETF, at least, we refer to bits-on-the-wire at every layer as "protocol". IP is a protocol, BGP is a protocol, TCP is a protocol, SMTP and HTTP are protocols, and various things built on HTTP are (higher layer) protocols. > I will make it consistent around protocol then. T'anks! Barry From nobody Wed Jul 9 10:10:35 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA731A0174 for ; Wed, 9 Jul 2014 10:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzHKG-_-01Oc for ; Wed, 9 Jul 2014 10:10:30 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0142.outbound.protection.outlook.com [207.46.163.142]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 731D21A0104 for ; Wed, 9 Jul 2014 10:10:30 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB391.namprd04.prod.outlook.com (10.141.60.150) with Microsoft SMTP Server (TLS) id 15.0.985.8; Wed, 9 Jul 2014 17:10:28 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.59]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.141]) with mapi id 15.00.0980.000; Wed, 9 Jul 2014 17:10:27 +0000 From: Kelly Grizzle To: Barry Leiba , "scim@ietf.org" Thread-Topic: [scim] Protocol vs API Thread-Index: AQHPm5Hxr3sOQ+l2XUGr3Jyue7aVHJuX9fGAgAAD1wCAAABfkA== Date: Wed, 9 Jul 2014 17:10:26 +0000 Message-ID: <88a5a81a50bd4daa8a822e01bbae04a2@BN1PR04MB392.namprd04.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 24F3427D00799024F343CA x-originating-ip: [24.55.12.91] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0267E514F9 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(13464003)(189002)(199002)(51914003)(51444003)(377454003)(107886001)(101416001)(80022001)(85852003)(66066001)(76576001)(107046002)(4396001)(83072002)(85306003)(86362001)(76176999)(50986999)(54356999)(77982001)(19580395003)(83322001)(81542001)(19580405001)(106116001)(21056001)(74316001)(99396002)(105586002)(92566001)(79102001)(33646001)(81342001)(106356001)(77096002)(46102001)(99286002)(95666004)(74502001)(76482001)(15975445006)(74662001)(20776003)(87936001)(31966008)(64706001)(2656002)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB391; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/0AK0cEwJzzXpI4ZRzGQYJ4U0dk0 Subject: Re: [scim] Protocol vs API X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 17:10:33 -0000 Works for me. Thanks for the clarifications, Barry. -----Original Message----- From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Barry Leiba Sent: Wednesday, July 09, 2014 12:09 PM To: scim@ietf.org Subject: Re: [scim] Protocol vs API Kelly says that Wikipedia says... > In some other cases, notably for SOAP and REST services, an > API comes as just a specification of remote calls exposed to the > API consumers. Remote calls, yes. But here we're specifying bits on the wire. I think that part of the issue with, say, SOAP is that SOAP mixes the two, = which blurs things. To me, the part of SOAP that specifies the bits on the= wire is also a protocol. This might also be a case of IETF idiom vs idiom used elsewhere. To-MAY-to, to-MAH-to, or something like that. Kelly, directly now... > That said ... I don't really care what we call it. If we do decide to=20 > go with "protocol", it probably would make sense to rename the=20 > draft-ietf-scim-api draft to something else. The title of the document says "protocol", and at this point it's not worth= the trouble to change the filename. The filename will disappear (except i= n the document history in the datatracker) when the RFC is published anyway= . Phil says... > Ok. I see your distinction. You are defining "API" as exclusive to=20 > programming (how one accesses a protocol in code). Right: Application Programming Interface. > My distinction was really in the layers: bits in the app layer (e.g.=20 > payload) vs. bits related to a protocol on a network (IP). In the IETF, at least, we refer to bits-on-the-wire at every layer as "prot= ocol". IP is a protocol, BGP is a protocol, TCP is a protocol, SMTP and HT= TP are protocols, and various things built on HTTP are (higher layer) proto= cols. > I will make it consistent around protocol then. T'anks! Barry _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From nobody Wed Jul 9 12:19:26 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03831A8BAF for ; Wed, 9 Jul 2014 12:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrhcPVnrRh2o for ; Wed, 9 Jul 2014 12:19:23 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 827981A041D for ; Wed, 9 Jul 2014 12:19:23 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s69JJMAY011350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 9 Jul 2014 19:19:22 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s69JJLb8018588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 9 Jul 2014 19:19:21 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s69JJKNg015623 for ; Wed, 9 Jul 2014 19:19:20 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 09 Jul 2014 12:19:20 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_785335AF-9C15-452F-9582-D294C0E7C659" Message-Id: <9742E324-359B-40AA-9B40-8A4051A6662B@oracle.com> Date: Wed, 9 Jul 2014 12:19:18 -0700 To: SCIM WG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/T6GMcH6r79szlI5nMsQjm1x1ClI Subject: [scim] ABNF correction in filters X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 19:19:25 -0000 --Apple-Mail=_785335AF-9C15-452F-9582-D294C0E7C659 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 FYI, There is a typo in the ABNF for filters: FILTER =3D attrExp / logExp / valuePath / *1"not" "(" FILTER ")" =85. attrExpr =3D (attrPath SP "pr") / (attrPath SP compareOp SP compValue) Should be: FILTER =3D attrExp / logExp / valuePath / *1"not" "(" FILTER ")" =85. attrExp =3D (attrPath SP "pr") / (attrPath SP compareOp SP compValue) Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_785335AF-9C15-452F-9582-D294C0E7C659 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 FYI,

There is a typo in the ABNF = for filters:

FILTER    =3D attrExp / logExp / valuePath / = *1"not" "(" FILTER ")"
=85.
attrExpr  =3D = (attrPath SP "pr") / (attrPath SP compareOp SP = compValue)

Should be:
FILTER    =3D attrExp = / logExp / valuePath / *1"not" "(" FILTER = ")"
=85.
attrExp  =3D = (attrPath SP "pr") / (attrPath SP compareOp SP = compValue)

= --Apple-Mail=_785335AF-9C15-452F-9582-D294C0E7C659-- From nobody Wed Jul 9 12:26:21 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA711A8BB3 for ; Wed, 9 Jul 2014 12:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtcoIAUI3pW6 for ; Wed, 9 Jul 2014 12:26:15 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B32D1A0BE8 for ; Wed, 9 Jul 2014 12:26:15 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB391.namprd04.prod.outlook.com (10.141.60.150) with Microsoft SMTP Server (TLS) id 15.0.985.8; Wed, 9 Jul 2014 19:26:13 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.59]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.141]) with mapi id 15.00.0980.000; Wed, 9 Jul 2014 19:26:13 +0000 From: Kelly Grizzle To: Phil Hunt , SCIM WG Thread-Topic: [scim] ABNF correction in filters Thread-Index: AQHPm6q1LaqTtiE+90WgdzpyjiDSvpuYH7BQ Date: Wed, 9 Jul 2014 19:26:13 +0000 Message-ID: <732cc736f42e434baec301a64e3d6fa3@BN1PR04MB392.namprd04.prod.outlook.com> References: <9742E324-359B-40AA-9B40-8A4051A6662B@oracle.com> In-Reply-To: <9742E324-359B-40AA-9B40-8A4051A6662B@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 256F8E9C007992256F8FE9 x-originating-ip: [64.134.147.121] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0267E514F9 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(377454003)(69234005)(106356001)(19609705001)(19300405004)(95666004)(77096002)(46102001)(99286002)(105586002)(92566001)(99396002)(79102001)(33646001)(81342001)(31966008)(20776003)(87936001)(64706001)(2656002)(76482001)(15975445006)(74662001)(74502001)(76576001)(107046002)(101416001)(15202345003)(80022001)(16601075003)(107886001)(66066001)(85852003)(19580405001)(19580395003)(83322001)(106116001)(81542001)(21056001)(74316001)(19625215002)(83072002)(16236675004)(85306003)(4396001)(77982001)(86362001)(54356999)(76176999)(50986999)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB391; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_732cc736f42e434baec301a64e3d6fa3BN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/TZmYB8rr-50YDeMZpWAByuB1WcU Subject: Re: [scim] ABNF correction in filters X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 19:26:20 -0000 --_000_732cc736f42e434baec301a64e3d6fa3BN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good catch, Phil. Should we open tickets to track each nit/error or just t= hrow them into revision 8 w/out a ticket? From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Wednesday, July 09, 2014 2:19 PM To: SCIM WG Subject: [scim] ABNF correction in filters FYI, There is a typo in the ABNF for filters: FILTER =3D attrExp / logExp / valuePath / *1"not" "(" FILTER ")" .... attrExpr =3D (attrPath SP "pr") / (attrPath SP compareOp SP compValue) Should be: FILTER =3D attrExp / logExp / valuePath / *1"not" "(" FILTER ")" .... attrExp =3D (attrPath SP "pr") / (attrPath SP compareOp SP compValue) Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_732cc736f42e434baec301a64e3d6fa3BN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Good catch, Phil.  S= hould we open tickets to track each nit/error or just throw them into revis= ion 8 w/out a ticket?

 <= /p>

 <= /p>

From: scim [ma= ilto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, July 09, 2014 2:19 PM
To: SCIM WG
Subject: [scim] ABNF correction in filters

 

FYI,

 

There is a typo in the ABNF for filters:<= /p>

FILTER    =3D attrExp / l= ogExp / valuePath / *1"not" "(" FILTER ")"

….

= attrExpr  =3D (attrPath SP "pr") / (attrPath SP compareOp SP= compValue)

 

Should be:

FILTER    =3D attrExp / l= ogExp / valuePath / *1"not" "(" FILTER ")"

….

= attrExp  =3D (attrPath SP "pr") / (attrPath SP compareOp SP = compValue)

 

Phil

 

@independentid<= /span>

ph= il.hunt@oracle.com

 

 

 

--_000_732cc736f42e434baec301a64e3d6fa3BN1PR04MB392namprd04pro_-- From nobody Wed Jul 9 12:32:02 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07BA1A0403 for ; Wed, 9 Jul 2014 12:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ie9QjnzzzhZC for ; Wed, 9 Jul 2014 12:31:55 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 866361A0370 for ; Wed, 9 Jul 2014 12:31:55 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s69JVsf9024609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Jul 2014 19:31:54 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s69JVrRo016822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jul 2014 19:31:54 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s69JVrdb016817; Wed, 9 Jul 2014 19:31:53 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 09 Jul 2014 12:31:53 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_79FE16BD-C33B-4B8C-9C8A-459EB5D81F9E" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <732cc736f42e434baec301a64e3d6fa3@BN1PR04MB392.namprd04.prod.outlook.com> Date: Wed, 9 Jul 2014 12:31:51 -0700 Message-Id: References: <9742E324-359B-40AA-9B40-8A4051A6662B@oracle.com> <732cc736f42e434baec301a64e3d6fa3@BN1PR04MB392.namprd04.prod.outlook.com> To: Kelly Grizzle X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/NYOH0_vo0w8rfywTDGJkufCTm_w Cc: SCIM WG Subject: [scim] Review plan (was Re: ABNF correction in filters) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 19:32:01 -0000 --Apple-Mail=_79FE16BD-C33B-4B8C-9C8A-459EB5D81F9E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I think in this phase, please just send in a single personal review = document. That will be a lot less traffic on the list. If you think an item will need some discussion, feel free to create = tickets. I=92d rather not do tickets for typos and minor nits. It=92s easy for = me to just run through your review message and transcribe the items to = the document quickly. Is that ok? Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 9, 2014, at 12:26 PM, Kelly Grizzle = wrote: > Good catch, Phil. Should we open tickets to track each nit/error or = just throw them into revision 8 w/out a ticket? > =20 > =20 > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Wednesday, July 09, 2014 2:19 PM > To: SCIM WG > Subject: [scim] ABNF correction in filters > =20 > FYI, > =20 > There is a typo in the ABNF for filters: >=20 > FILTER =3D attrExp / logExp / valuePath / *1"not" "(" FILTER ")" > =85. > attrExpr =3D (attrPath SP "pr") / (attrPath SP compareOp SP = compValue) > =20 > Should be: > FILTER =3D attrExp / logExp / valuePath / *1"not" "(" FILTER ")" > =85. > attrExp =3D (attrPath SP "pr") / (attrPath SP compareOp SP compValue) > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 --Apple-Mail=_79FE16BD-C33B-4B8C-9C8A-459EB5D81F9E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = think in this phase, please just send in a single personal review = document. That will be a lot less traffic on the = list.

If you think an item will need some discussion, = feel free to create tickets.

I=92d rather not = do tickets for typos and minor nits.  It=92s easy for me to just = run through your review message and transcribe the items to the document = quickly.

Is that ok?


On Jul 9, 2014, at 12:26 PM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

Good catch, Phil.  Should we open tickets to = track each nit/error or just throw them into revision 8 w/out a = ticket?

 

 

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, July 09, 2014 2:19 PM
To: SCIM WG
Subject: [scim] ABNF correction in filters

 

FYI,

 

There is a typo in the ABNF for = filters:


FILTER    =3D= attrExp / logExp / valuePath / *1"not" "(" FILTER ")"

=85.

attrExpr  =3D (attrPath SP "pr") / (attrPath SP = compareOp SP compValue)

 

Should be:

FILTER    =3D= attrExp / logExp / valuePath / *1"not" "(" FILTER ")"

=85.

attrExp  =3D (attrPath SP "pr") / (attrPath SP compareOp = SP compValue)

 

 

 

 


= --Apple-Mail=_79FE16BD-C33B-4B8C-9C8A-459EB5D81F9E-- From nobody Wed Jul 9 12:41:20 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9FC1A0418 for ; Wed, 9 Jul 2014 12:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWqC5frZkKLh for ; Wed, 9 Jul 2014 12:41:12 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0140.outbound.protection.outlook.com [207.46.163.140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39D991A02FE for ; Wed, 9 Jul 2014 12:41:12 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB391.namprd04.prod.outlook.com (10.141.60.150) with Microsoft SMTP Server (TLS) id 15.0.985.8; Wed, 9 Jul 2014 19:41:09 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.59]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.141]) with mapi id 15.00.0980.000; Wed, 9 Jul 2014 19:41:10 +0000 From: Kelly Grizzle To: Phil Hunt Thread-Topic: Review plan (was Re: [scim] ABNF correction in filters) Thread-Index: AQHPm6xzb/4bJ+ZP/kSzBVbtDku7FJuYJAJg Date: Wed, 9 Jul 2014 19:41:09 +0000 Message-ID: References: <9742E324-359B-40AA-9B40-8A4051A6662B@oracle.com> <732cc736f42e434baec301a64e3d6fa3@BN1PR04MB392.namprd04.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 257D37C7007992257D3914 x-originating-ip: [64.134.147.121] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0267E514F9 x-forefront-antispam-report: SFV:NSPM; SFS:(52044002)(69234005)(189002)(199002)(24454002)(377454003)(66066001)(80022001)(15202345003)(16601075003)(19580405001)(85852003)(76576001)(101416001)(107046002)(4396001)(16236675004)(85306003)(83072002)(86362001)(54356999)(76176999)(50986999)(77982001)(106116001)(81542001)(83322001)(19580395003)(19625215002)(21056001)(74316001)(99396002)(105586002)(92566001)(79102001)(81342001)(33646001)(110136001)(106356001)(19300405004)(19609705001)(46102001)(77096002)(99286002)(95666004)(74662001)(15975445006)(74502001)(20776003)(87936001)(31966008)(2656002)(76482001)(64706001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB391; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_b8b27cea620e4d5eadfbb08d2203f37dBN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/xG8NG9v2L9ccr3WwNZeezgwruL4 Cc: SCIM WG Subject: Re: [scim] Review plan (was Re: ABNF correction in filters) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 19:41:18 -0000 --_000_b8b27cea620e4d5eadfbb08d2203f37dBN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Less red tape. Sounds Bueno. From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Wednesday, July 09, 2014 2:32 PM To: Kelly Grizzle Cc: SCIM WG Subject: Review plan (was Re: [scim] ABNF correction in filters) I think in this phase, please just send in a single personal review documen= t. That will be a lot less traffic on the list. If you think an item will need some discussion, feel free to create tickets= . I'd rather not do tickets for typos and minor nits. It's easy for me to ju= st run through your review message and transcribe the items to the document= quickly. Is that ok? Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 9, 2014, at 12:26 PM, Kelly Grizzle > wrote: Good catch, Phil. Should we open tickets to track each nit/error or just t= hrow them into revision 8 w/out a ticket? From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Wednesday, July 09, 2014 2:19 PM To: SCIM WG Subject: [scim] ABNF correction in filters FYI, There is a typo in the ABNF for filters: FILTER =3D attrExp / logExp / valuePath / *1"not" "(" FILTER ")" .... attrExpr =3D (attrPath SP "pr") / (attrPath SP compareOp SP compValue) Should be: FILTER =3D attrExp / logExp / valuePath / *1"not" "(" FILTER ")" .... attrExp =3D (attrPath SP "pr") / (attrPath SP compareOp SP compValue) Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_b8b27cea620e4d5eadfbb08d2203f37dBN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Less red tape.  Soun= ds Bueno. 

 <= /p>

From: Phil Hun= t [mailto:phil.hunt@oracle.com]
Sent: Wednesday, July 09, 2014 2:32 PM
To: Kelly Grizzle
Cc: SCIM WG
Subject: Review plan (was Re: [scim] ABNF correction in filters)

 

I think in this phase, please just send in a single = personal review document. That will be a lot less traffic on the list.=

 

If you think an item will need some discussion, feel= free to create tickets.

 

I’d rather not do tickets for typos and minor = nits.  It’s easy for me to just run through your review message = and transcribe the items to the document quickly.

 

Is that ok?

 

Phil

 

@independentid<= /span>

ph= il.hunt@oracle.com

 

 

 

On Jul 9, 2014, at 12:26 PM, Kelly Grizzle <kelly.grizzle@sailpoint.com&g= t; wrote:



Good catch, Phil.  S= hould we open tickets to track each nit/error or just throw them into revis= ion 8 w/out a ticket?

 <= /p>

 <= /p>

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, July 09, 2014 2:19 PM
To: SCIM WG
Subject: [scim] ABNF correction in filters

 

FYI,

 

There is a typo in the ABNF for filters:<= /p>

FILTER    =3D attrExp / l= ogExp / valuePath / *1"not" "(" FILTER ")"

….

= attrExpr  =3D (attrPath SP "pr") / (attrPath SP compareOp SP= compValue)

 

Should be:

FILTER    =3D attrExp / l= ogExp / valuePath / *1"not" "(" FILTER ")"

….

= attrExp  =3D (attrPath SP "pr") / (attrPath SP compareOp SP = compValue)

 

 

 

 

 

--_000_b8b27cea620e4d5eadfbb08d2203f37dBN1PR04MB392namprd04pro_-- From nobody Wed Jul 9 12:55:59 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D18E1A0463 for ; Wed, 9 Jul 2014 12:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmaVVINHubw9 for ; Wed, 9 Jul 2014 12:55:56 -0700 (PDT) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 130981A0415 for ; Wed, 9 Jul 2014 12:55:55 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id b8so5329412lan.40 for ; Wed, 09 Jul 2014 12:55:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QgvfVUcCT2xSY9s93wmxBAC/C6GaUMNJBewPRi94AK0=; b=lRak9y3mzT10xsWGYOKhc9BjhN8mWJqB7U47GGmjHNqqP15W5foYk9yVU5sfHd9ipm HHNtx4fRDMLtBXrWwDF3oWiIdQ6NMjXvZtaGkyx3vgr0Bqjp40kOLF9nnorazpV1RAIH KJJ8rZUTL6j+VaPLMsGlKm28jXlg7RXF0vAvwIJsQUL5y5cuXPyFDoHaz25q643QvetL 83bxeGs7bBRIyZHSR6jUAkHYsQku67Vsd+viT3lHPf002FkbbIjSMGkDXW5f9uMFMQzT DBCUo4f1VWTGwOKPIPiq0meWwBz9Z9aa7VPK6vGxf0vjxo8WyQFtCOFykPUasQgh87kF voMw== X-Gm-Message-State: ALoCoQlEWHgT4Xsa05m8sx0xg9xrBodGtsRvo+LISqtt216mr76fcrOSso8P9i4VeyeBqhlKKo02 X-Received: by 10.152.37.99 with SMTP id x3mr13490042laj.55.1404935754112; Wed, 09 Jul 2014 12:55:54 -0700 (PDT) Received: from [10.0.0.115] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id a7sm4839791lae.37.2014.07.09.12.55.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Jul 2014 12:55:53 -0700 (PDT) Message-ID: <53BD9E48.5060306@mnt.se> Date: Wed, 09 Jul 2014 21:55:52 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: scim@ietf.org References: <9742E324-359B-40AA-9B40-8A4051A6662B@oracle.com> <732cc736f42e434baec301a64e3d6fa3@BN1PR04MB392.namprd04.prod.outlook.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/OOL39B7QOJBu5WBnU8V-pkv2Y-k Subject: Re: [scim] Review plan (was Re: ABNF correction in filters) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 19:55:58 -0000 On 2014-07-09 21:31, Phil Hunt wrote: > I think in this phase, please just send in a single personal review > document. That will be a lot less traffic on the list. > > If you think an item will need some discussion, feel free to create tickets. > > I’d rather not do tickets for typos and minor nits. It’s easy for me to > just run through your review message and transcribe the items to the > document quickly. > > Is that ok? Just make sure everything gets onto the list! From nobody Sun Jul 13 11:42:56 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE3E1A00D1 for ; Sun, 13 Jul 2014 11:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.022 X-Spam-Level: X-Spam-Status: No, score=-0.022 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbJ-Mw6mTaOz for ; Sun, 13 Jul 2014 11:42:54 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D72BA1A00CD for ; Sun, 13 Jul 2014 11:42:53 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s6DIgquP018457 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 13 Jul 2014 20:42:52 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id s6DIgnsw006765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 13 Jul 2014 20:42:52 +0200 (CEST) X-Footer: c3VuZXQuc2U= Received: from [172.20.10.3] ([2.67.51.205]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.2.4) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128 bits)) for scim@ietf.org; Sun, 13 Jul 2014 20:42:47 +0200 Message-ID: <53C2D324.8070008@sunet.se> Date: Sun, 13 Jul 2014 20:42:44 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "scim@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09MpSGQUA - 5fa8e20103c8 - 20140713 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/scim/87FNjkc5-dNW9gyOEanZjwj6X6o Subject: [scim] agenda for Toronto X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 18:42:54 -0000 Folks, Its pretty basic: we meet on Wednesday after lunch in Salon A to get as close to WGLC-ready core documents as we possibly can. This is the agenda so far: If anyone could do a quick status on the use-case document that would be good. Any other agenda requests? Cheers Leif ---- Agenda for SCIM IETF90 - Note Well & Agenda Bashing (5min) - core document status and issue progress (rest) - draft-ietf-scim-api-07 - draft-ietf-scim-core-schema-06 From nobody Sun Jul 13 19:27:54 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E36E1A0277 for ; Sun, 13 Jul 2014 19:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmcNiPDzX0lq for ; Sun, 13 Jul 2014 19:27:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 976F11A0276 for ; Sun, 13 Jul 2014 19:27:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJX78130; Mon, 14 Jul 2014 02:27:47 +0000 (GMT) Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 14 Jul 2014 03:27:46 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.128]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Mon, 14 Jul 2014 10:27:42 +0800 From: Likepeng To: Leif Johansson , "scim@ietf.org" Thread-Topic: [scim] agenda for Toronto Thread-Index: AQHPnsrTSnYZntsoYECtyXqD19WDopue0vyA Date: Mon, 14 Jul 2014 02:27:41 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F258177736@SZXEMA501-MBS.china.huawei.com> References: <53C2D324.8070008@sunet.se> In-Reply-To: <53C2D324.8070008@sunet.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/scim/eNAvoqVfndhoZxVUVUP_7ZIRlWM Subject: Re: [scim] agenda for Toronto X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 02:27:50 -0000 PiBJZiBhbnlvbmUgY291bGQgZG8gYSBxdWljayBzdGF0dXMgb24gdGhlIHVzZS1jYXNlIGRvY3Vt ZW50IHRoYXQgd291bGQgYmUgZ29vZC4NCg0KWWVzLCBJIGNhbi4NCg0KVGhhbmtzLA0KDQpLaW5k IFJlZ2FyZHMNCktlcGVuZw0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IHNjaW0g W21haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gTGVpZiBKb2hhbnNzb24NCj4gt6LL zcqxvOQ6IDIwMTTE6jfUwjE0yNUgMjo0Mw0KPiDK1bz+yMs6IHNjaW1AaWV0Zi5vcmcNCj4g1vfM 4jogW3NjaW1dIGFnZW5kYSBmb3IgVG9yb250bw0KPiANCj4gDQo+IEZvbGtzLA0KPiANCj4gSXRz IHByZXR0eSBiYXNpYzogd2UgbWVldCBvbiBXZWRuZXNkYXkgYWZ0ZXIgbHVuY2ggaW4gU2Fsb24g QSB0byBnZXQgYXMgY2xvc2UgdG8NCj4gV0dMQy1yZWFkeSBjb3JlIGRvY3VtZW50cyBhcyB3ZSBw b3NzaWJseSBjYW4uIFRoaXMgaXMgdGhlIGFnZW5kYSBzbyBmYXI6DQo+IA0KPiBJZiBhbnlvbmUg Y291bGQgZG8gYSBxdWljayBzdGF0dXMgb24gdGhlIHVzZS1jYXNlIGRvY3VtZW50IHRoYXQgd291 bGQgYmUNCj4gZ29vZC4NCj4gDQo+IEFueSBvdGhlciBhZ2VuZGEgcmVxdWVzdHM/DQo+IA0KPiAJ Q2hlZXJzIExlaWYNCj4gDQo+IC0tLS0NCj4gDQo+IEFnZW5kYSBmb3IgU0NJTSBJRVRGOTANCj4g DQo+IC0gTm90ZSBXZWxsICYgQWdlbmRhIEJhc2hpbmcgKDVtaW4pDQo+IC0gY29yZSBkb2N1bWVu dCBzdGF0dXMgYW5kIGlzc3VlIHByb2dyZXNzIChyZXN0KQ0KPiAgIC0gZHJhZnQtaWV0Zi1zY2lt LWFwaS0wNw0KPiAgIC0gZHJhZnQtaWV0Zi1zY2ltLWNvcmUtc2NoZW1hLTA2DQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzY2ltIG1haWxp bmcgbGlzdA0KPiBzY2ltQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2NpbQ0K From nobody Mon Jul 14 08:57:27 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9811A0AB5; Mon, 14 Jul 2014 08:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8DwHDAPGZaM; Mon, 14 Jul 2014 08:57:18 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0144.outbound.protection.outlook.com [207.46.163.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFE081A0AB0; Mon, 14 Jul 2014 08:57:17 -0700 (PDT) Received: from DM2PR03CA010.namprd03.prod.outlook.com (10.141.52.158) by BL2PR03MB097.namprd03.prod.outlook.com (10.255.230.15) with Microsoft SMTP Server (TLS) id 15.0.985.8; Mon, 14 Jul 2014 15:57:15 +0000 Received: from BN1AFFO11FD058.protection.gbl (2a01:111:f400:7c10::154) by DM2PR03CA010.outlook.office365.com (2a01:111:e400:2414::30) with Microsoft SMTP Server (TLS) id 15.0.985.8 via Frontend Transport; Mon, 14 Jul 2014 15:57:14 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD058.mail.protection.outlook.com (10.58.53.73) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Mon, 14 Jul 2014 15:57:14 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0195.002; Mon, 14 Jul 2014 15:56:36 +0000 From: Mike Jones To: "jose@ietf.org" , "oauth@ietf.org" , "scim@ietf.org" Thread-Topic: OpenID Meeting at IETF 90 Thread-Index: Ac+ffDHCYP2TSxQERm6q/OBVg43Xpw== Date: Mon, 14 Jul 2014 15:56:34 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADA8D1D@TK5EX14MBXC294.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439ADA8D1DTK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(448002)(199002)(189002)(85326001)(66066001)(15975445006)(229853001)(19300405004)(6806004)(99396002)(19625215002)(86612001)(77982001)(55846006)(107886001)(104016003)(33656002)(83072002)(107046002)(85306003)(92566001)(81542001)(86362001)(64706001)(80022001)(50986999)(87936001)(2656002)(79102001)(4396001)(97736001)(31966008)(85852003)(84676001)(84326002)(15202345003)(71186001)(20776003)(512954002)(74502001)(74662001)(81342001)(16236675004)(19580395003)(68736004)(83322001)(76482001)(81156004)(77096002)(26826002)(106466001)(92726001)(2201001)(46102001)(69596002)(44976005)(54356999)(95666004)(21056001)(19617315012); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB097; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 02723F29C4 Received-SPF: PermError (: domain of microsoft.com used an invalid SPF mechanism) Authentication-Results: spf=permerror (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/zrVZhBAUL4f7XhSGrf4z7lZBLPM Subject: [scim] OpenID Meeting at IETF 90 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 15:57:20 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439ADA8D1DTK5EX14MBXC294r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There will be an OpenID meeting at IETF 90 on Sunday from 1-4. If you're i= nterested, please register at http://openid-ietf-90.eventbrite.com/. -- Mike --_000_4E1F6AAD24975D4BA5B16804296739439ADA8D1DTK5EX14MBXC294r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There will be an OpenID m= eeting at IETF 90 on Sunday from 1-4.  If you’re interested, ple= ase register at http://openid-ietf= -90.eventbrite.com/.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     -- Mike

 <= /p>

--_000_4E1F6AAD24975D4BA5B16804296739439ADA8D1DTK5EX14MBXC294r_-- From nobody Mon Jul 14 11:00:33 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930221B2794 for ; Mon, 14 Jul 2014 11:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AFgcBGpJiyS for ; Mon, 14 Jul 2014 11:00:29 -0700 (PDT) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E922A1AD62A for ; Mon, 14 Jul 2014 11:00:28 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id u57so2217311wes.24 for ; Mon, 14 Jul 2014 11:00:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=O/zycqr7tIjUQYzy4Tz+ny0iSM+3tG+TQBQO1VAf1WM=; b=TrhJKkHceJTtKNmT/HZbofeWDVax6VkRsuQO22vZ9KpEDHudvz/5hNlZsy6L0oapb0 OmDK+5p4USv8j6mLpZC0Mkpp/h0CnA+JX6Y3EvpVPNtZugpC6IKLh/j+14moNUM9J4fh Li3BpjDpW/WbdNMLAVgINPviWz72T+JpX6ddW5KBtT9vnEN3+pnJGAcX+c3FUYF1ihgn TNmn4FrEprpbYB8sR2S7topwAxa1tKwlSIYzOhaxN6fogHD+4xVge1yxzmF/J2rqnULF 9UJZ7SJ6Vm0971WVJbvIXUJeLzSUetvA/UrwMdBm1nWExZkq49zogbhXLYyfZAA0+7CL E8aQ== X-Gm-Message-State: ALoCoQnCf4IkIoY24fbBiPQhi4t0TmGaFt2aizf+DJstFbwV60PLeaj+H+RLiVQPuemL/B1TZp2a X-Received: by 10.194.190.78 with SMTP id go14mr4941699wjc.128.1405360827449; Mon, 14 Jul 2014 11:00:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.119.6 with HTTP; Mon, 14 Jul 2014 11:00:07 -0700 (PDT) From: Ian Glazer Date: Mon, 14 Jul 2014 11:00:07 -0700 Message-ID: To: "scim@ietf.org WG" Content-Type: multipart/alternative; boundary=047d7bb046bce6d31604fe2b1084 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/aJSoN50mAQYoNh531_ZBp7WcUYE Subject: [scim] Comments so sections 1 through 3.3 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 18:00:31 -0000 --047d7bb046bce6d31604fe2b1084 Content-Type: text/plain; charset=UTF-8 Here are my early comments on the above sections. I'll grind through more of this a bit later. 1.1 - "identity service providers and client" - This is a little confusing. Do we mean identity providers and consumers? providers of identity services and organizations that consume those services? 1.3 - URL versus URI - There might be a bit of a inconsistency here. 2. - The section is titled "Authentication and Authorization" but authorization isn't directly addressed. The sentence "Appropriate security considerations of the selected authentication and authorization schemes SHOULD be taken" isn't actionable - it is a motherhood and apple pie statement. Do we want to specifically mention scopes as an authorization mechanism? Do we just want to cut "Authorization" from the section header? 3. API - Did we decided whether SCIM is an API or a protocol? For consistency-sake, the title of this section and the first sentence may need to change accordingly. 3. POST - "or bulk modify resources" - Bulk? I thought that bulk was off the table for this draft? 3. PUT - The draft reads "PUT SHOULD NOT be used to create new resources." Should that SHOULD actually be a MUST? 3. API Table - minor nit - only some of the sections are properly linked in the PDF 3. API Table - /Bulk - I thought we weren't dealing with Bulk for v2 and were going to handle it via profile later 3.1 - "Successful resource creation..." - It is unclear from the second sentence whether the entire object MUST be returned or can the server simply return back a pointer to the newly created object? 3.1 - Is the server required to return a Location header when a resource is successfully created? Text does not make that clear. 3.1.1. - Just a clarification - "SHALL be set by the service provider" - in this case service provider means SCIM server and not the client, is that correct? 3.2 Consistency question - Query or Search? 3.2.2 Consistency question - it appears that this draft refers to "service providers," "Providers," and "servers" - does this need to be cleaned up and made consistent? 3.2.2.1 - Do we really want to allow a search against the server root that would result is all objects being returned? Seems like we ought to endorse a pattern of querying resourceTypes and then a specific resourceType is a better way to go. 3.2.2.2 - What happens if someone includes a "ge" search against a non-numeric or non-date type field? The next isn't clear about a failure condition. 3.2.2.3 - Primary attributed - it isn't clear from the text what a primary attribute is. 3.2.2.5 - Meta-question - how does a SCIM server indicate whether it supports attributes and excludedAttributes to be returned (or not) for a Query? 3.2.3 - Figure 2 - the example doesn't use a meta.resourceType attribute which I think it should to indicate a best practice. 3.3.1 - HTTP PUT "SHOULD NOT" or "MUST NOT" be used to create new resources? 3.3.1 - "If an attribute is required..." - What if the attribute's value isn't going to change? Does it still need to be sent along? 3.3.1 - "Attributes whose mutability is 'readWrite.' This paragraph seem very squishy. The server is afforded a lot of latitude which the client may not be aware of. Should be more prescriptive? Attributes that are omitted are not changed? 3.3.2.1 - I'd move the paragraph before the example up before the list of possible outcomes. 3.3.2.2 - I get what happens here but there could be confusion as to whether Remove sets a value to "null" or not. Is removing an attribute equivalent to nulling it? 3.3.2.2 - What about mutability? If I attempt to remove a readOnly, can I? What about "required" attributes? 3.3.2.3 - What about mutability? -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --047d7bb046bce6d31604fe2b1084 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here are my early comments on the above sections. I'll= grind through more of this a bit later.

1.1 - &quo= t;identity service providers and client" - This is a little confusing.= Do we mean identity providers and consumers? providers of identity service= s and organizations that consume those services?

1.3 - URL versus URI - There might be a bit of a incons= istency here.

2. - The section is titled "Aut= hentication and Authorization" but authorization isn't directly ad= dressed. The sentence "Appropriate security considerations of the sele= cted authentication and authorization schemes SHOULD be taken" isn'= ;t actionable - it is a motherhood and apple pie statement. Do we want to s= pecifically mention scopes as an authorization mechanism? Do we just want t= o cut "Authorization" from the section header?

3. API - Did we decided whether SCIM is an API or a pro= tocol? For consistency-sake, the title of this section and the first senten= ce may need to change accordingly.

3. POST - "= ;or bulk modify resources" - Bulk? I thought that bulk was off the tab= le for this draft?

3. PUT - The draft reads "PUT SHOULD NOT be used t= o create new resources." Should that SHOULD actually be a MUST?
<= div>
3. API Table - minor nit - only some of the sections are= properly linked in the PDF

3. API Table - /Bulk - I thought we weren't dealing= with Bulk for v2 and were going to handle it via profile later
<= br>
3.1 - "Successful resource creation..." - It is unc= lear from the second sentence whether the entire object MUST be returned or= can the server simply return back a pointer to the newly created object?

3.1 - Is the server required to return a Location heade= r when a resource is successfully created? Text does not make that clear.

3.1.1. - Just a clarification - "SHALL be set = by the service provider" - in this case service provider means SCIM se= rver and not the client, is that correct?

3.2 Consistency question - Query or Search?
<= br>
3.2.2 Consistency question - it appears that this draft refer= s to "service providers," "Providers," and "server= s" - does this need to be cleaned up and made consistent?

3.2.2.1 - Do we really want to allow a search against t= he server root that would result is all objects being returned? Seems like = we ought to endorse a pattern of querying resourceTypes and then a specific= resourceType is a better way to go.

3.2.2.2 - What happens if someone includes a "ge&q= uot; search against a non-numeric or non-date type field? The next isn'= t clear about a failure condition.

3.2.2.3 - Prima= ry attributed - it isn't clear from the text what a primary attribute i= s.

3.2.2.5 - Meta-question - how does a SCIM server indica= te whether it supports attributes and excludedAttributes to be returned (or= not) for a Query?

3.2.3 - Figure 2 - the example = doesn't use a meta.resourceType attribute which I think it should to in= dicate a best practice.

3.3.1 - HTTP PUT "SHOULD NOT" or "MUST N= OT" be used to create new resources?

3.3.1 - = "If an attribute is required..." - What if the attribute's va= lue isn't going to change? Does it still need to be sent along?

3.3.1 - "Attributes whose mutability is 'readW= rite.' This paragraph seem very squishy. The server is afforded a lot o= f latitude which the client may not be aware of. Should be more prescriptiv= e? Attributes that are omitted are not changed?

3.3.2.1 - I'd move the paragraph before the example= up before the list of possible outcomes.

3.3.2.2 = - I get what happens here but there could be confusion as to whether Remove= sets a value to "null" or not. Is removing an attribute equivale= nt to nulling it?

3.3.2.2 - What about mutability? If I attempt to remove= a readOnly, can I? What about "required" attributes?
<= br>
3.3.2.3 - What about mutability?


--
Ian Glazer
Senior Dire= ctor, Identity
+1 202 255 3166
--047d7bb046bce6d31604fe2b1084-- From nobody Mon Jul 14 15:55:01 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5C51A0193 for ; Mon, 14 Jul 2014 15:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kj3VF2-XDcNL for ; Mon, 14 Jul 2014 15:54:55 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5E5C1A0191 for ; Mon, 14 Jul 2014 15:54:55 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6EMssh7007356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Jul 2014 22:54:54 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6EMsqE7000040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2014 22:54:53 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s6EMsp77011355; Mon, 14 Jul 2014 22:54:52 GMT Received: from [10.1.1.191] (/64.114.125.226) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 14 Jul 2014 15:54:46 -0700 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-293C33B8-A1BA-4E50-B02F-C250F257375F Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D257) From: Phil Hunt Date: Mon, 14 Jul 2014 15:54:31 -0700 To: Ian Glazer X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/yseB-7UL6lF9waprdINVoAQDm9E Cc: "scim@ietf.org WG" Subject: Re: [scim] Comments so sections 1 through 3.3 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 22:54:58 -0000 --Apple-Mail-293C33B8-A1BA-4E50-B02F-C250F257375F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Ian Thanks for all the comments! I will look at in more detail when I get back f= rom vacation.=20 Regarding protocol vs api, the advice I received was we should call this a p= rotocol as api is associate with programming not over the wire semantics.=20= Only real issue is the name of the document itself. This will be one of the i= ssues to sort out in Toronto for sure! Thanks again!=20 Phil > On Jul 14, 2014, at 11:00, Ian Glazer wrote: >=20 > Here are my early comments on the above sections. I'll grind through more o= f this a bit later. >=20 > 1.1 - "identity service providers and client" - This is a little confusing= . Do we mean identity providers and consumers? providers of identity service= s and organizations that consume those services? >=20 > 1.3 - URL versus URI - There might be a bit of a inconsistency here. >=20 > 2. - The section is titled "Authentication and Authorization" but authoriz= ation isn't directly addressed. The sentence "Appropriate security considera= tions of the selected authentication and authorization schemes SHOULD be tak= en" isn't actionable - it is a motherhood and apple pie statement. Do we wan= t to specifically mention scopes as an authorization mechanism? Do we just w= ant to cut "Authorization" from the section header? >=20 > 3. API - Did we decided whether SCIM is an API or a protocol? For consiste= ncy-sake, the title of this section and the first sentence may need to chang= e accordingly. >=20 > 3. POST - "or bulk modify resources" - Bulk? I thought that bulk was off t= he table for this draft? >=20 > 3. PUT - The draft reads "PUT SHOULD NOT be used to create new resources."= Should that SHOULD actually be a MUST? >=20 > 3. API Table - minor nit - only some of the sections are properly linked i= n the PDF >=20 > 3. API Table - /Bulk - I thought we weren't dealing with Bulk for v2 and w= ere going to handle it via profile later >=20 > 3.1 - "Successful resource creation..." - It is unclear from the second se= ntence whether the entire object MUST be returned or can the server simply r= eturn back a pointer to the newly created object? >=20 > 3.1 - Is the server required to return a Location header when a resource i= s successfully created? Text does not make that clear. >=20 > 3.1.1. - Just a clarification - "SHALL be set by the service provider" - i= n this case service provider means SCIM server and not the client, is that c= orrect? >=20 > 3.2 Consistency question - Query or Search? >=20 > 3.2.2 Consistency question - it appears that this draft refers to "service= providers," "Providers," and "servers" - does this need to be cleaned up an= d made consistent? >=20 > 3.2.2.1 - Do we really want to allow a search against the server root that= would result is all objects being returned? Seems like we ought to endorse a= pattern of querying resourceTypes and then a specific resourceType is a bet= ter way to go. >=20 > 3.2.2.2 - What happens if someone includes a "ge" search against a non-num= eric or non-date type field? The next isn't clear about a failure condition.= >=20 > 3.2.2.3 - Primary attributed - it isn't clear from the text what a primary= attribute is. >=20 > 3.2.2.5 - Meta-question - how does a SCIM server indicate whether it suppo= rts attributes and excludedAttributes to be returned (or not) for a Query? >=20 > 3.2.3 - Figure 2 - the example doesn't use a meta.resourceType attribute w= hich I think it should to indicate a best practice. >=20 > 3.3.1 - HTTP PUT "SHOULD NOT" or "MUST NOT" be used to create new resource= s? >=20 > 3.3.1 - "If an attribute is required..." - What if the attribute's value i= sn't going to change? Does it still need to be sent along? >=20 > 3.3.1 - "Attributes whose mutability is 'readWrite.' This paragraph seem v= ery squishy. The server is afforded a lot of latitude which the client may n= ot be aware of. Should be more prescriptive? Attributes that are omitted are= not changed? >=20 > 3.3.2.1 - I'd move the paragraph before the example up before the list of p= ossible outcomes. >=20 > 3.3.2.2 - I get what happens here but there could be confusion as to wheth= er Remove sets a value to "null" or not. Is removing an attribute equivalent= to nulling it? >=20 > 3.3.2.2 - What about mutability? If I attempt to remove a readOnly, can I?= What about "required" attributes? >=20 > 3.3.2.3 - What about mutability? >=20 >=20 > --=20 > Ian Glazer > Senior Director, Identity > +1 202 255 3166 > @iglazer > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-293C33B8-A1BA-4E50-B02F-C250F257375F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ian

Thanks fo= r all the comments! I will look at in more detail when I get back from vacat= ion. 

Regarding protocol vs api, the advice I r= eceived was we should call this a protocol as api is associate with programm= ing not over the wire semantics. 

Only real is= sue is the name of the document itself. This will be one of the issues to so= rt out in Toronto for sure!

Thanks again! 

<= div>Phil

On Jul 14, 2014, at 11:00, Ian Glazer <iglazer@salesforce.com> wrote:

=
Here are my early comm= ents on the above sections. I'll grind through more of this a bit later.
1.1 - "identity service providers and client" - This is= a little confusing. Do we mean identity providers and consumers? providers o= f identity services and organizations that consume those services?

1.3 - URL versus URI - There might be a bit of a inconsi= stency here.

2. - The section is titled "Authentica= tion and Authorization" but authorization isn't directly addressed. The sent= ence "Appropriate security considerations of the selected authentication and= authorization schemes SHOULD be taken" isn't actionable - it is a motherhoo= d and apple pie statement. Do we want to specifically mention scopes as an a= uthorization mechanism? Do we just want to cut "Authorization" from the sect= ion header?

3. API - Did we decided whether SCIM is an API or a prot= ocol? For consistency-sake, the title of this section and the first sentence= may need to change accordingly.

3. POST - "or bulk= modify resources" - Bulk? I thought that bulk was off the table for this dr= aft?

3. PUT - The draft reads "PUT SHOULD NOT be used to crea= te new resources." Should that SHOULD actually be a MUST?

3. API Table - minor nit - only some of the sections are properly lin= ked in the PDF

3. API Table - /Bulk - I thought we weren't dealing with= Bulk for v2 and were going to handle it via profile later

3.1 - "Successful resource creation..." - It is unclear from the sec= ond sentence whether the entire object MUST be returned or can the server si= mply return back a pointer to the newly created object?

3.1 - Is the server required to return a Location header= when a resource is successfully created? Text does not make that clear.

3.1.1. - Just a clarification - "SHALL be set by the s= ervice provider" - in this case service provider means SCIM server and not t= he client, is that correct?

3.2 Consistency question - Query or Search?
3.2.2 Consistency question - it appears that this draft refers t= o "service providers," "Providers," and "servers" - does this need to be cle= aned up and made consistent?

3.2.2.1 - Do we really want to allow a search against th= e server root that would result is all objects being returned? Seems like we= ought to endorse a pattern of querying resourceTypes and then a specific re= sourceType is a better way to go.

3.2.2.2 - What happens if someone includes a "ge" search= against a non-numeric or non-date type field? The next isn't clear about a f= ailure condition.

3.2.2.3 - Primary attributed - it= isn't clear from the text what a primary attribute is.

3.2.2.5 - Meta-question - how does a SCIM server indicat= e whether it supports attributes and excludedAttributes to be returned (or n= ot) for a Query?

3.2.3 - Figure 2 - the example doe= sn't use a meta.resourceType attribute which I think it should to indicate a= best practice.

3.3.1 - HTTP PUT "SHOULD NOT" or "MUST NOT" be used to c= reate new resources?

3.3.1 - "If an attribute is re= quired..." - What if the attribute's value isn't going to change? Does it st= ill need to be sent along?

3.3.1 - "Attributes whose mutability is 'readWrite.' Thi= s paragraph seem very squishy. The server is afforded a lot of latitude whic= h the client may not be aware of. Should be more prescriptive? Attributes th= at are omitted are not changed?

3.3.2.1 - I'd move the paragraph before the example up b= efore the list of possible outcomes.

3.3.2.2 - I ge= t what happens here but there could be confusion as to whether Remove sets a= value to "null" or not. Is removing an attribute equivalent to nulling it?<= /div>

3.3.2.2 - What about mutability? If I attempt to remove a= readOnly, can I? What about "required" attributes?

3.3.2.3 - What about mutability?


--
Ian Glazer
Senior Direc= tor, Identity
+1 202 255 3166
____________________= ___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman= /listinfo/scim
= --Apple-Mail-293C33B8-A1BA-4E50-B02F-C250F257375F-- From nobody Tue Jul 15 08:30:48 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A431A04CD for ; Tue, 15 Jul 2014 08:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InSQOfasR6_H for ; Tue, 15 Jul 2014 08:30:00 -0700 (PDT) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B7F51B28BA for ; Tue, 15 Jul 2014 08:29:35 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id w62so2380626wes.36 for ; Tue, 15 Jul 2014 08:29:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=+Ohv77W/BKAG9qqvC9vocCaFeDdZD8swpww8WC1P6DQ=; b=diMeIL9spzZKJ8XLRI5vHvJVjLYCwVSGS/64vy3KUlqlkTMXgxYxOVztNihT6UqueX LW5t6TUx7XOhwEg72KRKy21CiSNEMgJh8oVVqIN8caxqpMLFOwRxLGkEO6KG1kKjKKlc QYB1LLSKfDJ1fX/kZU/fRLox8L2ddg2AyE6GfcqQ9Xw5bNBviYgJ1mvRTepBeC52y2y1 rl6vd/+ZsECdCjsLg+5wgf/Ay9w32L/N/ce8wfvumHCU9HEjR6HkwrqQgg11qjjkhvhN lAwa9WgwjxRxfQjmbqRAis+8aThznj3pAvX6n6PiH4V5F7M+A+geHF/+ZqtzV+EaTMeA UiFw== X-Gm-Message-State: ALoCoQm8eOLEPtZmXJI7led8rbEBeQbaCwTu2F+hNs2rMxiZkprPICEch3zJOI+aWdXKj5ShI1Tn X-Received: by 10.180.183.167 with SMTP id en7mr6713861wic.6.1405438174480; Tue, 15 Jul 2014 08:29:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.119.6 with HTTP; Tue, 15 Jul 2014 08:29:14 -0700 (PDT) From: Ian Glazer Date: Tue, 15 Jul 2014 08:29:14 -0700 Message-ID: To: "scim@ietf.org WG" Content-Type: multipart/alternative; boundary=001a11c239d424ea0704fe3d13e6 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/bM04m5c71zowz-Kli8daonr21u8 Subject: [scim] Comments for sections 3.4 to the end X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 15:30:22 -0000 --001a11c239d424ea0704fe3d13e6 Content-Type: text/plain; charset=UTF-8 Here's a few more comments: 3.4 Delete - Does an SP who chooses not to permanently delete a resource have to tell the client of that choice? 3.4 Delete conflicts - "SP MUST not consider deleted resource in conflict calculation" - What about situations where the SP requires all userNames to be unique and holds delete accounts to ensure no repetition of userNames? This might cause a problem for Salesforce. 3.5 Bulk - Maybe my memory failed me here but I thought we were carving Bulk out as its own profile to be dealt with later. Given that no one has implemented it I wonder if it doesn't make sense to completely pull it and put it into a future profile. 3.5 Bulk - formatting issue - Page 38 of the pdf. The paragraph beginning "The following example shows how to add..." is formatted like example code not regular text. 3.5 Bulk - formatting issue - Page 40 of the pdf. The paragraph beginning "The following response is returned if an error occurred..." is formatted like example code not regular text. 3.5 Bulk - formatting issue - same problems on pages 41 and 42 as 38 and 40. 3.7 attributes - If "attributes" are specified, it isn't clear if default attributes are also returned along with the minimum set and those specified. I think this needs to say explicitly that default attributes are not returned when "attributes" are specified. 6.4 - Universal Identifiers - ? -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --001a11c239d424ea0704fe3d13e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here's a few more comments:

3.= 4 Delete - Does an SP who chooses not to permanently delete a resource have= to tell the client of that choice?

3.4 Delete con= flicts - "SP MUST not consider deleted resource in conflict calculatio= n" - =C2=A0What about situations where the SP requires all userNames t= o be unique and holds delete accounts to ensure no repetition of userNames?= This might cause a problem for Salesforce.

3.5 Bulk - Maybe my memory failed me here but I thought= we were carving Bulk out as its own profile to be dealt with later. Given = that no one has implemented it I wonder if it doesn't make sense to com= pletely pull it and put it into a future profile.

3.5 Bulk - formatting issue - Page 38 of the pdf. The p= aragraph beginning "The following example shows how to add..." is= formatted like example code not regular text.

3.5 Bulk - formatting issue - Page 40 of the pdf. The paragraph beginning &= quot;The following response is returned if an error occurred..." is fo= rmatted like example code not regular text.

3.5 Bu= lk - formatting issue - same problems on pages 41 and 42 as 38 and 40.

3.7 attributes - If "attributes" are specifie= d, it isn't clear if default attributes are also returned along with th= e minimum set and those specified. I think this needs to say explicitly tha= t default attributes are not returned when "attributes" are speci= fied.

6.4 - Universal Identifiers - ?


--
Ian Glazer
Senior Di= rector, Identity
+1 202 255 3166
--001a11c239d424ea0704fe3d13e6-- From nobody Tue Jul 15 18:12:38 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF441B29D8 for ; Tue, 15 Jul 2014 18:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAOo4nCx-oYz for ; Tue, 15 Jul 2014 18:12:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E43B11B29D6 for ; Tue, 15 Jul 2014 18:12:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKC01072; Wed, 16 Jul 2014 01:12:31 +0000 (GMT) Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Jul 2014 02:12:30 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.128]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Wed, 16 Jul 2014 09:12:28 +0800 From: Likepeng To: "scim@ietf.org" Thread-Topic: Requesting review and comments for use case draft Thread-Index: AQHPitO/TBooaB9vskWBkKvbtCXZk5t2khYQgCt869A= Date: Wed, 16 Jul 2014 01:12:27 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F2581785F4@SZXEMA501-MBS.china.huawei.com> References: <20140618085956.12264.23957.idtracker@ietfa.amsl.com> <34966E97BE8AD64EAE9D3D6E4DEE36F25815CE70@SZXEMA501-MBS.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F25815CE70@SZXEMA501-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/scim/hYVkFM0mLpvMAoBgCB_EW-8d8ig Subject: [scim] Requesting review and comments for use case draft X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 01:12:35 -0000 Hi Mike and Bill, Hope you are doing well. According to our previous meeting notes, you agreed to help to review use c= ase draft: http://www.ietf.org/proceedings/89/minutes/minutes-89-scim >Use Cases draft: K. Lee (name approximate) >-new drafts up. Definitely need reviewers. "Non author reviewers specifi= cally". Mike Jones and Bill Mills raised hands. >-no significant discussion in the room. May we request you to review and send your comments/suggestion to the list = on the latest version of the SCIM use case draft.=20 http://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ Many thanks in advance. Kind Regards Kepeng From nobody Thu Jul 17 11:05:32 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 283811A000F for ; Thu, 17 Jul 2014 11:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.902 X-Spam-Level: X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGla3OBOMVIX for ; Thu, 17 Jul 2014 11:03:59 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D039D1A0043 for ; Thu, 17 Jul 2014 11:03:59 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6HI3vAq031116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Jul 2014 18:03:58 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s6HI3uAT007057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Jul 2014 18:03:57 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6HI3tDj006053; Thu, 17 Jul 2014 18:03:55 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 17 Jul 2014 11:03:55 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <53BD0502.6040405@tarent.de> Date: Thu, 17 Jul 2014 11:03:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8C5A2D5E-0A4D-4572-80ED-8D8B640FD574@oracle.com> References: <53BD0502.6040405@tarent.de> To: =?windows-1252?Q?David_M=F6bius?= X-Mailer: Apple Mail (2.1878.6) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/ipFUNehOlrZAF6L4sKa9qv4rPMA Cc: "scim@ietf.org WG" Subject: Re: [scim] search case insensitiv X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 18:04:03 -0000 David, Sorry for not responding earlier, just getting through my emails from = vacation now. The discoverable server schema tells you whether a particular attribute = is case sensitive or not and tells you how the filter will be compared = (case exact or not). See =93caseExact=94 in = http://tools.ietf.org/html/draft-ietf-scim-core-schema-06#section-10 At present there is no way for an attribute with =93caseExact=94:true to = be compared in a case insensitive way. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 9, 2014, at 2:01 AM, David M=F6bius wrote: > Hello, >=20 > the normal search with scim is cas sensitive since we can't say it is > not. Is their any possibility to say to the server that we want to do = a > case insensitive search? >=20 > by David >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Thu Jul 17 11:56:11 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257D11A0073 for ; Thu, 17 Jul 2014 11:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0Tqwi5J14Cd for ; Thu, 17 Jul 2014 11:52:58 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88DED1A0002 for ; Thu, 17 Jul 2014 11:52:58 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6HIqvqx030302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 17 Jul 2014 18:52:57 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6HIquxn027088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Jul 2014 18:52:56 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6HIquIU027078 for ; Thu, 17 Jul 2014 18:52:56 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 17 Jul 2014 11:52:56 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_5214CEA2-1670-495C-B8B9-4B6FBDBA724A" Message-Id: <57BAE65C-6176-4E31-AFAB-CF6DFE9DDEE4@oracle.com> Date: Thu, 17 Jul 2014 11:52:54 -0700 To: SCIM WG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/uJ-RqK5M1lfEJlRB7OLyy-zc7lk Subject: [scim] Security considerations: sensitive data X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 18:53:00 -0000 --Apple-Mail=_5214CEA2-1670-495C-B8B9-4B6FBDBA724A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 At present we do not have any security considerations for sensitive data = (e.g. passwords). =20 Am thinking we should have some general verbiage around the issues/best = practice around things like passwords that need to be salted/hashed = appropriately. To some implementers as a pure provisioning protocol = there may be no impact. But for those building SCIM on top of a = persistence system (e.g. database), the considerations become important. = There=92s lots of stuff to reference here, especially from the OAuth = Threat Model document as well as LDAP. The other issue is whether this goes in the API or the core-schema draft = (or both). Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_5214CEA2-1670-495C-B8B9-4B6FBDBA724A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 At = present we do not have any security considerations for sensitive data = (e.g. passwords).  

Am thinking we should have = some general verbiage around the issues/best practice around things like = passwords that need to be salted/hashed appropriately.  To some = implementers as a pure provisioning protocol there may be no impact. But = for those building SCIM on top of a persistence system (e.g. database), = the considerations become important. There=92s lots of stuff to = reference here, especially from the OAuth Threat Model document as well = as LDAP.

The other issue is whether this goes = in the API or the core-schema draft (or = both).

= --Apple-Mail=_5214CEA2-1670-495C-B8B9-4B6FBDBA724A-- From nobody Thu Jul 17 16:46:59 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61F61B2892 for ; Thu, 17 Jul 2014 16:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XlaLyP2Op4R for ; Thu, 17 Jul 2014 16:46:53 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF1591B288A for ; Thu, 17 Jul 2014 16:46:52 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6HNkpYk011762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Jul 2014 23:46:52 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6HNkpNY027779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jul 2014 23:46:51 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6HNko64006744; Thu, 17 Jul 2014 23:46:50 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 17 Jul 2014 16:46:50 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_9B744CFA-5112-4706-95B7-8A7D278E11ED" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: Date: Thu, 17 Jul 2014 16:46:48 -0700 Message-Id: <3ADF1D27-C771-4645-814E-324D51353674@oracle.com> References: To: Ian Glazer X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/vAGUBpD9ReoTTtzNHD_d0KOLRW0 Cc: "scim@ietf.org WG" Subject: Re: [scim] Comments so sections 1 through 3.3 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 23:46:56 -0000 --Apple-Mail=_9B744CFA-5112-4706-95B7-8A7D278E11ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ian, Thanks for the thorough walk through. Comments in line below. Thanks for the feedback. Many of these are obvious and will plan to put = them in the document following Toronto (unless I hear objections). = Others I will add to the list of discussion items for Toronto. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 14, 2014, at 11:00 AM, Ian Glazer wrote: > Here are my early comments on the above sections. I'll grind through = more of this a bit later. >=20 > 1.1 - "identity service providers and client" - This is a little = confusing. Do we mean identity providers and consumers? providers of = identity services and organizations that consume those services? How about just =93web service providers and clients=94. The fact that = it is a protocol around identity isn=92t near as important as that it is = an HTTP protocol. >=20 > 1.3 - URL versus URI - There might be a bit of a inconsistency here. Will Fix. I think the issue here is that it must be a URL (accessible = via HTTP) but IETF seems to always want URIs regardless. =20 >=20 > 2. - The section is titled "Authentication and Authorization" but = authorization isn't directly addressed. The sentence "Appropriate = security considerations of the selected authentication and authorization = schemes SHOULD be taken" isn't actionable - it is a motherhood and apple = pie statement. Do we want to specifically mention scopes as an = authorization mechanism? Do we just want to cut "Authorization" from the = section header? I have already attempted to create a better way of describing this: Because SCIM uses HTTP protocol, it does not define a scheme for authentication and authorization. It depends on standard HTTP authentication schemes. It is RECOMMENDED that clients be implemented in such a way that new authentication schemes can be deployed. Implementers SHOULD support existing authentication/ authorization schemes. In particular, OAuth2 [RFC6750] is RECOMMENDED. Appropriate security considerations of the selected authentication and authorization schemes SHOULD be taken. Because this protocol uses HTTP response status codes as the primary means of reporting the result of a request, servers are advised to respond to unauthorized or unauthenticated requests using the 401 response code in accordance with Section 3.1 of [RFC7235]. All examples show an OAuth2 bearer token [RFC6750] (thought it is not required) ; e.g., GET /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1 Host: example.com Authorization: Bearer h480djs93hd8 The context of the request (i.e. the user for whom data is being requested) MUST be inferred by service providers. That said, do we want to get into a standardized authorization model? = Maybe this is something as a future draft specification. Particularly if = we want to talk about a future SCIM Directory specification. >=20 > 3. API - Did we decided whether SCIM is an API or a protocol? For = consistency-sake, the title of this section and the first sentence may = need to change accordingly. Per my previous email. I=92ve had some recommendation that API always = refers to a programming library interface rather than over the wire = semantics. Thus I have begun changing to the SCIM protocol or SCIM HTTP = protocol where appropriate. Note we need to discuss the issue of renaming the SCIM API draft to SCIM = Protocol draft. >=20 > 3. POST - "or bulk modify resources" - Bulk? I thought that bulk was = off the table for this draft? There was some discussion on one of the calls (I can=92t remember if we = followed up on the list). The feeling was that many are beginning to = implement now. We=92d like to keep it in place for now but we agreed it = may not make the final cut. This should be a discussion item for = Toronto. >=20 > 3. PUT - The draft reads "PUT SHOULD NOT be used to create new = resources." Should that SHOULD actually be a MUST? I=92m open to some discussion here. I=92m not sure if there are limited = scenarios whereby the implementation has to allow this. >=20 > 3. API Table - minor nit - only some of the sections are properly = linked in the PDF Ok. Weird. Will take a look. Seems like an xml2rfc issue (the xml = references the same way for each item). >=20 > 3. API Table - /Bulk - I thought we weren't dealing with Bulk for v2 = and were going to handle it via profile later See above >=20 > 3.1 - "Successful resource creation..." - It is unclear from the = second sentence whether the entire object MUST be returned or can the = server simply return back a pointer to the newly created object? Assume you are referring to: Upon successful creation, the response body MUST contain the newly created resource. Maybe it should say =93the newly created service provider representation = of the full resource=94? >=20 > 3.1 - Is the server required to return a Location header when a = resource is successfully created? Text does not make that clear. Agreed it should say this. >=20 > 3.1.1. - Just a clarification - "SHALL be set by the service provider" = - in this case service provider means SCIM server and not the client, is = that correct? In all cases =93service provider=94 means the HTTP service, not the = provider of identity data (the client). Maybe we need more terminology = text in the intro on this point. >=20 > 3.2 Consistency question - Query or Search? Agreed. Any preferences? >=20 > 3.2.2 Consistency question - it appears that this draft refers to = "service providers," "Providers," and "servers" - does this need to be = cleaned up and made consistent? Agreed see above. >=20 > 3.2.2.1 - Do we really want to allow a search against the server root = that would result is all objects being returned? Seems like we ought to = endorse a pattern of querying resourceTypes and then a specific = resourceType is a better way to go. This is regulated by the max results limits. There was a specific = example of being able to search without regard to resource type, or a = specific set of resource types. The use case was a search-as-user-types = scenario where the result was not known to be a user or a group. >=20 > 3.2.2.2 - What happens if someone includes a "ge" search against a = non-numeric or non-date type field? The next isn't clear about a failure = condition. Maybe you mis-read. If anything, I see it doesn=92t say how numeric = comparisons are made. For strings it is the normal lexicographical = comparison. >=20 > 3.2.2.3 - Primary attributed - it isn't clear from the text what a = primary attribute is. Will add a reference to the multi-valued attribute definition where = primary is defined. >=20 > 3.2.2.5 - Meta-question - how does a SCIM server indicate whether it = supports attributes and excludedAttributes to be returned (or not) for a = Query? Not sure what you mean. There=92s no optionality here. >=20 > 3.2.3 - Figure 2 - the example doesn't use a meta.resourceType = attribute which I think it should to indicate a best practice. Sure. Why not. Might be a good way to say how to search both users and = groups. >=20 > 3.3.1 - HTTP PUT "SHOULD NOT" or "MUST NOT" be used to create new = resources? See above. >=20 > 3.3.1 - "If an attribute is required..." - What if the attribute's = value isn't going to change? Does it still need to be sent along? Yes. Since it is a replace, but value must always be supplied - even = when no change. Otherwise it makes missing value logic even more = complex. :-) >=20 > 3.3.1 - "Attributes whose mutability is 'readWrite.' This paragraph = seem very squishy. The server is afforded a lot of latitude which the = client may not be aware of. Should be more prescriptive? Attributes that = are omitted are not changed? The problem here was the issue I raised earlier about understanding the = implied meaning of a missing value: * omitted because client isn=92t aware of it * omitted because the client does not intend to change it * omitted because the client wants to default it * omitted because the client wants to delete it * omitted because the client doesn=92t care The squishiness was a result of trying to give the server some room to = interpret. This probably still needs more discussion. >=20 > 3.3.2.1 - I'd move the paragraph before the example up before the list = of possible outcomes. ok >=20 > 3.3.2.2 - I get what happens here but there could be confusion as to = whether Remove sets a value to "null" or not. Is removing an attribute = equivalent to nulling it? I think we=92ve informally discussed that for scim, null =3D=3D removed. = We should discuss this in Toronto and formalize this in the spec. = Having null equal to removed makes the missing/omitted attribute logic = on PUT etc easier to define. >=20 > 3.3.2.2 - What about mutability? If I attempt to remove a readOnly, = can I? What about "required" attributes? Good point. >=20 > 3.3.2.3 - What about mutability? Agreed. >=20 >=20 > --=20 > Ian Glazer > Senior Director, Identity > +1 202 255 3166 > @iglazer > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_9B744CFA-5112-4706-95B7-8A7D278E11ED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Ian,

Thanks for the = thorough walk through.

Comments in line = below.

Thanks for the feedback. Many of these are = obvious and will plan to put them in the document following Toronto = (unless I hear objections). Others I will add to the list of discussion = items for Toronto.

Phil

On Jul 14, 2014, at 11:00 AM, Ian Glazer <iglazer@salesforce.com> = wrote:

Here are my early comments on the above = sections. I'll grind through more of this a bit = later.

1.1 - "identity service providers and = client" - This is a little confusing. Do we mean identity providers and = consumers? providers of identity services and organizations that consume = those services?

How about = just =93web service providers and clients=94.  The fact that it is = a protocol around identity isn=92t near as important as that it is an = HTTP protocol.

1.3 - URL versus URI - There might be a bit of a = inconsistency here.

Will = Fix. I think the issue here is that it must be a URL (accessible via = HTTP) but IETF seems to always want URIs regardless. =  

2. - The section is titled = "Authentication and Authorization" but authorization isn't directly = addressed. The sentence "Appropriate security considerations of the = selected authentication and authorization schemes SHOULD be taken" isn't = actionable - it is a motherhood and apple pie statement. Do we want to = specifically mention scopes as an authorization mechanism? Do we just = want to cut "Authorization" from the section = header?

I have already = attempted to create a better way of describing this:
   Because SCIM =
uses HTTP protocol, it does not define a scheme for
   authentication and authorization.  It depends on standard HTTP
   authentication schemes.  It is RECOMMENDED that clients be
   implemented in such a way that new authentication schemes can be
   deployed.  Implementers SHOULD support existing authentication/
   authorization schemes.  In particular, OAuth2 [RFC6750] is
   RECOMMENDED.  Appropriate security considerations of the selected
   authentication and authorization schemes SHOULD be taken.  Because
   this protocol uses HTTP response status codes as the primary means of
   reporting the result of a request, servers are advised to respond to
   unauthorized or unauthenticated requests using the 401 response code
   in accordance with Section 3.1 of [RFC7235].

   All examples show an OAuth2 bearer token [RFC6750] (thought it is not
   required) ; e.g.,

   GET /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1
   Host: example.com
   Authorization: Bearer h480djs93hd8

   The context of the request (i.e. the user for whom data is being
   requested) MUST be inferred by service providers.
That = said, do we want to get into a standardized authorization model? =  Maybe this is something as a future draft specification. = Particularly if we want to talk about a future SCIM Directory = specification.


3. API - Did we decided whether SCIM is an API or a = protocol? For consistency-sake, the title of this section and the first = sentence may need to change = accordingly.

Per my = previous email. I=92ve had some recommendation that API always refers to = a programming library interface rather than over the wire semantics. = Thus I have begun changing to the SCIM protocol or SCIM HTTP protocol = where appropriate.

Note we need to discuss the = issue of renaming the SCIM API draft to SCIM Protocol = draft.

3. POST - "or bulk modify = resources" - Bulk? I thought that bulk was off the table for this = draft?

There was some = discussion on one of the calls (I can=92t remember if we followed up on = the list). The feeling was that many are beginning to implement now. = We=92d like to keep it in place for now but we agreed it may not make = the final cut.  This should be a discussion item for = Toronto.

3. PUT - The draft reads "PUT SHOULD NOT be used to = create new resources." Should that SHOULD actually be a = MUST?

I=92m open to some = discussion here. I=92m not sure if there are limited scenarios whereby = the implementation has to allow this.

3. API Table - minor nit - only = some of the sections are properly linked in the = PDF

Ok. Weird. Will take a = look. Seems like an xml2rfc issue (the xml references the same way for = each item).

3. API Table - /Bulk - I thought we weren't dealing = with Bulk for v2 and were going to handle it via profile = later
See above

3.1 - = "Successful resource creation..." - It is unclear from the second = sentence whether the entire object MUST be returned or can the server = simply return back a pointer to the newly created = object?
Assume you are referring = to:
Upon =
successful creation, the response body MUST
   contain the newly created resource.

Maybe it = should say =93the newly created service provider representation of the = full resource=94?

3.1 - Is the server required to return a Location = header when a resource is successfully created? Text does not make that = clear.

Agreed it should say = this.

3.1.1. - Just a clarification - = "SHALL be set by the service provider" - in this case service provider = means SCIM server and not the client, is that = correct?

In all cases = =93service provider=94 means the HTTP service, not the provider of = identity data (the client). Maybe we need more terminology text in the = intro on this point.

3.2 Consistency question - Query or = Search?

Agreed. Any = preferences?

3.2.2 Consistency question - it = appears that this draft refers to "service providers," "Providers," and = "servers" - does this need to be cleaned up and made = consistent?

Agreed see = above.

3.2.2.1 - Do we really want to allow a search = against the server root that would result is all objects being returned? = Seems like we ought to endorse a pattern of querying resourceTypes and = then a specific resourceType is a better way to = go.

This is regulated by = the max results limits. There was a specific example of being able to = search without regard to resource type, or a specific set of resource = types. The use case was a search-as-user-types scenario where the result = was not known to be a user or a group.

3.2.2.2 - What happens if someone includes a "ge" = search against a non-numeric or non-date type field? The next isn't = clear about a failure condition.
Maybe you = mis-read. If anything, I see it doesn=92t say how numeric comparisons = are made. For strings it is the normal lexicographical = comparison.

3.2.2.3 - Primary attributed - it = isn't clear from the text what a primary attribute = is.

Will add a reference to = the multi-valued attribute definition where primary is = defined.

3.2.2.5 - Meta-question - how does a SCIM server = indicate whether it supports attributes and excludedAttributes to be = returned (or not) for a = Query?

Not sure what you = mean. There=92s no optionality here.

3.2.3 - Figure 2 - the example = doesn't use a meta.resourceType attribute which I think it should to = indicate a best = practice.

Sure. Why not. =  Might be a good way to say how to search both users and = groups.

3.3.1 - HTTP PUT "SHOULD NOT" or "MUST NOT" be used = to create new = resources?

See = above.

3.3.1 - "If an attribute is = required..." - What if the attribute's value isn't going to change? Does = it still need to be sent = along?

Yes. Since it is a = replace, but value must always be supplied - even when no change. = Otherwise it makes missing value logic even more complex. = :-)


3.3.1 - "Attributes whose mutability is 'readWrite.' = This paragraph seem very squishy. The server is afforded a lot of = latitude which the client may not be aware of. Should be more = prescriptive? Attributes that are omitted are not = changed?

The problem here = was the issue I raised earlier about understanding the implied meaning = of a missing value:
* omitted because client isn=92t aware of = it
* omitted because the client does not intend to change = it
* omitted because the client wants to default = it
* omitted because the client wants to delete it
* = omitted because the client doesn=92t care

The = squishiness was a result of trying to give the server some room to = interpret.

This probably still needs more = discussion.

3.3.2.1 - I'd move the paragraph before the example = up before the list of possible = outcomes.
ok

3.3.2.2 - I get = what happens here but there could be confusion as to whether Remove sets = a value to "null" or not. Is removing an attribute equivalent to nulling = it?

I think we=92ve = informally discussed that for scim, null =3D=3D removed. We should = discuss this in Toronto and formalize this in the spec.  Having = null equal to removed makes the missing/omitted attribute logic on PUT = etc easier to define.

3.3.2.2 - What about mutability? If I attempt to = remove a readOnly, can I? What about "required" = attributes?

Good = point.

3.3.2.3 - What about = mutability?

Agreed.


--
Ian Glazer
Senior = Director, Identity
+1 202 255 3166
_______________________________________________
scim mailing = list
scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim

= --Apple-Mail=_9B744CFA-5112-4706-95B7-8A7D278E11ED-- From nobody Fri Jul 18 07:06:32 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F79F1B2973 for ; Fri, 18 Jul 2014 07:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDch3RpUgXzH for ; Fri, 18 Jul 2014 07:06:24 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 679AD1B2907 for ; Fri, 18 Jul 2014 07:06:23 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id n15so2839268lbi.4 for ; Fri, 18 Jul 2014 07:06:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=z87EvIMkoiKqtWkgdqr/VWWy6d362mudnDJTqjJFMLQ=; b=Apl1Djqcu+ou0bKME3GrrjLEBnStQAGymzZ2BTMhjbnrhx7lgEnK5HwAYVfGE3lQJw a9Y50boolnixMz8jFQg811309q7TlKi3Z9GJrZQUH8c+Uwrr9rsJH1hbouzYPKEKiUBZ S8vsQs82rO3diE5R6KsDfEs9dQKjOTDI0KwxDOjPK6t8feH4PaeOKQd6xB3AVDaVTse+ He0onfxQPquYxWJ74l+yuOyA0D1gj+uVS2D8mtR0QLVssJwGDhkE0ZnfrzZd39/Qk+Hj 9HoL1+0ysSXV5LvoE7QmvWPxFJKm7rB6oA18huGsZOUpG9/eKj5GfeiWfhxEWCOJ6PQi lfow== X-Gm-Message-State: ALoCoQk40CVm+QG+f18Z9/aGkZo6Loh5AjKRxSF9xGyYxFWISN4IehfOxwkY3uStyhgElHCDaSZi X-Received: by 10.152.36.169 with SMTP id r9mr5671613laj.14.1405692380676; Fri, 18 Jul 2014 07:06:20 -0700 (PDT) Received: from [2.65.183.91] (2.65.183.91.mobile.tre.se. [2.65.183.91]) by mx.google.com with ESMTPSA id ok1sm9510688lbc.18.2014.07.18.07.06.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jul 2014 07:06:20 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-C34790D2-3AE3-4CC4-B1BE-ABB208B0387A Mime-Version: 1.0 (1.0) From: Leif Johansson X-Mailer: iPhone Mail (11D257) In-Reply-To: <57BAE65C-6176-4E31-AFAB-CF6DFE9DDEE4@oracle.com> Date: Fri, 18 Jul 2014 16:06:18 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <57BAE65C-6176-4E31-AFAB-CF6DFE9DDEE4@oracle.com> To: Phil Hunt Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Aylb1m-GcmevrY3mD1QjyLk0MfQ Cc: SCIM WG Subject: Re: [scim] Security considerations: sensitive data X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 14:06:29 -0000 --Apple-Mail-C34790D2-3AE3-4CC4-B1BE-ABB208B0387A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think we should say that scim is not an authentication protocol and any re= semblance to one is accidental and that using scim for provisioning credenti= als should be avoided.=20 Thats the way to avoid lots of ratholes! > 17 jul 2014 kl. 20:52 skrev Phil Hunt : >=20 > At present we do not have any security considerations for sensitive data (= e.g. passwords). =20 >=20 > Am thinking we should have some general verbiage around the issues/best pr= actice around things like passwords that need to be salted/hashed appropriat= ely. To some implementers as a pure provisioning protocol there may be no i= mpact. But for those building SCIM on top of a persistence system (e.g. data= base), the considerations become important. There=E2=80=99s lots of stuff to= reference here, especially from the OAuth Threat Model document as well as L= DAP. >=20 > The other issue is whether this goes in the API or the core-schema draft (= or both). >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-C34790D2-3AE3-4CC4-B1BE-ABB208B0387A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I think we should say that scim is not= an authentication protocol and any resemblance to one is accidental and tha= t using scim for provisioning credentials should be avoided. 

Thats the way to avoid lots of ratholes!

17 ju= l 2014 kl. 20:52 skrev Phil Hunt <phil.hunt@oracle.com>:

<= meta http-equiv=3D"Content-Type" content=3D"text/html charset=3Dwindows-1252= ">At present we do not have any security considerations for sensitive data (= e.g. passwords).  

Am thinking we should have some g= eneral verbiage around the issues/best practice around things like passwords= that need to be salted/hashed appropriately.  To some implementers as a= pure provisioning protocol there may be no impact. But for those building S= CIM on top of a persistence system (e.g. database), the considerations becom= e important. There=E2=80=99s lots of stuff to reference here, especially fro= m the OAuth Threat Model document as well as LDAP.

= The other issue is whether this goes in the API or the core-schema draft (or= both).

= --Apple-Mail-C34790D2-3AE3-4CC4-B1BE-ABB208B0387A-- From nobody Fri Jul 18 10:18:26 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516841B27F0 for ; Fri, 18 Jul 2014 10:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrCDilQWehbq for ; Fri, 18 Jul 2014 10:18:18 -0700 (PDT) Received: from nm39-vm8.bullet.mail.bf1.yahoo.com (nm39-vm8.bullet.mail.bf1.yahoo.com [72.30.239.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B19F1B27CC for ; Fri, 18 Jul 2014 10:18:18 -0700 (PDT) Received: from [66.196.81.173] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 18 Jul 2014 17:18:17 -0000 Received: from [98.139.212.236] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 18 Jul 2014 17:18:17 -0000 Received: from [127.0.0.1] by omp1045.mail.bf1.yahoo.com with NNFMP; 18 Jul 2014 17:18:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 477993.16947.bm@omp1045.mail.bf1.yahoo.com Received: (qmail 25285 invoked by uid 60001); 18 Jul 2014 17:18:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1405703897; bh=gPLnpzclbjqLAJDg2oNtCcZBtyXVOyPxDsdgO2CUYWA=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=HotiD90vu46HuGklOvjn5L74Q8Y2Wp+nVNB6DGA2gHvSxQHSY5MSsPtLjDPhsrCiGKXLZ2muDaQP69PJXXRW2qfRAEisCVSIMH9fs79VtfNs2BPcEskp4JLoVQ6VPQtJh6hyYdfECQK8QP0YMMp7zz4OzNSFBRbfJQtJHVukDqg= X-YMail-OSG: hJVeyqgVM1l9SP1_WnVChh7NmWo7GmCNtxJ9E8.Qoe0p3gp Hhv3uoo72ZFB1FehvylIw8ardnFpMqEsZE9fCmGsRmHsGjRKkFCfqmTGSuhp w5x8y6fJL0ndIrSxm0EY9zvkbdWaB1flvhcJxMjVN6NIWaAP5F90K7qJEMXy t7wEhj5rrVKmIYXJNV2u2oT1TR_bGG4rh3nPbl1urC0Y_YcfH2rx5_U0Ukss 0Q_gLrsyil.zZQ3FHdvKlVvoaeACSJSTRpj4JHfDXVwivvjAii7c41Icrc7t wdKGf.Fiu9YOQ8pTUdOvd9pxHcajF1LFh1NgE9aNtMTCMc_quF0XiDQC_ihM RgB5ciwdDn2BVhxxurayZtjRnp11.JaRNrt.lGIjywJcpgMCd_ARgz5S1grF q7wq7z_ty2F76daWgJH2gaO7V3p9p.t7.E0eWLwXbcQs7hwvkd_ekgkILgTV KxI4e6HdaZgyMfndJjy.xqZG4uM3XNWtX80TOFPZ0V1X8eC7M3iGAaWlJRjO hjHaVS5Bu59fKK5ttTQshYkB70ZsEEd_QfoVnjnl9TT9lyrrWwMviEN0l9jj dD11HCcJJqKcO3gbEK59vhCwwFNzSDPjXP6azKrCFhWD0tp8nwWPaArRAoC0 qsK4_TGNdQM6IrbS1r3FXUiWRBddUkMiLKsbW5Dek_.cYDdoxq2WE Received: from [167.220.24.190] by web142806.mail.bf1.yahoo.com via HTTP; Fri, 18 Jul 2014 10:18:17 PDT X-Rocket-MIMEInfo: 002.001, SW4gZmFjdCBTQ0lNIGlzIHZlcnkgd2Vhay9zaWxlbnQgb24gdGhlIHdob2xlIGF1dGhuL2F1dGh6IHN1YmplY3QuCgoKT24gRnJpZGF5LCBKdWx5IDE4LCAyMDE0IDc6MDYgQU0sIExlaWYgSm9oYW5zc29uIDxsZWlmakBtbnQuc2U.IHdyb3RlOgogCgoKSSB0aGluayB3ZSBzaG91bGQgc2F5IHRoYXQgc2NpbSBpcyBub3QgYW4gYXV0aGVudGljYXRpb24gcHJvdG9jb2wgYW5kIGFueSByZXNlbWJsYW5jZSB0byBvbmUgaXMgYWNjaWRlbnRhbCBhbmQgdGhhdCB1c2luZyBzY2ltIGZvciBwcm92aXNpb25pbmcgY3IBMAEBAQE- X-Mailer: YahooMailWebService/0.8.195.680 References: <57BAE65C-6176-4E31-AFAB-CF6DFE9DDEE4@oracle.com> Message-ID: <1405703897.41499.YahooMailNeo@web142806.mail.bf1.yahoo.com> Date: Fri, 18 Jul 2014 10:18:17 -0700 From: Bill Mills To: Leif Johansson , Phil Hunt In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="515012262-230769683-1405703897=:41499" Archived-At: http://mailarchive.ietf.org/arch/msg/scim/dYje0eraU6lT7PYScoR3Dc2Vphg Cc: SCIM WG Subject: Re: [scim] Security considerations: sensitive data X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 17:18:22 -0000 --515012262-230769683-1405703897=:41499 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In fact SCIM is very weak/silent on the whole authn/authz subject.=0A=0A=0A= On Friday, July 18, 2014 7:06 AM, Leif Johansson wrote:=0A = =0A=0A=0AI think we should say that scim is not an authentication protocol = and any resemblance to one is accidental and that using scim for provisioni= ng credentials should be avoided.=C2=A0=0A=0AThats the way to avoid lots of= ratholes!=0A=0A17 jul 2014 kl. 20:52 skrev Phil Hunt :=0A=0A=0AAt present we do not have any security considerations for sensit= ive data (e.g. passwords). =C2=A0=0A=0AAm thinking we should have some gene= ral verbiage around the issues/best practice around things like passwords t= hat need to be salted/hashed appropriately. =C2=A0To some implementers as a= pure provisioning protocol there may be no impact. But for those building = SCIM on top of a persistence system (e.g. database), the considerations bec= ome important. There=E2=80=99s lots of stuff to reference here, especially = from the OAuth Threat Model document as well as LDAP.=0A=0AThe other issue = is whether this goes in the API or the core-schema draft (or both).=0A=0APh= il=0A=0A@independentid=0Awww.independentid.comphil.hunt@oracle.com=0A=0A=0A= =0A_______________________________________________=0A>scim mailing list=0A>= scim@ietf.org=0A>https://www.ietf.org/mailman/listinfo/scim=0A>=0A=0A______= _________________________________________=0Ascim mailing list=0Ascim@ietf.o= rg=0Ahttps://www.ietf.org/mailman/listinfo/scim --515012262-230769683-1405703897=:41499 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
In fact SCIM is very weak/silent on the whole auth= n/authz subject.


On Friday, July 18,= 2014 7:06 AM, Leif Johansson <leifj@mnt.se> wrote:

<= div>I think we should say that scim is not an authentication protocol and a= ny resemblance to one is accidental and that using scim for provisioning cr= edentials should be avoided. 

Thats the= way to avoid lots of ratholes!

17 jul 2014 kl. = 20:52 skrev Phil Hunt <phil.hunt@oracle.com>:

At= present we do not have any security considerations for sensitive data (e.g= . passwords).  

Am thinking we shoul= d have some general verbiage around the issues/best practice around things = like passwords that need to be salted/hashed appropriately.  To some i= mplementers as a pure provisioning protocol there may be no impact. But for those building SCIM = on top of a persistence system (e.g. database), the considerations become i= mportant. There=E2=80=99s lots of stuff to reference here, especially from = the OAuth Threat Model document as well as LDAP.

The other issue is whether this goes in the API or the core-s= chema draft (or both).

<= br clear=3D"none" class=3D"yiv6755170945Apple-interchange-newline">=0A=0A
_________= ______________________________________
scim = mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

_______________________________________________
scim mailing list
scim@ietf.org<= br clear=3D"none">https://www.ietf.org/mailman/listinfo/scim


--515012262-230769683-1405703897=:41499-- From nobody Fri Jul 18 10:41:55 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FB51A0AAB for ; Fri, 18 Jul 2014 10:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbNAA2H2MOzd for ; Fri, 18 Jul 2014 10:41:49 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7E281A000B for ; Fri, 18 Jul 2014 10:41:49 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6IHfm3B028532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Jul 2014 17:41:48 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6IHflYG003682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jul 2014 17:41:47 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6IHflsK003669; Fri, 18 Jul 2014 17:41:47 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 18 Jul 2014 10:41:46 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_44FE6ACD-2CB6-4761-9CB9-E3266F402C72" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <1405703897.41499.YahooMailNeo@web142806.mail.bf1.yahoo.com> Date: Fri, 18 Jul 2014 10:41:45 -0700 Message-Id: References: <57BAE65C-6176-4E31-AFAB-CF6DFE9DDEE4@oracle.com> <1405703897.41499.YahooMailNeo@web142806.mail.bf1.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/6yYdTAXKsD2MdfgBwvViC_x8X_I Cc: Leif Johansson , SCIM WG Subject: Re: [scim] Security considerations: sensitive data X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 17:41:51 -0000 --Apple-Mail=_44FE6ACD-2CB6-4761-9CB9-E3266F402C72 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I posted some improved authen text in another thread. I believe strongly we are going to have to address credential management = one way or another in a future charter. The real issue is because people are building web UI servers and HTML5 = code that contact SCIM endpoints to provide user self-service features. = =46rom a protocol perspective, its hard to differentiate from a client = doing the bad thing of sync=92ing passwords, to a UI component simply = setting the password via a cloud SCIM endpoint. For example, a set-top = box might make a SCIM call to update a password as it presents its own = UI to the end-user. The set top box may use an OAuth token that enables = the SCIM endpoint to trust the box to make such a change. I am ok with saying SCIM does not do authentication. But to say that = passwords cannot be validated(matched) would be wrong. At best it can be = simply a single factor confirmation. An authentication system SHOULD be = much more than this (e.g. establishing a session, validating multiple = factors). All of which fall out of scope of SCIM. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 18, 2014, at 10:18 AM, Bill Mills wrote: > In fact SCIM is very weak/silent on the whole authn/authz subject. >=20 >=20 > On Friday, July 18, 2014 7:06 AM, Leif Johansson wrote: >=20 >=20 > I think we should say that scim is not an authentication protocol and = any resemblance to one is accidental and that using scim for = provisioning credentials should be avoided.=20 >=20 > Thats the way to avoid lots of ratholes! >=20 > 17 jul 2014 kl. 20:52 skrev Phil Hunt : >=20 >=20 > At present we do not have any security considerations for sensitive = data (e.g. passwords). =20 >=20 > Am thinking we should have some general verbiage around the = issues/best practice around things like passwords that need to be = salted/hashed appropriately. To some implementers as a pure = provisioning protocol there may be no impact. But for those building = SCIM on top of a persistence system (e.g. database), the considerations = become important. There=92s lots of stuff to reference here, especially = from the OAuth Threat Model document as well as LDAP. >=20 > The other issue is whether this goes in the API or the core-schema = draft (or both). >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=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 --Apple-Mail=_44FE6ACD-2CB6-4761-9CB9-E3266F402C72 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = posted some improved authen text in another thread.

I = believe strongly we are going to have to address credential management = one way or another in a future charter.

The = real issue is because people are building web UI servers and HTML5 code = that contact SCIM endpoints to provide user self-service features. =  =46rom a protocol perspective, its hard to differentiate from a = client doing the bad thing of sync=92ing passwords, to a UI component = simply setting the password via a cloud SCIM endpoint.  For = example, a set-top box might make a SCIM call to update a password as it = presents its own UI to the end-user.  The set top box may use an = OAuth token that enables the SCIM endpoint to trust the box to make such = a change.

I am ok with saying SCIM does not do = authentication. But to say that passwords cannot be validated(matched) = would be wrong. At best it can be simply a single factor confirmation. = An authentication system SHOULD be much more than this (e.g. = establishing a session, validating multiple factors).  All of which = fall out of scope of SCIM.

Phil

On Jul 18, 2014, at 10:18 AM, Bill Mills <wmills_92105@yahoo.com> = wrote:

In fact SCIM is very = weak/silent on the whole authn/authz subject.


=
On Friday, July 18, = 2014 7:06 AM, Leif Johansson <leifj@mnt.se> wrote:
 =


I think we should say that scim is not an = authentication protocol and any resemblance to one is accidental and = that using scim for provisioning credentials should be avoided. 

Thats = the way to avoid lots of ratholes!

17 jul 2014 kl. 20:52 skrev Phil Hunt <phil.hunt@oracle.com>:

At = present we do not have any security considerations for sensitive data = (e.g. passwords).  

Am thinking = we should have some general verbiage around the issues/best practice = around things like passwords that need to be salted/hashed = appropriately.  To some implementers as a pure provisioning protocol there may be no impact. But for those building = SCIM on top of a persistence system (e.g. database), the considerations = become important. There=92s lots of stuff to reference here, especially = from the OAuth Threat Model document as well as LDAP.

The other issue is whether this goes in the = API or the core-schema draft (or both).

_______________________________________________=
scim mailing list
scim@ietf.org
https://www.ietf.org/m= ailman/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/ma= ilman/listinfo/scim

= --Apple-Mail=_44FE6ACD-2CB6-4761-9CB9-E3266F402C72-- From nobody Fri Jul 18 10:42:26 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12AA51A000B for ; Fri, 18 Jul 2014 10:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7kY9RY0v3OQ for ; Fri, 18 Jul 2014 10:42:22 -0700 (PDT) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FD6C1A001B for ; Fri, 18 Jul 2014 10:42:21 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id v6so3053859lbi.24 for ; Fri, 18 Jul 2014 10:42:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=UMeM7XcGt8yHufJQ4lRnwH4wVWyI7vQC1y9pkh41XQM=; b=YspTZozMRBTi78Oevy2yq9ln8jVaFhN6mLU+K4yin/lpgHpoA2OvG5XLg5F90HdDjY oYrLrnf2Rn7o/C6FiNpnEEcNdJ76PQSFN8HR50PycugVp2MqLEQ0yhFQocNy9UN0Y4yh uUMDcVRB8yfEiFncTXVVP0eIRvfnnY8Iw6LmmbDgY8aou7raZyCYLWrNb+ckunGILHg1 a84YNHifMlSt4ZxOI2jvG1UaRviWrxyExHGZ4L8IJDoRNhKdB3O8Ogu46Ns6ng9phPFV s1LsoqCtulmoqx/zEiY8Uf4EWe2sSrdp9DzFBh6zgDPe3QHjfe0M1Du7YXDLNTeejtJj DtzA== X-Gm-Message-State: ALoCoQmOgTIipwDepA4ogrOb5jSltD3EpP6K6H9d91p5PylXrH2qxQCW18TyorovbCIBqKA4ClyE X-Received: by 10.152.9.136 with SMTP id z8mr5703940laa.98.1405705339735; Fri, 18 Jul 2014 10:42:19 -0700 (PDT) Received: from [2.65.183.91] (2.65.183.91.mobile.tre.se. [2.65.183.91]) by mx.google.com with ESMTPSA id db4sm4018991lad.21.2014.07.18.10.42.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jul 2014 10:42:19 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-9742B218-71D0-4396-BC69-438860A9FA95 Mime-Version: 1.0 (1.0) From: Leif Johansson X-Mailer: iPhone Mail (11D257) In-Reply-To: <1405703897.41499.YahooMailNeo@web142806.mail.bf1.yahoo.com> Date: Fri, 18 Jul 2014 19:42:19 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <57BAE65C-6176-4E31-AFAB-CF6DFE9DDEE4@oracle.com> <1405703897.41499.YahooMailNeo@web142806.mail.bf1.yahoo.com> To: Bill Mills Archived-At: http://mailarchive.ietf.org/arch/msg/scim/b3Z46ziYcSjpbTNg6B_CzfLQIhk Cc: SCIM WG , Phil Hunt Subject: Re: [scim] Security considerations: sensitive data X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 17:42:24 -0000 --Apple-Mail-9742B218-71D0-4396-BC69-438860A9FA95 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > 18 jul 2014 kl. 19:18 skrev Bill Mills : >=20 > In fact SCIM is very weak/silent on the whole authn/authz subject. Right - I suggest that adding more words may get us in trouble. There are a= bucnh of credential mgmt protocols around and trying to make scim behave li= ke one is just going to garner attention from everybody who has a favorite a= uthentication protocol. Best say 'don't do it' and leave it for extensions.= >=20 >=20 > On Friday, July 18, 2014 7:06 AM, Leif Johansson wrote: >=20 >=20 > I think we should say that scim is not an authentication protocol and any r= esemblance to one is accidental and that using scim for provisioning credent= ials should be avoided.=20 >=20 > Thats the way to avoid lots of ratholes! >=20 >> 17 jul 2014 kl. 20:52 skrev Phil Hunt : >>=20 >=20 >=20 > At present we do not have any security considerations for sensitive data (= e.g. passwords). =20 >=20 > Am thinking we should have some general verbiage around the issues/best pr= actice around things like passwords that need to be salted/hashed appropriat= ely. To some implementers as a pure provisioning protocol there may be no i= mpact. But for those building SCIM on top of a persistence system (e.g. data= base), the considerations become important. There=E2=80=99s lots of stuff to= reference here, especially from the OAuth Threat Model document as well as L= DAP. >=20 > The other issue is whether this goes in the API or the core-schema draft (= or both). >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 --Apple-Mail-9742B218-71D0-4396-BC69-438860A9FA95 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


18 jul 2014 kl. 19:= 18 skrev Bill Mills <wmills_921= 05@yahoo.com>:

= In fact SCIM is very weak/silent on the whole authn/authz subject.

Right  - I suggest that= adding more words may get us in trouble. There are a bucnh of credential mg= mt protocols around and trying to make scim behave like one is just going to= garner attention from everybody who has a favorite authentication protocol.=  Best say 'don't do it' and leave it for extensions.



On Friday, July 18, 2014 7:06 A= M, Leif Johansson <leifj@mnt.se> w= rote:


I think we should say that scim is not an authenti= cation protocol and any resemblance to one is accidental and that using scim= for provisioning credentials should be avoided. 

Thats the w= ay to avoid lots of ratholes!

17 jul 2014 kl. 20:5= 2 skrev Phil Hunt <= phil.hunt@oracle.com>:

=
At present w= e do not have any security considerations for sensitive data (e.g. passwords= ).  

Am thinking we should have some g= eneral verbiage around the issues/best practice around things like passwords= that need to be salted/hashed appropriately.  To some implementers as a= pure provisioning protocol there may be no impact. But for those building SCIM o= n top of a persistence system (e.g. database), the considerations become imp= ortant. There=E2=80=99s lots of stuff to reference here, especially from the= OAuth Threat Model document as well as LDAP.

<= /div>
The other issue is whether this goes in the API or the core-schema= draft (or both).



______________= _________________________________
scim mailin= g 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-9742B218-71D0-4396-BC69-438860A9FA95-- From nobody Fri Jul 18 10:44:37 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D951A001B for ; Fri, 18 Jul 2014 10:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_I_NcqK2395 for ; Fri, 18 Jul 2014 10:44:28 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6397C1A000B for ; Fri, 18 Jul 2014 10:44:27 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id z11so3108934lbi.17 for ; Fri, 18 Jul 2014 10:44:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=dKoT+n03QJY3jJ5IjhqrlO+926eLhvYN6MsJ8qNaB/c=; b=HMqoRJh6zOX+SJ3Da06IgR6VW/1CISDiGnzmcrreIGIJ0z6QYZMuijErq8nR1Mjqi+ GBYoWDXgFNx6AxP5vyagkSe6FcoSjqNGgI2xbQ/Logj+xx15iEiSRL95CIQrwYiBZxQk bvpCvn/mbNby9FHrGize/O9bDNXK2mAn6wMFaCIqWV1NDoQk2g9rgflXf8q0MNAQA8rl PESfxAUjPeWTEy7ID8xo6zjFhX80mUskEwL0DwRgXMwnsdoWkFYIWruR2hbnImykwe8C 4AJ34R0S+7aDFtrhdp5izblCcuJuk3qKPEyzCCIErUt2KnYzdbHx14kCBl/Falg1Ue3s oLZA== X-Gm-Message-State: ALoCoQkalsd9j+LE+eV849J2Rq4PMBYOUw+vm45IybfL55lo9V/ToONqZUex/uRloAR74xljUOhD X-Received: by 10.152.203.233 with SMTP id kt9mr7036048lac.84.1405705465655; Fri, 18 Jul 2014 10:44:25 -0700 (PDT) Received: from [2.65.183.91] (2.65.183.91.mobile.tre.se. [2.65.183.91]) by mx.google.com with ESMTPSA id xt2sm5001438lac.11.2014.07.18.10.44.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jul 2014 10:44:25 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-D52CF2E0-7F9E-452A-BDA7-8FBFA159EF3E Mime-Version: 1.0 (1.0) From: Leif Johansson X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Fri, 18 Jul 2014 19:44:25 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <57BAE65C-6176-4E31-AFAB-CF6DFE9DDEE4@oracle.com> <1405703897.41499.YahooMailNeo@web142806.mail.bf1.yahoo.com> To: Phil Hunt Archived-At: http://mailarchive.ietf.org/arch/msg/scim/eE06eQ3iNPQyLMSdKF9Iw4MyjMk Cc: SCIM WG , William Mills Subject: Re: [scim] Security considerations: sensitive data X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 17:44:34 -0000 --Apple-Mail-D52CF2E0-7F9E-452A-BDA7-8FBFA159EF3E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > 18 jul 2014 kl. 19:41 skrev Phil Hunt : >=20 > I posted some improved authen text in another thread. >=20 > I believe strongly we are going to have to address credential management o= ne way or another in a future charter. >=20 Lets deal w this when somebody defines an extension for it! > The real issue is because people are building web UI servers and HTML5 cod= e that contact SCIM endpoints to provide user self-service features. =46rom= a protocol perspective, its hard to differentiate from a client doing the b= ad thing of sync=E2=80=99ing passwords, to a UI component simply setting the= password via a cloud SCIM endpoint. For example, a set-top box might make a= SCIM call to update a password as it presents its own UI to the end-user. T= he set top box may use an OAuth token that enables the SCIM endpoint to trus= t the box to make such a change. >=20 > I am ok with saying SCIM does not do authentication. But to say that passw= ords cannot be validated(matched) would be wrong.=20 There are many a rat buried there. > At best it can be simply a single factor confirmation. An authentication s= ystem SHOULD be much more than this (e.g. establishing a session, validating= multiple factors). All of which fall out of scope of SCIM. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >> On Jul 18, 2014, at 10:18 AM, Bill Mills wrote: >>=20 >> In fact SCIM is very weak/silent on the whole authn/authz subject. >>=20 >>=20 >> On Friday, July 18, 2014 7:06 AM, Leif Johansson wrote: >>=20 >>=20 >> I think we should say that scim is not an authentication protocol and any= resemblance to one is accidental and that using scim for provisioning crede= ntials should be avoided.=20 >>=20 >> Thats the way to avoid lots of ratholes! >>=20 >>> 17 jul 2014 kl. 20:52 skrev Phil Hunt : >>>=20 >>=20 >>=20 >> At present we do not have any security considerations for sensitive data (= e.g. passwords). =20 >>=20 >> Am thinking we should have some general verbiage around the issues/best p= ractice around things like passwords that need to be salted/hashed appropria= tely. To some implementers as a pure provisioning protocol there may be no i= mpact. But for those building SCIM on top of a persistence system (e.g. data= base), the considerations become important. There=E2=80=99s lots of stuff to= reference here, especially from the OAuth Threat Model document as well as L= DAP. >>=20 >> The other issue is whether this goes in the API or the core-schema draft (= or both). >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>=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 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-D52CF2E0-7F9E-452A-BDA7-8FBFA159EF3E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


18 jul 2014 kl. 19:= 41 skrev Phil Hunt <phil.hunt@ora= cle.com>:

I posted som= e improved authen text in another thread.

I believe stron= gly we are going to have to address credential management one way or another= in a future charter.


=
Lets deal w this when somebody defines an extension for it!

The real issue is because people are build= ing web UI servers and HTML5 code that contact SCIM endpoints to provide use= r self-service features.  =46rom a protocol perspective, its hard to di= fferentiate from a client doing the bad thing of sync=E2=80=99ing passwords,= to a UI component simply setting the password via a cloud SCIM endpoint. &n= bsp;For example, a set-top box might make a SCIM call to update a password a= s it presents its own UI to the end-user.  The set top box may use an O= Auth token that enables the SCIM endpoint to trust the box to make such a ch= ange.

I am ok with saying SCIM does not do authenti= cation. But to say that passwords cannot be validated(matched) would be wron= g.

There are many a rat buried t= here.

At best it can be simply a= single factor confirmation. An authentication system SHOULD be much more th= an this (e.g. establishing a session, validating multiple factors).  Al= l of which fall out of scope of SCIM.

Phil


On Jul 18, 2014, at 10:18 AM, Bill Mills <wmills_92105@yahoo.com> wrote:

In fact SCIM is very weak/silent on the whole authn/authz subject.<= /span>


= On Friday, July 18, 2014 7:06 AM, Leif Joh= ansson <leifj@mnt.se> wrote:
<= /font>


I think we should say that scim is not an authentication prot= ocol and any resemblance to one is accidental and that using scim for provis= ioning credentials should be avoided. 

Thats the w= ay to avoid lots of ratholes!

17 jul 2014 kl. 20:5= 2 skrev Phil Hunt <= phil.hunt@oracle.com>:

=
At present we do n= ot have any security considerations for sensitive data (e.g. passwords). &nb= sp;

Am thinking we should have some genera= l verbiage around the issues/best practice around things like passwords that= need to be salted/hashed appropriately.  To some implementers as a pur= e provisioning protocol there may be no impact. But for those building SCIM o= n top of a persistence system (e.g. database), the considerations become imp= ortant. There=E2=80=99s lots of stuff to reference here, especially from the= OAuth Threat Model document as well as LDAP.

<= /div>
The other issue is whether this goes in the API or the core-schema= draft (or both).

=
Phil

@independentid
<= a rel=3D"nofollow" shape=3D"rect" target=3D"_blank" href=3D"http://www.indep= endentid.com/">www.independentid.com
phil.hunt@oracle.com

=


___________________= ____________________________
scim mailing lis= t
scim@= ietf.org
htt= ps://www.ietf.org/mailman/listinfo/scim

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


_______________________________________________<= br>scim mailing list
scim@ietf.orghttps://www.ietf.or= g/mailman/listinfo/scim

____________________________________= ___________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
= --Apple-Mail-D52CF2E0-7F9E-452A-BDA7-8FBFA159EF3E-- From nobody Fri Jul 18 10:51:28 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB84E1B29C7 for ; Fri, 18 Jul 2014 10:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oosx-heUDrof for ; Fri, 18 Jul 2014 10:51:24 -0700 (PDT) Received: from nm22-vm1.bullet.mail.bf1.yahoo.com (nm22-vm1.bullet.mail.bf1.yahoo.com [98.139.212.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B97701B29C8 for ; Fri, 18 Jul 2014 10:51:23 -0700 (PDT) Received: from [98.139.215.142] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 18 Jul 2014 17:51:22 -0000 Received: from [98.139.212.217] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 18 Jul 2014 17:51:22 -0000 Received: from [127.0.0.1] by omp1026.mail.bf1.yahoo.com with NNFMP; 18 Jul 2014 17:51:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 791747.63692.bm@omp1026.mail.bf1.yahoo.com Received: (qmail 47414 invoked by uid 60001); 18 Jul 2014 17:51:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1405705882; bh=lWYC9SKflFO6jBQeTSjHfBOpJXdImPWPiEB6ztWxfpU=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ouPU4Z6wH/YMDeeCnh7hyjeRJDfG4Q/V8jIvH7tZ2Hs11+KS0eA0cKF2LN7MIzRKnsyfne4BjaU0rD9ru3bRsWHUz2npc8LhPQwAtPqcmWROh1oMhI0zQ1MLfW045z9/BwbJxtoFu/YqGiWqLUOCSwn79w/ff3LStnTO04iWXAI= X-YMail-OSG: KOs7_gcVM1mnBJbjflwxk0X0j8Bd0vkCL6bGhG6PFRV5mos fvEKXHeMY8QY311yGNWR6zJp6KHzzKz4o5cqdWX4HdQuW8jgrA2j5ftTq8AA 9SWozHo5P2d667qflE8s2uL34oDyc6q_zzwJx8bSO1y03grhm37nKQSB7VpR nt4FEipJAnH02Z6bpv9GGqa3Uwr_XL2A_JtMjsmkEk.WmnXA0xg3xJ137jnN tidZURtRLPwviDc6SxHCEk5wGHrGStggPL9hRF_Q005MLAGhJ2vbbeJxde9D kdewy589NAOwQHVygsf.gCr4oWuevINk3fw4XGdQtqEa0dRftrBx.EpD12aT 2yDv_6pqtiVaW22HRYzsFaotSse7M6hHxNVGdVCZwMPUCUrHzsTilMisOI3i uv.4.54wt2lKX6dt2j3Vtoxs_uxkal1D9KIiQmcJOpxpwpyHRrfIwRqNmxe7 p0TdAqmJQmbbrKjP90i4O9rJWJmvJuRurmq4OYiwdjRJIN8xpUSxpcqd0dnT pYVao6WscWqLqrG7macmRBGn02iHZYHoNS1ShNosjTEU8xqgF24uO6sKvpHs vca0Vh29LzoFO.lfDIEQRjII9TvWM0at9TEpdLUezcjCd2stf1Rlyf3Y2XN0 THGQ5aByrbbX.k4t1aX9VDubErKtZImHh6RVJj0tZOje6HQW7wPKD Received: from [167.220.24.190] by web142806.mail.bf1.yahoo.com via HTTP; Fri, 18 Jul 2014 10:51:22 PDT X-Rocket-MIMEInfo: 002.001, IlNDSU0gaXMgYSBkYXRhIHN5bmRpY2F0aW9uL3B1YmxpY2F0aW9uL3F1ZXJ5IHRvb2wsIGFzIHN1Y2ggaXQgbWF5IGJlIHVzZWQgYXMgdGhlIGRhdGEgc291cmNlL3NpbmsgZm9yIGFuIGF1dGhlbnRpY2F0aW9uIHN5c3RlbSBhY3RpbmcgYXMgYSBjbGllbnQgb3IgcGVlci4iCgoKT24gRnJpZGF5LCBKdWx5IDE4LCAyMDE0IDEwOjQ1IEFNLCBMZWlmIEpvaGFuc3NvbiA8bGVpZmpAbW50LnNlPiB3cm90ZToKIAoKCgoKCjE4IGp1bCAyMDE0IGtsLiAxOTo0MSBza3JldiBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.195.680 References: <57BAE65C-6176-4E31-AFAB-CF6DFE9DDEE4@oracle.com> <1405703897.41499.YahooMailNeo@web142806.mail.bf1.yahoo.com> Message-ID: <1405705882.99642.YahooMailNeo@web142806.mail.bf1.yahoo.com> Date: Fri, 18 Jul 2014 10:51:22 -0700 From: Bill Mills To: Leif Johansson , Phil Hunt In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="515012262-235877667-1405705882=:99642" Archived-At: http://mailarchive.ietf.org/arch/msg/scim/RnnBdGLvLkWfC_-_qveAjXn5pto Cc: SCIM WG Subject: Re: [scim] Security considerations: sensitive data X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 17:51:26 -0000 --515012262-235877667-1405705882=:99642 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable "SCIM is a data syndication/publication/query tool, as such it may be used = as the data source/sink for an authentication system acting as a client or = peer."=0A=0A=0AOn Friday, July 18, 2014 10:45 AM, Leif Johansson wrote:=0A =0A=0A=0A=0A=0A=0A18 jul 2014 kl. 19:41 skrev Phil Hunt :=0A=0A=0AI posted some improved authen text in another t= hread.=0A=0AI believe strongly we are going to have to address credential m= anagement one way or another in a future charter.=0A=0A=0ALets deal w this = when somebody defines an extension for it!=0A=0AThe real issue is because p= eople are building web UI servers and HTML5 code that contact SCIM endpoint= s to provide user self-service features. =C2=A0From a protocol perspective,= its hard to differentiate from a client doing the bad thing of sync=E2=80= =99ing passwords, to a UI component simply setting the password via a cloud= SCIM endpoint. =C2=A0For example, a set-top box might make a SCIM call to = update a password as it presents its own UI to the end-user. =C2=A0The set = top box may use an OAuth token that enables the SCIM endpoint to trust the = box to make such a change.=0A>=0A>=0A>I am ok with saying SCIM does not do = authentication. But to say that passwords cannot be validated(matched) woul= d be wrong. =0A=0AThere are many a rat buried there.=0A=0A=0AAt best it can= be simply a single factor confirmation. An authentication system SHOULD be= much more than this (e.g. establishing a session, validating multiple fact= ors). =C2=A0All of which fall out of scope of SCIM.=0A>=0A>=0A>Phil=0A>=0A>= =0A>@independentid=0A>www.independentid.comphil.hunt@oracle.com=0A>=0A>=0A>= =0A>=0A>On Jul 18, 2014, at 10:18 AM, Bill Mills w= rote:=0A>=0A>In fact SCIM is very weak/silent on the whole authn/authz subj= ect.=0A>>=0A>>=0A>>=0A>>On Friday, July 18, 2014 7:06 AM, Leif Johansson wrote:=0A>> =0A>>=0A>>=0A>>I think we should say that scim is = not an authentication protocol and any resemblance to one is accidental and= that using scim for provisioning credentials should be avoided.=C2=A0=0A>>= =0A>>=0A>>Thats the way to avoid lots of ratholes!=0A>>=0A>>17 jul 2014 kl.= 20:52 skrev Phil Hunt :=0A>>=0A>>=0A>>At present we = do not have any security considerations for sensitive data (e.g. passwords)= . =C2=A0=0A>>=0A>>=0A>>Am thinking we should have some general verbiage aro= und the issues/best practice around things like passwords that need to be s= alted/hashed appropriately. =C2=A0To some implementers as a pure provisioni= ng protocol there may be no impact. But for those building SCIM on top of a= persistence system (e.g. database), the considerations become important. T= here=E2=80=99s lots of stuff to reference here, especially from the OAuth T= hreat Model document as well as LDAP.=0A>>=0A>>=0A>>The other issue is whet= her this goes in the API or the core-schema draft (or both).=0A>>=0A>>=0A>>= Phil=0A>>=0A>>=0A>>@independentid=0A>>www.independentid.comphil.hunt@oracle= .com=0A>>=0A>>=0A>>=0A>>=0A>>______________________________________________= _=0A>>>scim mailing list=0A>>>scim@ietf.org=0A>>>https://www.ietf.org/mailm= an/listinfo/scim=0A>>>=0A>>=0A>>___________________________________________= ____=0A>>scim mailing list=0A>>scim@ietf.org=0A>>https://www.ietf.org/mailm= an/listinfo/scim=0A>>=0A>>=0A>>____________________________________________= ___=0A>>scim mailing list=0A>>scim@ietf.org=0A>>https://www.ietf.org/mailma= n/listinfo/scim=0A>>=0A>=0A_______________________________________________= =0A>scim mailing list=0A>scim@ietf.org=0A>https://www.ietf.org/mailman/list= info/scim=0A>=0A=0A_______________________________________________=0Ascim m= ailing list=0Ascim@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/scim --515012262-235877667-1405705882=:99642 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
"SCIM is a data syndication/publication/query tool= , as such it may be used as the data source/sink for an authentication syst= em acting as a client or peer."
<= br>
On F= riday, July 18, 2014 10:45 AM, Leif Johansson <leifj@mnt.se> wrote:




At best it can be simply = a single factor confirmation. An authentication system SHOULD be much more = than this (e.g. establishing a session, validating multiple factors).  = ;All of which fall out of scope of SCIM.

Phil

=0A=0A
On Jul 18, 2014, at 10:18 AM, Bill Mills= <wmills_9210= 5@yahoo.com> wrote:

<= span>In fact SCIM is very weak/silent on the whole authn/authz subject.


On Friday, July= 18, 2014 7:06 AM, Leif Johansson <leifj@mnt.se> wrote:


<= div id=3D"yiv6718046711">
I think we should say that scim is not a= n authentication protocol and any resemblance to one is accidental and that= using scim for provisioning credentials=0A should be avoided. 
<= div>
Thats the way to avoid lots of ratholes!<= /div>

17 jul 2014 kl. 20:52 skrev Phil Hunt <phil.hunt@oracle.com&g= t;:

At present we do not have any security = considerations for sensitive data (e.g. passwords).  

Am thinking we should have some general verbiage around t= he issues/best practice around things like passwords that need to be salted= /hashed appropriately.  To some implementers as a pure=0A provisioning= protocol there may be no impact. But for those building SCIM on top of a p= ersistence system (e.g. database), the considerations become important. The= re=E2=80=99s lots of stuff to reference here, especially from the OAuth Thr= eat Model document as well as LDAP.

The other issue is whether this goes in the API or the core-schema draft (= or both).

=0A
<= div style=3D"word-wrap:break-word;">
Phil

=
@independentid
phil.= hunt@oracle.com


=0A
=0A
______________________________= _________________
scim mailing listscim@ietf.o= rg
https:/= /www.ietf.org/mailman/listinfo/scim

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


=0A
__________________= _____________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/list= info/scim

__________________= _____________________________
scim mailing l= ist
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

______________________________________________= _
scim mailing list
scim@ietf.org=
https://www.ietf.org/mailman/listinfo/s= cim


--515012262-235877667-1405705882=:99642-- From nobody Fri Jul 18 11:12:56 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42A01B2A23 for ; Fri, 18 Jul 2014 11:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFLVyN1Mu38l for ; Fri, 18 Jul 2014 11:12:49 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 650341B2A21 for ; Fri, 18 Jul 2014 11:12:49 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6IIClK1016483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Jul 2014 18:12:48 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6IIClbD022703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jul 2014 18:12:47 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s6IICiEO022372; Fri, 18 Jul 2014 18:12:45 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 18 Jul 2014 11:12:44 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_542CC3E2-C89A-4172-AD57-0F18CE7A6534" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <1405705882.99642.YahooMailNeo@web142806.mail.bf1.yahoo.com> Date: Fri, 18 Jul 2014 11:12:42 -0700 Message-Id: References: <57BAE65C-6176-4E31-AFAB-CF6DFE9DDEE4@oracle.com> <1405703897.41499.YahooMailNeo@web142806.mail.bf1.yahoo.com> <1405705882.99642.YahooMailNeo@web142806.mail.bf1.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Xt7by52QDPf9Z55r4KQq7A0HglM Cc: Leif Johansson , SCIM WG Subject: Re: [scim] Security considerations: sensitive data X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 18:12:52 -0000 --Apple-Mail=_542CC3E2-C89A-4172-AD57-0F18CE7A6534 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 +1 I would add =93provisioning=94 to that as well. 8-) Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 18, 2014, at 10:51 AM, Bill Mills wrote: > "SCIM is a data syndication/publication/query tool, as such it may be = used as the data source/sink for an authentication system acting as a = client or peer." >=20 >=20 > On Friday, July 18, 2014 10:45 AM, Leif Johansson = wrote: >=20 >=20 >=20 >=20 > 18 jul 2014 kl. 19:41 skrev Phil Hunt : >=20 >=20 > I posted some improved authen text in another thread. >=20 > I believe strongly we are going to have to address credential = management one way or another in a future charter. >=20 >=20 > Lets deal w this when somebody defines an extension for it! >=20 >> The real issue is because people are building web UI servers and = HTML5 code that contact SCIM endpoints to provide user self-service = features. >=46rom a protocol perspective, its hard to differentiate = from a client doing the bad thing of sync=92ing passwords, to a UI = component simply setting the password via a cloud SCIM endpoint. For = example, a set-top box might make a SCIM call to update a password as it = presents its own UI to the end-user. The set top box may use an OAuth = token that enables the SCIM endpoint to trust the box to make such a = change. >>=20 >> I am ok with saying SCIM does not do authentication. But to say that = passwords cannot be validated(matched) would be wrong. >=20 > There are many a rat buried there. >=20 >> At best it can be simply a single factor confirmation. An = authentication system SHOULD be much more than this (e.g. establishing a = session, validating multiple factors). All of which fall out of scope = of SCIM. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >> On Jul 18, 2014, at 10:18 AM, Bill Mills = wrote: >>=20 >>> In fact SCIM is very weak/silent on the whole authn/authz subject. >>>=20 >>>=20 >>> On Friday, July 18, 2014 7:06 AM, Leif Johansson = wrote: >>>=20 >>>=20 >>> I think we should say that scim is not an authentication protocol = and any resemblance to one is accidental and that using scim for = provisioning credentials should be avoided.=20 >>>=20 >>> Thats the way to avoid lots of ratholes! >>>=20 >>> 17 jul 2014 kl. 20:52 skrev Phil Hunt : >>>=20 >>>=20 >>> At present we do not have any security considerations for sensitive = data (e.g. passwords). =20 >>>=20 >>> Am thinking we should have some general verbiage around the = issues/best practice around things like passwords that need to be = salted/hashed appropriately. To some implementers as a pure = provisioning protocol there may be no impact. But for those building = SCIM on top of a persistence system (e.g. database), the considerations = become important. There=92s lots of stuff to reference here, especially = from the OAuth Threat Model document as well as LDAP. >>>=20 >>> The other issue is whether this goes in the API or the core-schema = draft (or both). >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>>=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 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=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 --Apple-Mail=_542CC3E2-C89A-4172-AD57-0F18CE7A6534 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 +1

I would add =93provisioning=94 = to that as well. 8-)

Phil

On Jul 18, 2014, at 10:51 AM, Bill Mills <wmills_92105@yahoo.com> = wrote:

"SCIM is a data = syndication/publication/query tool, as such it may be used as the data = source/sink for an authentication system acting as a client or = peer."


On Friday, July 18, 2014 10:45 AM, Leif Johansson <leifj@mnt.se> wrote:
 =




18 jul 2014 kl. 19:41 skrev Phil Hunt <phil.hunt@oracle.com>:

I posted some improved = authen text in another thread.

I = believe strongly we are going to have to address credential management = one way or another in a future charter.


Lets deal w this = when somebody defines an extension for it!

The real issue is because = people are building web UI servers and HTML5 code that contact SCIM = endpoints to provide user self-service features.  >=46rom a = protocol perspective, its hard to differentiate from a client doing the = bad thing of sync=92ing passwords, to a UI component simply setting the = password via a cloud SCIM endpoint.  For example, a set-top box might make a SCIM = call to update a password as it presents its own UI to the end-user. =  The set top box may use an OAuth token that enables the SCIM = endpoint to trust the box to make such a change.

I am ok with saying SCIM does not do = authentication. But to say that passwords cannot be validated(matched) = would be wrong.

There are many a rat buried there.

At best it can be simply a = single factor confirmation. An authentication system SHOULD be much more = than this (e.g. establishing a session, validating multiple factors). =  All of which fall out of scope of SCIM.

Phil

On Jul 18, 2014, at 10:18 AM, Bill Mills = <wmills_92105@yahoo.com> = wrote:

In fact SCIM is very = weak/silent on the whole authn/authz subject.


On Friday, = July 18, 2014 7:06 AM, Leif Johansson <leifj@mnt.se> wrote:


=
I think we should say that scim is not an = authentication protocol and any resemblance to one is accidental and = that using scim for provisioning credentials should be avoided. 

Thats = the way to avoid lots of ratholes!

17 jul 2014 kl. 20:52 skrev Phil Hunt <phil.hunt@oracle.com>:

At = present we do not have any security considerations for sensitive data = (e.g. passwords).  

Am thinking = we should have some general verbiage around the issues/best practice = around things like passwords that need to be salted/hashed = appropriately.  To some implementers as a pure provisioning protocol there may be no impact. But for those building = SCIM on top of a persistence system (e.g. database), the considerations = become important. There=92s lots of stuff to reference here, especially = from the OAuth Threat Model document as well as LDAP.

The other issue is whether this goes in the = API or the core-schema draft (or both).

_______________________________________________=
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/m= ailman/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/ma= ilman/listinfo/scim

= --Apple-Mail=_542CC3E2-C89A-4172-AD57-0F18CE7A6534-- From nobody Fri Jul 18 12:34:32 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1A41B2A71 for ; Fri, 18 Jul 2014 12:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAvMF81-OwQj for ; Fri, 18 Jul 2014 12:34:28 -0700 (PDT) Received: from nm47-vm1.bullet.mail.bf1.yahoo.com (nm47-vm1.bullet.mail.bf1.yahoo.com [216.109.115.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0389C1B2A70 for ; Fri, 18 Jul 2014 12:34:27 -0700 (PDT) Received: from [98.139.215.140] by nm47.bullet.mail.bf1.yahoo.com with NNFMP; 18 Jul 2014 19:34:27 -0000 Received: from [98.139.212.226] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 18 Jul 2014 19:34:27 -0000 Received: from [127.0.0.1] by omp1035.mail.bf1.yahoo.com with NNFMP; 18 Jul 2014 19:34:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 137792.36359.bm@omp1035.mail.bf1.yahoo.com Received: (qmail 93959 invoked by uid 60001); 18 Jul 2014 19:34:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1405712067; bh=Jo0hZw26NdPUI3lFsNPMw1CHsTbH57bOlXic7CLihVU=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VQu3y9aWBJOB90bKmZXsiRYPIdvLOXvR9Bk7kvkLQrLQAd2Fx4c70mEILY+5EN4YaU/92JQh+7I2SNSjviotvyMHTpPxX8Py+ceHuto96TvKVkTkbPsrWx/hr4zwCMhr9Kpb6pkpBrdNzh6VKldo8+NbgydBpAtfXrkGg/9FvA0= X-YMail-OSG: M_Po0ZgVM1ljmuC7P4NfYbwKVEzns0VL6Mu71PaFydW2t0C 4eprEudwBFwu7KMxI3qPBQKp97oi_Vd0kY4MQnn2TIYmnKok8il7qUkEkt0b PUPqR6iW50JFCY7b4iFtvFa51U57VvMoapiO8zK639ymxKVA1ouUK.gPpx.x sChMrWZXmyK.f1uW0q3JM6h1j0Xb_E391cci5ncEjlvhZxcharAHAMGDjbo4 6K8Du6dFnh6K.2SsG4EGLV1p_ktqNtDILyjUbQV7mc.6U1.lpSQhbPCVHqVv E8hkmSM3k.hqOxMuIF1sR24yHkxmU_JUWZDM2MehAk7NPYTzOjXQglerHSc7 e6uN_1a4yVZvC7QifMU.G6pOvggQUZKLr8g6bPiRfElP034aATu3UNaQiuoa ulOmbZ8XICcLvGN6v17.gnlCTQjNUP9AJavhgMesNQqxRDA6tq15H.DwjBFz MJbT6ZCecN1.yNG8JhPyFsSum4.YsRB8k9wVWfuV3yle_nXEDuMrlUTIwpjx crlB3kskwerPboymIuk4X1jXM73FLy5b6XezOAY13725.POGDwdUrVTIOzE2 509wGTTduQojMp6plbFm5zU8bEmQLl1RK25tLQQWDgEZGMA2v7hrpZ_ewA93 giIO7FNcJt6fL12M.Q3NNxTdUfITVAeY36.qb2b0JYsLNOw-- Received: from [167.220.24.190] by web142805.mail.bf1.yahoo.com via HTTP; Fri, 18 Jul 2014 12:34:26 PDT X-Rocket-MIMEInfo: 002.001, V29ya3MgZm9yIG1lIHRvIGFkZCBwcm92aXNpb25pbmcuIMKgSWYgaXQncyBub3QgaW4gdGhlIHNwZWMgaXQgY291bGQgYmUgdG8gbWFrZSBjbGVhciBpdCdzIG5vdCBhbiBhdXRoIHN5c3RlbS4KCgpPbiBGcmlkYXksIEp1bHkgMTgsIDIwMTQgMTE6MTIgQU0sIFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb20.IHdyb3RlOgogCgoKKzEKCkkgd291bGQgYWRkIOKAnHByb3Zpc2lvbmluZ.KAnSB0byB0aGF0IGFzIHdlbGwuIDgtKQoKUGhpbAoKCkBpbmRlcGVuZGVudGlkCnd3dy5pbmRlcGVuZGVudGlkLmMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.195.683 References: <57BAE65C-6176-4E31-AFAB-CF6DFE9DDEE4@oracle.com> <1405703897.41499.YahooMailNeo@web142806.mail.bf1.yahoo.com> <1405705882.99642.YahooMailNeo@web142806.mail.bf1.yahoo.com> Message-ID: <1405712066.50079.YahooMailNeo@web142805.mail.bf1.yahoo.com> Date: Fri, 18 Jul 2014 12:34:26 -0700 From: Bill Mills To: Phil Hunt In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1583497461-566165197-1405712066=:50079" Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Z2ccVVpGk13Ujz58JyTX2UlMaeg Cc: Leif Johansson , SCIM WG Subject: Re: [scim] Security considerations: sensitive data X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 19:34:29 -0000 --1583497461-566165197-1405712066=:50079 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Works for me to add provisioning. =C2=A0If it's not in the spec it could be= to make clear it's not an auth system.=0A=0A=0AOn Friday, July 18, 2014 11= :12 AM, Phil Hunt wrote:=0A =0A=0A=0A+1=0A=0AI would= add =E2=80=9Cprovisioning=E2=80=9D to that as well. 8-)=0A=0APhil=0A=0A=0A= @independentid=0Awww.independentid.comphil.hunt@oracle.com=0A=0A=0A=0AOn Ju= l 18, 2014, at 10:51 AM, Bill Mills wrote:=0A=0A"S= CIM is a data syndication/publication/query tool, as such it may be used as= the data source/sink for an authentication system acting as a client or pe= er."=0A>=0A>=0A>=0A>On Friday, July 18, 2014 10:45 AM, Leif Johansson wrote:=0A> =0A>=0A>=0A>=0A>=0A>=0A>18 jul 2014 kl. 19:41=0A skrev= Phil Hunt :=0A>=0A>=0A>I posted some improved authen= text in another thread.=0A>=0A>=0A>I believe strongly we are going to have= to address credential management one way or another in a future charter.= =0A>=0A>=0A>=0A>=0A>Lets deal w this when somebody defines an extension for= it!=0A>=0A>The real issue is because people are building web UI servers an= d HTML5 code that contact SCIM endpoints to provide user self-service featu= res. =C2=A0>From a protocol perspective, its hard to differentiate from a c= lient doing the bad thing of sync=E2=80=99ing passwords, to a UI component = simply setting the password via a cloud SCIM endpoint. =C2=A0For example, a= set-top box might make a SCIM call to update a password as it presents its= own UI to the end-user. =C2=A0The set top box may use an OAuth token that = enables the SCIM endpoint to trust the box to make such a change.=0A>>=0A>>= =0A>>I am ok with saying SCIM does not do authentication. But to say that p= asswords cannot be validated(matched) would be wrong. =0A>=0A>=0A>There are= many a rat buried there.=0A>=0A>=0A>At best it can be simply a single fact= or confirmation. An authentication system SHOULD be much more than this (e.= g. establishing a session, validating multiple factors). =C2=A0All of which= fall out of scope of SCIM.=0A>>=0A>>=0A>>Phil=0A>>=0A>>=0A>>@independentid= =0A>>www.independentid.comphil.hunt@oracle.com=0A>>=0A>>=0A>>=0A>>=0A>>On J= ul 18, 2014, at 10:18 AM, Bill Mills wrote:=0A>>= =0A>>In fact SCIM is very weak/silent on the whole authn/authz subject.=0A>= >>=0A>>>=0A>>>=0A>>>On Friday, July 18, 2014 7:06 AM, Leif Johansson wrote:=0A>>> =0A>>>=0A>>>=0A>>>I think we should say that scim is = not an authentication protocol and any resemblance to one is accidental and= that using scim for provisioning credentials should be avoided.=C2=A0=0A>>= >=0A>>>=0A>>>Thats the way to avoid lots of ratholes!=0A>>>=0A>>>17 jul 201= 4 kl. 20:52 skrev Phil Hunt :=0A>>>=0A>>>=0A>>>At pre= sent we do not have any security considerations for sensitive data (e.g. pa= sswords). =C2=A0=0A>>>=0A>>>=0A>>>Am thinking we should have some general v= erbiage around the issues/best practice around things like passwords that n= eed to be salted/hashed appropriately. =C2=A0To some implementers as a pure= provisioning protocol there may be no impact. But for those building SCIM = on top of a persistence system (e.g. database), the considerations become i= mportant. There=E2=80=99s lots of stuff to reference here, especially from = the OAuth Threat Model document as well as LDAP.=0A>>>=0A>>>=0A>>>The other= issue is whether this goes in the API or the core-schema draft (or both).= =0A>>>=0A>>>=0A>>>Phil=0A>>>=0A>>>=0A>>>@independentid=0A>>>www.independent= id.comphil.hunt@oracle.com=0A>>>=0A>>>=0A>>>=0A>>>=0A>>>___________________= ____________________________=0A>>>>scim mailing list=0A>>>>scim@ietf.org=0A= >>>>https://www.ietf.org/mailman/listinfo/scim=0A>>>>=0A>>>>=0A>>>=0A>>>=0A= >>>_______________________________________________=0A>>>scim mailing list= =0A>>>scim@ietf.org=0A>>>https://www.ietf.org/mailman/listinfo/scim=0A>>>= =0A>>>=0A>>>=0A>>>_______________________________________________=0A>>>scim= mailing list=0A>>>scim@ietf.org=0A>>>https://www.ietf.org/mailman/listinfo= /scim=0A>>>=0A>>=0A>>=0A>_______________________________________________=0A= >>scim mailing list=0A>>scim@ietf.org=0A>>https://www.ietf.org/mailman/list= info/scim=0A>>=0A>=0A>=0A>_______________________________________________= =0A>scim mailing list=0A>scim@ietf.org=0A>https://www.ietf.org/mailman/list= info/scim=0A>=0A>=0A>=0A>_______________________________________________=0A= >scim mailing list=0A>scim@ietf.org=0A>https://www.ietf.org/mailman/listinf= o/scim=0A> --1583497461-566165197-1405712066=:50079 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Works for me to add provisioning.  If it's no= t in the spec it could be to make clear it's not an auth system.


On Friday, July 18, 2014 11:12 AM, Phil Hunt &= lt;phil.hunt@oracle.com> wrote:


+1

I would add =E2=80=9Cprovisioning=E2=80=9D to that as well. 8= -)

Phil<= /div>
<= span class=3D"yiv9693767832Apple-style-span" style=3D"border-collapse:separ= ate;border-spacing:0px;">
<= /span>

@independentid
<= a rel=3D"nofollow" shape=3D"rect" target=3D"_blank" href=3D"http://www.inde= pendentid.com/">www.independentid.com
phil.hunt@oracle.com


=0A
= =0A
On Jul 18, 2014, at 10:51 AM, Bill Mills &l= t;wmills_92105@y= ahoo.com> wrote:

"SCIM is a data syndication/publication/query tool, as such it may be use= d as the data source/sink for an authentication system acting as a client o= r peer."


= On Friday, July 18, 2014 10:45 AM, Leif Johansson <leifj@mnt.se> wrote:
 <= /div>



18 jul 2014 kl. 19:41=0A skrev Phil Hunt <phil.hunt@oracle.com&= gt;:

<= div>
I posted some improved authen text in ano= ther thread.

I believe strongly we are go= ing to have to address credential management one way or another in a future= charter.


=
Lets deal w this when somebody defines an extension for it!

The real issue is because peop= le are building web UI servers and HTML5 code that contact SCIM endpoints t= o provide user self-service features.  >From a protocol perspective= , its hard to differentiate from a client doing the bad thing of sync=E2=80= =99ing passwords, to a UI component simply setting the password via a=0A cl= oud SCIM endpoint.  For example, a set-top box might make a SCIM call = to update a password as it presents its own UI to the end-user.  The s= et top box may use an OAuth token that enables the SCIM endpoint to trust t= he box to make such a change.

I am = ok with saying SCIM does not do authentication. But to say that passwords c= annot be validated(matched) would be wrong.

There are many a rat buried there.

At best it can be simply a single fac= tor confirmation. An authentication system SHOULD be much more than this (e= .g. establishing a session, validating multiple factors).  All of whic= h fall out of scope of SCIM.

Phil
=0A
On Jul 18, 2014, at 10:18= AM, Bill Mills <wmills_92105@yahoo.com> wrote:

In fact SCIM is very weak/silent on the whole authn/aut= hz subject.


On Friday, July= 18, 2014 7:06 AM, Leif Johansson <leifj@mnt.se> wrote:


<= div id=3D"yiv9693767832">
I think we should say that scim is not a= n authentication protocol and any resemblance to one is accidental and that= using scim for provisioning credentials=0A should be avoided. 
<= div>
Thats the way to avoid lots of ratholes!<= /div>

17 jul 2014 kl. 20:52 skrev Phil Hunt <phil.hunt@oracle.com&g= t;:

At present we do not have any security = considerations for sensitive data (e.g. passwords).  

Am thinking we should have some general verbiage around t= he issues/best practice around things like passwords that need to be salted= /hashed appropriately.  To some implementers as a pure=0A provisioning= protocol there may be no impact. But for those building SCIM on top of a p= ersistence system (e.g. database), the considerations become important. The= re=E2=80=99s lots of stuff to reference here, especially from the OAuth Thr= eat Model document as well as LDAP.

The other issue is whether this goes in the API or the core-schema draft (= or both).

=0A
<= div style=3D"word-wrap:break-word;">
Phil

=
@independentid
phil.= hunt@oracle.com


=0A
=0A
______________________________= _________________
scim mailing listscim@ietf.o= rg
https:/= /www.ietf.org/mailman/listinfo/scim


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


=0A
___________________________= ____________________
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 listscim@ietf.org<= br clear=3D"none">https://www.ietf.org/mailma= n/listinfo/scim


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



= --1583497461-566165197-1405712066=:50079-- From nobody Fri Jul 18 12:48:56 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425871B296D for ; Fri, 18 Jul 2014 12:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id das-5byDNV6o for ; Fri, 18 Jul 2014 12:48:51 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAC4F1A01BD for ; Fri, 18 Jul 2014 12:48:50 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id x48so5186915wes.33 for ; Fri, 18 Jul 2014 12:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Rta1XWYU/hFWL35aATIEfsY4vPQ/e8woHHXk/w1f1Sc=; b=JpUxqopmDtf5AJSudB6i4cKcfzCpCdUr5XFCsCC/BUS012pJJ9m156d/RFeSpEzeNS D/Jr6WE3I6a3G8lW58DbrjogWaUBFEXcFAAURoDtDdd7Hl2vkr+D+NqO1cwbyQ0+94CB Odas1JaoBxd4Esa4qjnmx9TI9wuP6VsWYceb8TsL6qFE0t8+oLSXVxvzdg68jGKjXKgA ClDFoZzu84xV9l7CbbRKc5rotpD76+m+XZsNuR5HRDVbJolMGuDKZDZpiYOWWY5aMp25 Bw8T3A4ND8FGKJV/6sUAMnyaDfxrz//hPogrkOHQoJYFglhQdNNY/kAyfETrD0/NXCHf o2BA== MIME-Version: 1.0 X-Received: by 10.180.184.20 with SMTP id eq20mr4660195wic.37.1405712929422; Fri, 18 Jul 2014 12:48:49 -0700 (PDT) Received: by 10.216.38.3 with HTTP; Fri, 18 Jul 2014 12:48:49 -0700 (PDT) In-Reply-To: References: <57BAE65C-6176-4E31-AFAB-CF6DFE9DDEE4@oracle.com> <1405703897.41499.YahooMailNeo@web142806.mail.bf1.yahoo.com> <1405705882.99642.YahooMailNeo@web142806.mail.bf1.yahoo.com> Date: Fri, 18 Jul 2014 12:48:49 -0700 Message-ID: From: Mahalingam Mani To: Phil Hunt Content-Type: multipart/alternative; boundary=001a11c3536ad085d504fe7d0b1f Archived-At: http://mailarchive.ietf.org/arch/msg/scim/bCxk0fT3G5m_LQQTUx4m81z_HmU Cc: Leif Johansson , William Mills , SCIM WG Subject: Re: [scim] Security considerations: sensitive data X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 19:48:54 -0000 --001a11c3536ad085d504fe7d0b1f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1. Moreover, in addition to the question of password field, other fields that have PI (personal identifier) /PII (personnally identifable information) significance; will also need some security guidance on authorization for access/modification. Thus, at least in security considerations section there needs to reference to the exposures/threats and some guidance on countermeasures. -mani =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Fri, Jul 18, 2014 at 11:12 AM, Phil Hunt wrote: > +1 > > I would add =E2=80=9Cprovisioning=E2=80=9D to that as well. 8-) > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On Jul 18, 2014, at 10:51 AM, Bill Mills wrote: > > "SCIM is a data syndication/publication/query tool, as such it may be use= d > as the data source/sink for an authentication system acting as a client o= r > peer." > > > On Friday, July 18, 2014 10:45 AM, Leif Johansson wrote: > > > > > 18 jul 2014 kl. 19:41 skrev Phil Hunt : > > I posted some improved authen text in another thread. > > I believe strongly we are going to have to address credential management > one way or another in a future charter. > > > Lets deal w this when somebody defines an extension for it! > > The real issue is because people are building web UI servers and HTML5 > code that contact SCIM endpoints to provide user self-service features. > >From a protocol perspective, its hard to differentiate from a client > doing the bad thing of sync=E2=80=99ing passwords, to a UI component simp= ly setting > the password via a cloud SCIM endpoint. For example, a set-top box might > make a SCIM call to update a password as it presents its own UI to the > end-user. The set top box may use an OAuth token that enables the SCIM > endpoint to trust the box to make such a change. > > I am ok with saying SCIM does not do authentication. But to say that > passwords cannot be validated(matched) would be wrong. > > > There are many a rat buried there. > > At best it can be simply a single factor confirmation. An authentication > system SHOULD be much more than this (e.g. establishing a session, > validating multiple factors). All of which fall out of scope of SCIM. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On Jul 18, 2014, at 10:18 AM, Bill Mills wrote: > > In fact SCIM is very weak/silent on the whole authn/authz subject. > > > On Friday, July 18, 2014 7:06 AM, Leif Johansson wrote: > > > I think we should say that scim is not an authentication protocol and any > resemblance to one is accidental and that using scim for provisioning > credentials should be avoided. > > Thats the way to avoid lots of ratholes! > > 17 jul 2014 kl. 20:52 skrev Phil Hunt : > > At present we do not have any security considerations for sensitive data > (e.g. passwords). > > Am thinking we should have some general verbiage around the issues/best > practice around things like passwords that need to be salted/hashed > appropriately. To some implementers as a pure provisioning protocol ther= e > may be no impact. But for those building SCIM on top of a persistence > system (e.g. database), the considerations become important. There=E2=80= =99s lots > of stuff to reference here, especially from the OAuth Threat Model docume= nt > as well as LDAP. > > The other issue is whether this goes in the API or the core-schema draft > (or both). > > 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 > > > _______________________________________________ > 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 > > --001a11c3536ad085d504fe7d0b1f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1.

Moreover, in addition to the questi= on of password field, other fields that have PI (personal identifier) /PII = (personnally identifable information) significance; will also need some sec= urity guidance on authorization for access/modification.
Thus, at least in security considerations section there needs to refer= ence to the exposures/threats and some guidance on countermeasures.

-mani
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


On Fri, Jul 18, 2014 at 11:12 AM, Phil H= unt <phil.hunt@oracle.com> wrote:
+1

I would add =E2= =80=9Cprovisioning=E2=80=9D to that as well. 8-)

<= span style=3D"text-align:-webkit-auto">Phil

@independentid
phil.hunt@oracle.co= m



On Jul 18, 2014, at 10:51 AM, Bill Mills <wmills_92105@yahoo.com> = wrote:

"SCIM is a data syndication/publication/query tool, as such= it may be used as the data source/sink for an authentication system acting= as a client or peer."


On Friday, July 18, 2014 10:45 AM,= Leif Johansson <leifj= @mnt.se> wrote:



18 jul 2014 kl. 19:41 skrev Phil Hunt <phil.hunt@oracle.com>:

I posted some improved authen text in another thread.

I believe strongly we are going to have to address = credential management one way or another in a future charter.

Lets deal w this when somebody def= ines an extension for it!

The real issue is because people are building web UI servers and HTML= 5 code that contact SCIM endpoints to provide user self-service features. = =C2=A0>From a protocol perspective, its hard to differentiate from a cli= ent doing the bad thing of sync=E2=80=99ing passwords, to a UI component si= mply setting the password via a cloud SCIM endpoint. =C2=A0For example, a set-top box might make a SCIM ca= ll to update a password as it presents its own UI to the end-user. =C2=A0Th= e set top box may use an OAuth token that enables the SCIM endpoint to trus= t the box to make such a change.

I am ok with saying SCIM does not do aut= hentication. But to say that passwords cannot be validated(matched) would b= e wrong.

There are ma= ny a rat buried there.

At best it can be si= mply a single factor confirmation. An authentication system SHOULD be much = more than this (e.g. establishing a session, validating multiple factors). = =C2=A0All of which fall out of scope of SCIM.

Phil


In fact SCIM is very weak/silent on the who= le authn/authz subject.


On Friday, July 18, 2014 7:06 AM, = Leif Johansson <leifj@mnt.se> wrote:


I think we sho= uld say that scim is not an authentication protocol and any resemblance to = one is accidental and that using scim for provisioning credentials should be avoided.=C2=A0

Thats the= way to avoid lots of ratholes!

17 jul 20= 14 kl. 20:52 skrev Phil Hunt <phil.hunt@oracle.com>= ;:

At present we do not have any security consider= ations for sensitive data (e.g. passwords). =C2=A0

<= /div>
Am thinking we should have some general verbiage around the issues/best pra= ctice around things like passwords that need to be salted/hashed appropriat= ely. =C2=A0To some implementers as a pure provisioning protocol there may be no impact. But for those building SCIM = on top of a persistence system (e.g. database), the considerations become i= mportant. There=E2=80=99s lots of stuff to reference here, especially from = the OAuth Threat Model document as well as LDAP.

The other issue is whether this goes in = the API or the core-schema draft (or both).

__________________= _____________________________
scim mailing l= ist
scim@ietf.org
https://www.ietf.org/mailman/listinfo/s= cim

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


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

_______________________________________________
scim mailing list
scim@iet= f.org
https://www.ietf.org/mailman/listinfo/s= cim

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


_______________________________________________
scim mai= ling list
scim@ietf.o= rg
ht= tps://www.ietf.org/mailman/listinfo/scim


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


--001a11c3536ad085d504fe7d0b1f-- From nobody Fri Jul 18 19:18:35 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A092F1A0354 for ; Fri, 18 Jul 2014 19:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdHlK6hHmNAe for ; Fri, 18 Jul 2014 19:18:29 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E78601A0351 for ; Fri, 18 Jul 2014 19:18:28 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6J2IRt4017729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 19 Jul 2014 02:18:28 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6J2IQLq026380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Jul 2014 02:18:27 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s6J2IPog025768; Sat, 19 Jul 2014 02:18:26 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 18 Jul 2014 19:18:25 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_5BFB557B-073D-43B1-B90B-6600E05E03AA" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: Date: Fri, 18 Jul 2014 19:18:23 -0700 Message-Id: References: To: Ian Glazer X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/1c_KlxCldKhTWvoeezcUMrnXvOU Cc: "scim@ietf.org WG" Subject: Re: [scim] Comments for sections 3.4 to the end X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 02:18:31 -0000 --Apple-Mail=_5BFB557B-073D-43B1-B90B-6600E05E03AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ian=85 thanks again. Comments inline Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 15, 2014, at 8:29 AM, Ian Glazer wrote: > Here's a few more comments: >=20 > 3.4 Delete - Does an SP who chooses not to permanently delete a = resource have to tell the client of that choice? The wording in 3.4 is intentional and leaves room for the record to be = retained. However, as far as the REST API is concerned the record is = gone. I=92ve had some thought that we may need to define functions down the = road the provide high-level IDM functions like password self service, = de-provisioning/de-activation, etc that go beyond simple state changes. = If we do that, the way we=92ve worded DELETE for now should be = compatible.=20 >=20 > 3.4 Delete conflicts - "SP MUST not consider deleted resource in = conflict calculation" - What about situations where the SP requires all = userNames to be unique and holds delete accounts to ensure no repetition = of userNames? This might cause a problem for Salesforce. Yes. This is an issue. The current text says the SP is to act as if the = resource is gone. That potentially means freeing up old user-ids.=20 Yet, I can see it is perfectly reasonable that a SP may never release a = username once used. Maybe the wording we have is a bit too tight? >=20 > 3.5 Bulk - Maybe my memory failed me here but I thought we were = carving Bulk out as its own profile to be dealt with later. Given that = no one has implemented it I wonder if it doesn't make sense to = completely pull it and put it into a future profile. I think I commented earlier =97 several orgs were starting = implementation the last time we discussed. I think the idea will be to = discuss in Toronto and confirm we are keeping it. >=20 > 3.5 Bulk - formatting issue - Page 38 of the pdf. The paragraph = beginning "The following example shows how to add..." is formatted like = example code not regular text. Will fix. >=20 > 3.5 Bulk - formatting issue - Page 40 of the pdf. The paragraph = beginning "The following response is returned if an error occurred..." = is formatted like example code not regular text. Will fix >=20 > 3.5 Bulk - formatting issue - same problems on pages 41 and 42 as 38 = and 40. Ditto. >=20 > 3.7 attributes - If "attributes" are specified, it isn't clear if = default attributes are also returned along with the minimum set and = those specified. I think this needs to say explicitly that default = attributes are not returned when "attributes" are specified. Will correct. >=20 > 6.4 - Universal Identifiers - ? I saw that today. I can=92t recall what that was about. I think it was = going to be a caution about using things like DN=92s as identifiers and = the need to ensure universality and stability (does not change).=20 Maybe someone else recalls? >=20 >=20 > --=20 > Ian Glazer > Senior Director, Identity > +1 202 255 3166 > @iglazer > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_5BFB557B-073D-43B1-B90B-6600E05E03AA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Ian=85 = thanks again.  Comments inline


On Jul 15, 2014, at 8:29 AM, Ian Glazer <iglazer@salesforce.com> = wrote:

Here's a few more = comments:

3.4 Delete - Does an SP who chooses = not to permanently delete a resource have to tell the client of that = choice?

The wording in 3.4 = is intentional and leaves room for the record to be retained. However, = as far as the REST API is concerned the record is = gone.

I=92ve had some thought that we may need = to define functions down the road the provide high-level IDM functions = like password self service, de-provisioning/de-activation, etc that go = beyond simple state changes.  If we do that, the way we=92ve worded = DELETE for now should be compatible. 

3.4 Delete = conflicts - "SP MUST not consider deleted resource in conflict = calculation" -  What about situations where the SP requires all = userNames to be unique and holds delete accounts to ensure no repetition = of userNames? This might cause a problem for = Salesforce.

Yes. This is an = issue. The current text says the SP is to act as if the resource is = gone.  That potentially means freeing up old = user-ids. 

Yet, I can see it is perfectly = reasonable that a SP may never release a username once used. Maybe the = wording we have is a bit too tight?

3.5 Bulk - Maybe my memory failed me here but I = thought we were carving Bulk out as its own profile to be dealt with = later. Given that no one has implemented it I wonder if it doesn't make = sense to completely pull it and put it into a future = profile.

I think I = commented earlier =97 several orgs were starting implementation the last = time we discussed. I think the idea will be to discuss in Toronto and = confirm we are keeping it.

3.5 Bulk - formatting issue - Page 38 of the pdf. = The paragraph beginning "The following example shows how to add..." is = formatted like example code not regular = text.

Will = fix.

3.5 Bulk - formatting issue - Page 40 of the pdf. The paragraph = beginning "The following response is returned if an error occurred..." = is formatted like example code not regular = text.
Will fix

3.5 Bulk - = formatting issue - same problems on pages 41 and 42 as 38 and = 40.
Ditto.

3.7 attributes - If "attributes" are specified, it = isn't clear if default attributes are also returned along with the = minimum set and those specified. I think this needs to say explicitly = that default attributes are not returned when "attributes" are = specified.

Will = correct.

6.4 - Universal Identifiers - = ?

I saw that today. I can=92t= recall what that was about.  I think it was going to be a caution = about using things like DN=92s as identifiers and the need to ensure = universality and stability (does not = change). 

Maybe someone else = recalls?


--
Ian Glazer
Senior Director, = Identity
+1 202 255 3166
_______________________________________________
scim mailing = list
scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim

= --Apple-Mail=_5BFB557B-073D-43B1-B90B-6600E05E03AA-- From nobody Sat Jul 19 11:29:12 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D69C1B299E for ; Sat, 19 Jul 2014 11:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghhksbmmasW7 for ; Sat, 19 Jul 2014 11:29:07 -0700 (PDT) Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 608FE1B2854 for ; Sat, 19 Jul 2014 11:29:05 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id u56so5809147wes.14 for ; Sat, 19 Jul 2014 11:29:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=GEA0mvIcS+7xBE6e3g6ZpUXtXCLjjAcO8oj9FXrpK2U=; b=ZnD573J5LUam5wYV9MIYOXDsnX7JzeZ5gZHcZgk77CQlU3Qb+PtiAZ/LQiGh4XNHbc zxs2VyT2bzLOMepEX2KfwWX5okiZkzh0/5bCa8Z3E9m4MErz3R+bfZJW4kMDdU8xSQv2 8C2YYgCQ1LZj9CSqYpW8dGSAjo3wbgcMKAqfjTV0ibYu4bHXKOk59ilyqwZcYJADnNMQ WKOr4yHy72pd3eJJQX0ycqTgOUGqFw+MBoQoH6pEePqrIBrDGQauF/WrcRQRNw/ipk14 wjpif96O6X/oL3UpH3P7UMfu8XpAl/TFnHW5OCfqaYsOwz/ivt+eW/6hxU/hNr8pEVCF kglw== X-Gm-Message-State: ALoCoQnLJz5dANmWOubtlwUfDrmTacTgbJ1ynd920eFUKQT8hfM8vH6hH7mCqnk3YnAeZXL77iso X-Received: by 10.180.20.105 with SMTP id m9mr16193200wie.6.1405794544688; Sat, 19 Jul 2014 11:29:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.119.6 with HTTP; Sat, 19 Jul 2014 11:28:44 -0700 (PDT) In-Reply-To: <3ADF1D27-C771-4645-814E-324D51353674@oracle.com> References: <3ADF1D27-C771-4645-814E-324D51353674@oracle.com> From: Ian Glazer Date: Sat, 19 Jul 2014 11:28:44 -0700 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=bcaec53f359176bcea04fe900cb9 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/it11iz6-zm0ZHJAhWBwn9E8EsXA Cc: "scim@ietf.org WG" Subject: Re: [scim] Comments so sections 1 through 3.3 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 18:29:10 -0000 --bcaec53f359176bcea04fe900cb9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for going through these Phil. Comments below On Thu, Jul 17, 2014 at 4:46 PM, Phil Hunt wrote: > Ian, > > Thanks for the thorough walk through. > > Comments in line below. > > Thanks for the feedback. Many of these are obvious and will plan to put > them in the document following Toronto (unless I hear objections). Others= I > will add to the list of discussion items for Toronto. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On Jul 14, 2014, at 11:00 AM, Ian Glazer wrote: > > Here are my early comments on the above sections. I'll grind through more > of this a bit later. > > 1.1 - "identity service providers and client" - This is a little > confusing. Do we mean identity providers and consumers? providers of > identity services and organizations that consume those services? > > > How about just =E2=80=9Cweb service providers and clients=E2=80=9D. The = fact that it is a > protocol around identity isn=E2=80=99t near as important as that it is an= HTTP > protocol. > > Works for me > > 1.3 - URL versus URI - There might be a bit of a inconsistency here. > > > Will Fix. I think the issue here is that it must be a URL (accessible via > HTTP) but IETF seems to always want URIs regardless. > > > 2. - The section is titled "Authentication and Authorization" but > authorization isn't directly addressed. The sentence "Appropriate securit= y > considerations of the selected authentication and authorization schemes > SHOULD be taken" isn't actionable - it is a motherhood and apple pie > statement. Do we want to specifically mention scopes as an authorization > mechanism? Do we just want to cut "Authorization" from the section header= ? > > > I have already attempted to create a better way of describing this: > > Because SCIM uses HTTP protocol, it does not define a scheme for > authentication and authorization. It depends on standard HTTP > authentication schemes. It is RECOMMENDED that clients be > implemented in such a way that new authentication schemes can be > deployed. Implementers SHOULD support existing authentication/ > authorization schemes. In particular, OAuth2 [RFC6750] is > RECOMMENDED. Appropriate security considerations of the selected > authentication and authorization schemes SHOULD be taken. Because > this protocol uses HTTP response status codes as the primary means of > reporting the result of a request, servers are advised to respond to > unauthorized or unauthenticated requests using the 401 response code > in accordance with Section 3.1 of [RFC7235]. > > All examples show an OAuth2 bearer token [RFC6750] (thought it is not > required) ; e.g., > > GET /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1 > Host: example.com > Authorization: Bearer h480djs93hd8 > > The context of the request (i.e. the user for whom data is being > requested) MUST be inferred by service providers. > > That said, do we want to get into a standardized authorization model? > Maybe this is something as a future draft specification. Particularly if > we want to talk about a future SCIM Directory specification. > > Not a huge fan of of standardizing the authZ model right now. I think there are more worms in that can than we want to deal with right now. > > 3. API - Did we decided whether SCIM is an API or a protocol? For > consistency-sake, the title of this section and the first sentence may ne= ed > to change accordingly. > > > Per my previous email. I=E2=80=99ve had some recommendation that API alwa= ys refers > to a programming library interface rather than over the wire semantics. > Thus I have begun changing to the SCIM protocol or SCIM HTTP protocol whe= re > appropriate. > > Note we need to discuss the issue of renaming the SCIM API draft to SCIM > Protocol draft. > > > 3. POST - "or bulk modify resources" - Bulk? I thought that bulk was off > the table for this draft? > > > There was some discussion on one of the calls (I can=E2=80=99t remember i= f we > followed up on the list). The feeling was that many are beginning to > implement now. We=E2=80=99d like to keep it in place for now but we agree= d it may > not make the final cut. This should be a discussion item for Toronto. > > I'd push to remove it but it isn't a deal breaker for us. > > 3. PUT - The draft reads "PUT SHOULD NOT be used to create new resources.= " > Should that SHOULD actually be a MUST? > > > I=E2=80=99m open to some discussion here. I=E2=80=99m not sure if there a= re limited > scenarios whereby the implementation has to allow this. > > > 3. API Table - minor nit - only some of the sections are properly linked > in the PDF > > > Ok. Weird. Will take a look. Seems like an xml2rfc issue (the xml > references the same way for each item). > > > 3. API Table - /Bulk - I thought we weren't dealing with Bulk for v2 and > were going to handle it via profile later > > See above > > > 3.1 - "Successful resource creation..." - It is unclear from the second > sentence whether the entire object MUST be returned or can the server > simply return back a pointer to the newly created object? > > Assume you are referring to: > > Upon successful creation, the response body MUST > contain the newly created resource. > > > Maybe it should say =E2=80=9Cthe newly created service provider represent= ation of > the full resource=E2=80=9D? > > > That doesn't address my poorly made point... What I am trying to ask is: does it make sense to always hand back the new complete object? Would it be more efficient to simply hand back a point to the resource instead? > 3.1 - Is the server required to return a Location header when a resource > is successfully created? Text does not make that clear. > > > Agreed it should say this. > > > 3.1.1. - Just a clarification - "SHALL be set by the service provider" - > in this case service provider means SCIM server and not the client, is th= at > correct? > > > In all cases =E2=80=9Cservice provider=E2=80=9D means the HTTP service, n= ot the provider > of identity data (the client). Maybe we need more terminology text in the > intro on this point. > > > 3.2 Consistency question - Query or Search? > > > Agreed. Any preferences? > > No. > > 3.2.2 Consistency question - it appears that this draft refers to "servic= e > providers," "Providers," and "servers" - does this need to be cleaned up > and made consistent? > > > Agreed see above. > > > 3.2.2.1 - Do we really want to allow a search against the server root tha= t > would result is all objects being returned? Seems like we ought to endors= e > a pattern of querying resourceTypes and then a specific resourceType is a > better way to go. > > > This is regulated by the max results limits. There was a specific example > of being able to search without regard to resource type, or a specific se= t > of resource types. The use case was a search-as-user-types scenario where > the result was not known to be a user or a group. > > > 3.2.2.2 - What happens if someone includes a "ge" search against a > non-numeric or non-date type field? The next isn't clear about a failure > condition. > > Maybe you mis-read. If anything, I see it doesn=E2=80=99t say how numeric > comparisons are made. For strings it is the normal lexicographical > comparison. > > > 3.2.2.3 - Primary attributed - it isn't clear from the text what a primar= y > attribute is. > > > Will add a reference to the multi-valued attribute definition where > primary is defined. > > > 3.2.2.5 - Meta-question - how does a SCIM server indicate whether it > supports attributes and excludedAttributes to be returned (or not) for a > Query? > > > Not sure what you mean. There=E2=80=99s no optionality here. > > Ok, that wasn't obvious from the text. > > 3.2.3 - Figure 2 - the example doesn't use a meta.resourceType attribute > which I think it should to indicate a best practice. > > > Sure. Why not. Might be a good way to say how to search both users and > groups. > > > 3.3.1 - HTTP PUT "SHOULD NOT" or "MUST NOT" be used to create new > resources? > > > See above. > > > 3.3.1 - "If an attribute is required..." - What if the attribute's value > isn't going to change? Does it still need to be sent along? > > > Yes. Since it is a replace, but value must always be supplied - even when > no change. Otherwise it makes missing value logic even more complex. :-) > > > 3.3.1 - "Attributes whose mutability is 'readWrite.' This paragraph seem > very squishy. The server is afforded a lot of latitude which the client m= ay > not be aware of. Should be more prescriptive? Attributes that are omitted > are not changed? > > > The problem here was the issue I raised earlier about understanding the > implied meaning of a missing value: > * omitted because client isn=E2=80=99t aware of it > * omitted because the client does not intend to change it > * omitted because the client wants to default it > * omitted because the client wants to delete it > * omitted because the client doesn=E2=80=99t care > > The squishiness was a result of trying to give the server some room to > interpret. > > This probably still needs more discussion. > > > 3.3.2.1 - I'd move the paragraph before the example up before the list of > possible outcomes. > > ok > > > 3.3.2.2 - I get what happens here but there could be confusion as to > whether Remove sets a value to "null" or not. Is removing an attribute > equivalent to nulling it? > > > I think we=E2=80=99ve informally discussed that for scim, null =3D=3D rem= oved. We > should discuss this in Toronto and formalize this in the spec. Having nu= ll > equal to removed makes the missing/omitted attribute logic on PUT etc > easier to define. > > > 3.3.2.2 - What about mutability? If I attempt to remove a readOnly, can I= ? > What about "required" attributes? > > > Good point. > > > 3.3.2.3 - What about mutability? > > > Agreed. > > > > -- > Ian Glazer > Senior Director, Identity > +1 202 255 3166 > @iglazer > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > --=20 Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --bcaec53f359176bcea04fe900cb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for going through these Phil. Comments below


On Thu, Jul 17, = 2014 at 4:46 PM, Phil Hunt <phil.hunt@oracle.com> wrote:<= br>
Ian= ,

Thanks for the thorough walk through.
=
Comments in line below.

Thanks for the feedback. M= any of these are obvious and will plan to put them in the document followin= g Toronto (unless I hear objections). Others I will add to the list of disc= ussion items for Toronto.

Phil

@independentid
phil.hunt@oracle.co= m



On Jul 14, 2014, at 11:00 AM, Ian Glazer <= iglazer@salesfo= rce.com> wrote:

= Here are my early comments on the above sections. I'll grind through mo= re of this a bit later.

1.1 - "identity service providers and client"= - This is a little confusing. Do we mean identity providers and consumers?= providers of identity services and organizations that consume those servic= es?

How about just =E2=80=9Cweb s= ervice providers and clients=E2=80=9D. =C2=A0The fact that it is a protocol= around identity isn=E2=80=99t near as important as that it is an HTTP prot= ocol.

Works for me=C2=A0

1.3 - URL versus URI - There might be a bit of a incons= istency here.

Will Fix. = I think the issue here is that it must be a URL (accessible via HTTP) but I= ETF seems to always want URIs regardless. =C2=A0


2. = - The section is titled "Authentication and Authorization" but au= thorization isn't directly addressed. The sentence "Appropriate se= curity considerations of the selected authentication and authorization sche= mes SHOULD be taken" isn't actionable - it is a motherhood and app= le pie statement. Do we want to specifically mention scopes as an authoriza= tion mechanism? Do we just want to cut "Authorization" from the s= ection header?

I have already attempted to c= reate a better way of describing this:
   Because SCIM uses HTTP protocol, it does =
not define a scheme for
   authentication and authorization.  It depends on standard HTTP
   authentication schemes.  It is RECOMMENDED that clients be
   implemented in such a way that new authentication schemes can be
   deployed.  Implementers SHOULD support existing authentication/
   authorization schemes.  In particular, OAuth2 [RFC6750] is
   RECOMMENDED.  Appropriate security considerations of the selected
   authentication and authorization schemes SHOULD be taken.  Because
   this protocol uses HTTP response status codes as the primary means of
   reporting the result of a request, servers are advised to respond to
   unauthorized or unauthenticated requests using the 401 response code
   in accordance with Section 3.1 of [RFC7235].

   All examples show an OAuth2 bearer token [RFC6750] (thought it is not
   required) ; e.g.,

   GET /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1
   Host: example.com
   Authorization: Bearer h480djs93hd8

   The context of the request (i.e. the user for whom data is being
   requested) MUST be inferred by service providers.
That said, d= o we want to get into a standardized authorization model? =C2=A0Maybe this = is something as a future draft specification. Particularly if we want to ta= lk about a future SCIM Directory specification.

No= t a huge fan of of standardizing the authZ model right now. I think there a= re more worms in that can than we want to deal with right now.=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

3. API - Did we decided whether SCIM is an API or a pro= tocol? For consistency-sake, the title of this section and the first senten= ce may need to change accordingly.

Per my previous email. I=E2=80=99ve had some recommendation= that API always refers to a programming library interface rather than over= the wire semantics. Thus I have begun changing to the SCIM protocol or SCI= M HTTP protocol where appropriate.

Note we need to discuss the issue of renaming the SCIM = API draft to SCIM Protocol draft.


3. POST - "or bulk modif= y resources" - Bulk? I thought that bulk was off the table for this dr= aft?

There was some discussion on = one of the calls (I can=E2=80=99t remember if we followed up on the list). = The feeling was that many are beginning to implement now. We=E2=80=99d like= to keep it in place for now but we agreed it may not make the final cut. = =C2=A0This should be a discussion item for Toronto.

I'd push to remove it but= it isn't a deal breaker for us.=C2=A0

3. PUT - The draft reads "PUT SHOULD NOT be used t= o create new resources." Should that SHOULD actually be a MUST?
<= /div>

I=E2=80=99m open to some discu= ssion here. I=E2=80=99m not sure if there are limited scenarios whereby the= implementation has to allow this.


3. = API Table - minor nit - only some of the sections are properly linked in th= e PDF

Ok. Weird. Will ta= ke a look. Seems like an xml2rfc issue (the xml references the same way for= each item).


3. API Table - /Bulk - I thought we weren't dealing= with Bulk for v2 and were going to handle it via profile later
=
See above


3.1 - "Successful resource c= reation..." - It is unclear from the second sentence whether the entir= e object MUST be returned or can the server simply return back a pointer to= the newly created object?
Assume you are referring to:
Upon successful cr=
eation, the response body MUST
   contain the newly created resource.

Maybe it sh= ould say =E2=80=9Cthe newly created service provider representation of the = full resource=E2=80=9D?

That doesn't address my poorly made point... What I am trying to= ask is: does it make sense to always hand back the new complete object? Wo= uld it be more efficient to simply hand back a point to the resource instea= d?=C2=A0
3.1 - Is the server required to return a Location header when a resource is= successfully created? Text does not make that clear.

Agreed it should say this.

<= /div>
3.1.1. - Just a clarification - "SHALL be set by the service= provider" - in this case service provider means SCIM server and not t= he client, is that correct?

In all cases =E2=80=9Cservice= provider=E2=80=9D means the HTTP service, not the provider of identity dat= a (the client). Maybe we need more terminology text in the intro on this po= int.


3.2 Consistency question - Query or Search?
=

Agreed. Any preferences?

No.=C2=A0

3.2.2 Consistency qu= estion - it appears that this draft refers to "service providers,"= ; "Providers," and "servers" - does this need to be cle= aned up and made consistent?

Agreed see above.


3.2.2.1 - Do we really want to allow a search against t= he server root that would result is all objects being returned? Seems like = we ought to endorse a pattern of querying resourceTypes and then a specific= resourceType is a better way to go.

This is regulated by the max = results limits. There was a specific example of being able to search withou= t regard to resource type, or a specific set of resource types. The use cas= e was a search-as-user-types scenario where the result was not known to be = a user or a group.


3.2.2.2 - What happens if someone includes a "ge&q= uot; search against a non-numeric or non-date type field? The next isn'= t clear about a failure condition.
Maybe you mis-read. If anything, I see it doesn=E2=80=99t say how numeric c= omparisons are made. For strings it is the normal lexicographical compariso= n.

=
3.2.2.3 - Primary attributed - it isn't clear from the text what a= primary attribute is.

W= ill add a reference to the multi-valued attribute definition where primary = is defined.


3.2.2.5 - Meta-question - how does a SCIM server indica= te whether it supports attributes and excludedAttributes to be returned (or= not) for a Query?

Not sure what you mean. There=E2=80=99s no optionality here.

Ok, that wasn't obvious = from the text.=C2=A0

3.2.3 - Figure 2 - t= he example doesn't use a meta.resourceType attribute which I think it s= hould to indicate a best practice.

Sure. Why not. =C2=A0Might be= a good way to say how to search both users and groups.

=

3.3.1 - HTTP PUT "SHOULD NOT" or "MUST N= OT" be used to create new resources?

See above.


3.3.1 - "If an attribute is = required..." - What if the attribute's value isn't going to ch= ange? Does it still need to be sent along?

Yes. Since it is a replace, but value must always be s= upplied - even when no change. Otherwise it makes missing value logic even = more complex. :-)


3.3.1 - "Attributes whose mutability is 'readW= rite.' This paragraph seem very squishy. The server is afforded a lot o= f latitude which the client may not be aware of. Should be more prescriptiv= e? Attributes that are omitted are not changed?

The problem here was the issu= e I raised earlier about understanding the implied meaning of a missing val= ue:
* omitted because client isn=E2=80=99t aware of it
= * omitted because the client does not intend to change it
* omitted because the client wants to default it
* omitted b= ecause the client wants to delete it
* omitted because the client= doesn=E2=80=99t care

The squishiness was a result= of trying to give the server some room to interpret.

This probably still needs more discussion.


3.3.2.1 - I'd move the paragraph before the example= up before the list of possible outcomes.
ok


3.3.2.2 - I get what happens here but there could be confusi= on as to whether Remove sets a value to "null" or not. Is removin= g an attribute equivalent to nulling it?

I think we=E2=80=99ve informally discussed that f= or scim, null =3D=3D removed. We should discuss this in Toronto and formali= ze this in the spec. =C2=A0Having null equal to removed makes the missing/o= mitted attribute logic on PUT etc easier to define.

3.3.2.2 - What about mutability? If I attempt to remove= a readOnly, can I? What about "required" attributes?
=

Good point.


3.3.2.3 - What about mutability?<= /div>

Agreed.


--
Ian Glazer
Senior Dire= ctor, Identity
_______________________________________________
scim mailing list
scim@ietf.org
https://= www.ietf.org/mailman/listinfo/scim




--
Ian Glazer
Senior Director, Identity
+1 202 255 3166
--bcaec53f359176bcea04fe900cb9-- From nobody Sat Jul 19 20:25:30 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40E71A0336 for ; Sat, 19 Jul 2014 20:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_cqgqQl7nSK for ; Sat, 19 Jul 2014 20:25:26 -0700 (PDT) Received: from canmail.canarie.ca (canmail.canarie.ca [205.189.33.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBA101A0337 for ; Sat, 19 Jul 2014 20:25:25 -0700 (PDT) Received: from THUNDERCHIEF.canarie.local (192.168.1.17) by Thunderchief.canarie.local (192.168.1.17) with Microsoft SMTP Server (TLS) id 15.0.775.38; Sat, 19 Jul 2014 23:25:24 -0400 Received: from THUNDERCHIEF.canarie.local ([::1]) by Thunderchief.canarie.local ([::1]) with mapi id 15.00.0775.031; Sat, 19 Jul 2014 23:25:11 -0400 From: Chris Phillips To: "scim@ietf.org WG" Thread-Topic: [scim] Comments so sections 1 through 3.3 Thread-Index: AQHPn42DkYimmmyg30Gn4Rlyefd2IpulNrIAgALLzACAAFLQAA== Date: Sun, 20 Jul 2014 03:25:10 +0000 Message-ID: References: <3ADF1D27-C771-4645-814E-324D51353674@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [24.246.9.45] Content-Type: multipart/alternative; boundary="_000_CFF0AA7A1ABA91chrisphillipscanarieca_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/abmR9OirE2NyufDlri6GnsdTAzs Subject: Re: [scim] Comments so sections 1 through 3.3 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 03:25:28 -0000 --_000_CFF0AA7A1ABA91chrisphillipscanarieca_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 to Ian's comments on the AuthZ challenges and not modifying the current = SCIM model right now. Chris. From: Ian Glazer > Date: Saturday, 19 July, 2014 2:28 PM To: Phil Hunt > Cc: "scim@ietf.org WG" > Subject: Re: [scim] Comments so sections 1 through 3.3 2. - The section is titled "Authentication and Authorization" but authoriza= tion isn't directly addressed. The sentence "Appropriate security considera= tions of the selected authentication and authorization schemes SHOULD be ta= ken" isn't actionable - it is a motherhood and apple pie statement. Do we w= ant to specifically mention scopes as an authorization mechanism? Do we jus= t want to cut "Authorization" from the section header? I have already attempted to create a better way of describing this: Because SCIM uses HTTP protocol, it does not define a scheme for authentication and authorization. It depends on standard HTTP authentication schemes. It is RECOMMENDED that clients be implemented in such a way that new authentication schemes can be deployed. Implementers SHOULD support existing authentication/ authorization schemes. In particular, OAuth2 [RFC6750] is RECOMMENDED. Appropriate security considerations of the selected authentication and authorization schemes SHOULD be taken. Because this protocol uses HTTP response status codes as the primary means of reporting the result of a request, servers are advised to respond to unauthorized or unauthenticated requests using the 401 response code in accordance with Section 3.1 of [RFC7235]. All examples show an OAuth2 bearer token [RFC6750] (thought it is not required) ; e.g., GET /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1 Host: example.com Authorization: Bearer h480djs93hd8 The context of the request (i.e. the user for whom data is being requested) MUST be inferred by service providers. That said, do we want to get into a standardized authorization model? Mayb= e this is something as a future draft specification. Particularly if we wan= t to talk about a future SCIM Directory specification. Not a huge fan of of standardizing the authZ model right now. I think there= are more worms in that can than we want to deal with right now. --_000_CFF0AA7A1ABA91chrisphillipscanarieca_ Content-Type: text/html; charset="us-ascii" Content-ID: <268ADF8339A6594297F34072F59D3E64@canarie.local> Content-Transfer-Encoding: quoted-printable
+1 to Ian's comments on the AuthZ challenges and not modifying the= current SCIM model right now.

Chris.

From: Ian Glazer <iglazer@salesforce.com>
Date: Saturday, 19 July, 2014 2:28 = PM
To: Phil Hunt <phil.hunt@oracle.com>
Cc: "scim@ietf.org WG" <sci= m@ietf.org>
Subject: Re: [scim] Comments so sec= tions 1 through 3.3


<snip>
2. - The section is titled "Authentication and Authorization"= ; but authorization isn't directly addressed. The sentence "Appropriat= e security considerations of the selected authentication and authorization = schemes SHOULD be taken" isn't actionable - it is a motherhood and apple pie statement. Do we want to specifically mentio= n scopes as an authorization mechanism? Do we just want to cut "Author= ization" from the section header?

I have already attempted to create a better way of describing this:
   Because SC=
IM uses HTTP protocol, it does not define a scheme for
   authentication and authorization.  It depends on standard HTTP
   authentication schemes.  It is RECOMMENDED that clients be
   implemented in such a way that new authentication schemes can be
   deployed.  Implementers SHOULD support existing authentication/
   authorization schemes.  In particular, OAuth2 [RFC6750] is
   RECOMMENDED.  Appropriate security considerations of the selected
   authentication and authorization schemes SHOULD be taken.  Because
   this protocol uses HTTP response status codes as the primary means of
   reporting the result of a request, servers are advised to respond to
   unauthorized or unauthenticated requests using the 401 response code
   in accordance with Section 3.1 of [RFC7235].

   All examples show an OAuth2 bearer token [RFC6750] (thought it is not
   required) ; e.g.,

   GET /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1
   Host: example.com
   Authorization: Bearer h480djs93hd8

   The context of the request (i.e. the user for whom data is being
   requested) MUST be inferred by service providers.
That said, do we want to get into a standardized authorization model? =  Maybe this is something as a future draft specification. Particularly= if we want to talk about a future SCIM Directory specification.

Not a huge fan of of standardizing the authZ model right now. I think = there are more worms in that can than we want to deal with right now. =


<snip>
--_000_CFF0AA7A1ABA91chrisphillipscanarieca_-- From nobody Mon Jul 21 06:04:23 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9F61B27C0 for ; Mon, 21 Jul 2014 06:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XJgwBa6Njru for ; Mon, 21 Jul 2014 06:04:16 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAED41B2BE0 for ; Mon, 21 Jul 2014 06:04:12 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB390.namprd04.prod.outlook.com (10.141.60.147) with Microsoft SMTP Server (TLS) id 15.0.990.7; Mon, 21 Jul 2014 13:04:11 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.122]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.122]) with mapi id 15.00.0990.007; Mon, 21 Jul 2014 13:04:11 +0000 From: Kelly Grizzle To: Chris Phillips , "scim@ietf.org WG" Thread-Topic: [scim] Comments so sections 1 through 3.3 Thread-Index: AQHPn42FUyoMTdZmXkS/lketPGZbfZuk86QAgALLzACAAJXgAIABmdeQ Date: Mon, 21 Jul 2014 13:04:11 +0000 Message-ID: References: <3ADF1D27-C771-4645-814E-324D51353674@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 03965BB8007AC203965D05 x-originating-ip: [70.114.158.171] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0279B3DD0D x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(377454003)(189002)(76576001)(101416001)(16236675004)(20776003)(21056001)(83072002)(107046002)(54356999)(19625215002)(87936001)(66066001)(50986999)(107886001)(106356001)(46102001)(79102001)(93886003)(76482001)(19300405004)(33646002)(74316001)(83322001)(86362001)(99396002)(77096002)(85306003)(16601075003)(31966008)(19609705001)(64706001)(19617315012)(85852003)(15975445006)(99286002)(95666004)(81542001)(4396001)(106116001)(19580405001)(2656002)(80022001)(76176999)(105586002)(92566001)(81342001)(74502001)(74662001)(19580395003)(77982001)(15202345003)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB390; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_df210e968d0d487a913697199f19a77bBN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/a9YY9IAJxHBtBkWJRBrIexu4uS4 Subject: Re: [scim] Comments so sections 1 through 3.3 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 13:04:20 -0000 --_000_df210e968d0d487a913697199f19a77bBN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 for not standardizing authz now. From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Chris Phillips Sent: Saturday, July 19, 2014 8:25 PM To: scim@ietf.org WG Subject: Re: [scim] Comments so sections 1 through 3.3 +1 to Ian's comments on the AuthZ challenges and not modifying the current = SCIM model right now. Chris. From: Ian Glazer > Date: Saturday, 19 July, 2014 2:28 PM To: Phil Hunt > Cc: "scim@ietf.org WG" > Subject: Re: [scim] Comments so sections 1 through 3.3 2. - The section is titled "Authentication and Authorization" but authoriza= tion isn't directly addressed. The sentence "Appropriate security considera= tions of the selected authentication and authorization schemes SHOULD be ta= ken" isn't actionable - it is a motherhood and apple pie statement. Do we w= ant to specifically mention scopes as an authorization mechanism? Do we jus= t want to cut "Authorization" from the section header? I have already attempted to create a better way of describing this: Because SCIM uses HTTP protocol, it does not define a scheme for authentication and authorization. It depends on standard HTTP authentication schemes. It is RECOMMENDED that clients be implemented in such a way that new authentication schemes can be deployed. Implementers SHOULD support existing authentication/ authorization schemes. In particular, OAuth2 [RFC6750] is RECOMMENDED. Appropriate security considerations of the selected authentication and authorization schemes SHOULD be taken. Because this protocol uses HTTP response status codes as the primary means of reporting the result of a request, servers are advised to respond to unauthorized or unauthenticated requests using the 401 response code in accordance with Section 3.1 of [RFC7235]. All examples show an OAuth2 bearer token [RFC6750] (thought it is not required) ; e.g., GET /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1 Host: example.com Authorization: Bearer h480djs93hd8 The context of the request (i.e. the user for whom data is being requested) MUST be inferred by service providers. That said, do we want to get into a standardized authorization model? Mayb= e this is something as a future draft specification. Particularly if we wan= t to talk about a future SCIM Directory specification. Not a huge fan of of standardizing the authZ model right now. I think there= are more worms in that can than we want to deal with right now. --_000_df210e968d0d487a913697199f19a77bBN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1 for not standardiz= ing authz now.

 <= /p>

From: scim [ma= ilto:scim-bounces@ietf.org] On Behalf Of Chris Phillips
Sent: Saturday, July 19, 2014 8:25 PM
To: scim@ietf.org WG
Subject: Re: [scim] Comments so sections 1 through 3.3

 

+1 to Ian's comments on= the AuthZ challenges and not modifying the current SCIM model right now.

 

Chris.

 

From: Ian Glazer <iglazer@salesforce.com>
Date: Saturday, 19 July, 2014 2:28 PM
To: Phil Hunt <phil.hunt@= oracle.com>
Cc: "scim@ietf.org WG"= ; <scim@ietf.org>
Subject: Re: [scim] Comments so sections 1 through 3.3

 

 

<snip>

2. - The section is titled = "Authentication and Authorization" but authorization isn't direct= ly addressed. The sentence "Appropriate security considerations of the selected authentication and authorization schemes SHOULD be taken"= ; isn't actionable - it is a motherhood and apple pie statement. Do we want= to specifically mention scopes as an authorization mechanism? Do we just w= ant to cut "Authorization" from the section header?

 

I have already attempted to= create a better way of describing this:

   Because SCIM uses HTTP protocol, it does not define=
 a scheme for
   authentication and authorizat=
ion.  It depends on standard HTTP
   authentication schemes. =
 It is RECOMMENDED that clients be
   implemented in such a way tha=
t new authentication schemes can be
   deployed.  Implementers =
SHOULD support existing authentication/
   authorization schemes.  =
In particular, OAuth2 [RFC6750] is
   RECOMMENDED.  Appropriat=
e security considerations of the selected
   authentication and authorizat=
ion schemes SHOULD be taken.  Because
   this protocol uses HTTP respo=
nse status codes as the primary means of
   reporting the result of a req=
uest, servers are advised to respond to
   unauthorized or unauthenticat=
ed requests using the 401 response code
   in accordance with Section 3.=
1 of [RFC7235].
 
   All examples show an OAuth2 b=
earer token [RFC6750] (thought it is not
   required) ; e.g.,<=
/span>
 
   GET /Users/2819c223-7f76-453a=
-919d-413861904646 HTTP/1.1
   Host: example.com
   Authorization: Bearer h480djs=
93hd8
 
   The context of the request (i=
.e. the user for whom data is being
   requested) MUST be inferred b=
y service providers.

That said, do we want to ge= t into a standardized authorization model?  Maybe this is something as= a future draft specification. Particularly if we want to talk about a future SCIM Directory specification.

 

Not a huge fan of of standa= rdizing the authZ model right now. I think there are more worms in that can= than we want to deal with right now. 

 

 

<snip>

--_000_df210e968d0d487a913697199f19a77bBN1PR04MB392namprd04pro_-- From nobody Mon Jul 21 07:35:32 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D646C1A001E for ; Mon, 21 Jul 2014 07:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lj9ssrAFrsFT for ; Mon, 21 Jul 2014 07:35:24 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 297B01A000D for ; Mon, 21 Jul 2014 07:35:24 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6LEZMeL019011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 21 Jul 2014 14:35:23 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6LEZLfH017705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 21 Jul 2014 14:35:22 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6LEZLan017688 for ; Mon, 21 Jul 2014 14:35:21 GMT Received: from dhcp-912f.meeting.ietf.org (/31.133.145.47) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 21 Jul 2014 07:35:21 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_87DE619B-E852-491A-B615-BDB4169EB1B4" Message-Id: <36A7B56D-EBF4-4208-AA3A-2DA7D118F8C2@oracle.com> Date: Mon, 21 Jul 2014 08:46:20 -0400 To: SCIM WG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/upwqAOastOaKWU0evTFqDCMMNnM Subject: [scim] Bulk request has a non-deterministic condition X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:35:30 -0000 --Apple-Mail=_87DE619B-E852-491A-B615-BDB4169EB1B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The following paragraph in Bulk was brought to my attention as = problematic: There can be more then one operation per resource in each bulk job. The Service client MUST take notice of the unordered structure of JSON and the service provider can process operations in any order. For example, if the Service client sends two PUT operations in one request, the outcome is non-deterministic. =46rom our perspective this makes Bulk un-implementable, since other = paragraphs seem to depend on serial processing (eg bulkId). Anybody have = any background for this? It seems to come from SCIM 1. If we were to proceed with bulk, I would recommend striking this = paragraph. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_87DE619B-E852-491A-B615-BDB4169EB1B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The = following paragraph in Bulk was brought to my attention as = problematic:
   =
There can be more then one operation per resource in each bulk job.
   The Service client MUST take notice of the unordered structure of
   JSON and the service provider can process operations in any order.
   For example, if the Service client sends two PUT operations in one
   request, the outcome is non-deterministic.

=46rom our perspective this = makes Bulk un-implementable, since other paragraphs seem to depend on = serial processing (eg bulkId). Anybody have any background for this? It = seems to come from SCIM 1.

If we were to = proceed with bulk, I would recommend striking this = paragraph.

Phil

@indepen= dentid
phil.hunt@oracle.com



= --Apple-Mail=_87DE619B-E852-491A-B615-BDB4169EB1B4-- From nobody Mon Jul 21 07:42:07 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857521A00C3 for ; Mon, 21 Jul 2014 07:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.227 X-Spam-Level: X-Spam-Status: No, score=0.227 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qR7NKMagfJhj for ; Mon, 21 Jul 2014 07:42:00 -0700 (PDT) Received: from atl4mhob19.myregisteredsite.com (atl4mhob19.myregisteredsite.com [209.17.115.112]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC1D1A002A for ; Mon, 21 Jul 2014 07:42:00 -0700 (PDT) Received: from mailpod1.hostingplatform.com ([10.30.71.114]) by atl4mhob19.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s6LEftcI001919 for ; Mon, 21 Jul 2014 10:41:55 -0400 Received: (qmail 23594 invoked by uid 0); 21 Jul 2014 14:41:55 -0000 X-TCPREMOTEIP: 71.162.105.193 X-Authenticated-UID: sal@idmachines.com Received: from unknown (HELO salPC) (sal@idmachines.com@71.162.105.193) by 0 with ESMTPA; 21 Jul 2014 14:41:55 -0000 From: "Salvatore D'Agostino" To: "'Kelly Grizzle'" , "'Chris Phillips'" , References: <3ADF1D27-C771-4645-814E-324D51353674@oracle.com> In-Reply-To: Date: Mon, 21 Jul 2014 10:41:54 -0400 Message-ID: <00a001cfa4f1$ead05870$c0710950$@com> X-Mailer: Microsoft Office Outlook 12.0 MIME-Version: 1.0 Thread-Index: AQHPn42FUyoMTdZmXkS/lketPGZbfZuk86QAgALLzACAAJXgAIABmdeQgAC1CpA= Content-Language: en-us Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0098_01CFA4D0.634087C0" Archived-At: http://mailarchive.ietf.org/arch/msg/scim/qa1EOJtKouE7xmnyacX9ig0yNs4 Subject: Re: [scim] Comments so sections 1 through 3.3 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:42:03 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0098_01CFA4D0.634087C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0099_01CFA4D0.634087C0" ------=_NextPart_001_0099_01CFA4D0.634087C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit yes, +1 leave AuthZ "open" From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Kelly Grizzle Sent: Monday, July 21, 2014 9:04 AM To: Chris Phillips; scim@ietf.org WG Subject: Re: [scim] Comments so sections 1 through 3.3 +1 for not standardizing authz now. From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Chris Phillips Sent: Saturday, July 19, 2014 8:25 PM To: scim@ietf.org WG Subject: Re: [scim] Comments so sections 1 through 3.3 +1 to Ian's comments on the AuthZ challenges and not modifying the current SCIM model right now. Chris. From: Ian Glazer Date: Saturday, 19 July, 2014 2:28 PM To: Phil Hunt Cc: "scim@ietf.org WG" Subject: Re: [scim] Comments so sections 1 through 3.3 2. - The section is titled "Authentication and Authorization" but authorization isn't directly addressed. The sentence "Appropriate security considerations of the selected authentication and authorization schemes SHOULD be taken" isn't actionable - it is a motherhood and apple pie statement. Do we want to specifically mention scopes as an authorization mechanism? Do we just want to cut "Authorization" from the section header? I have already attempted to create a better way of describing this: Because SCIM uses HTTP protocol, it does not define a scheme for authentication and authorization. It depends on standard HTTP authentication schemes. It is RECOMMENDED that clients be implemented in such a way that new authentication schemes can be deployed. Implementers SHOULD support existing authentication/ authorization schemes. In particular, OAuth2 [RFC6750] is RECOMMENDED. Appropriate security considerations of the selected authentication and authorization schemes SHOULD be taken. Because this protocol uses HTTP response status codes as the primary means of reporting the result of a request, servers are advised to respond to unauthorized or unauthenticated requests using the 401 response code in accordance with Section 3.1 of [RFC7235]. All examples show an OAuth2 bearer token [RFC6750] (thought it is not required) ; e.g., GET /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1 Host: example.com Authorization: Bearer h480djs93hd8 The context of the request (i.e. the user for whom data is being requested) MUST be inferred by service providers. That said, do we want to get into a standardized authorization model? Maybe this is something as a future draft specification. Particularly if we want to talk about a future SCIM Directory specification. Not a huge fan of of standardizing the authZ model right now. I think there are more worms in that can than we want to deal with right now. ------=_NextPart_001_0099_01CFA4D0.634087C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

yes, +1 leave AuthZ “open”

 

From:= = scim [mailto:scim-bounces@ietf.org] On Behalf Of Kelly = Grizzle
Sent: Monday, July 21, 2014 9:04 AM
To: = Chris Phillips; scim@ietf.org WG
Subject: Re: [scim] Comments = so sections 1 through 3.3

 

+1 for not standardizing authz now.

 

From:= = scim [mailto:scim-bounces@ietf.org] = On Behalf Of Chris Phillips
Sent: Saturday, July 19, = 2014 8:25 PM
To: scim@ietf.org WG
Subject: = Re: [scim] Comments so sections 1 through = 3.3

 

+1 to Ian's comments on the AuthZ challenges and not modifying the = current SCIM model right now.

 

Chris.

 

From: Ian Glazer <iglazer@salesforce.com>
= Date: Saturday, 19 July, 2014 2:28 PM
To: Phil Hunt = <phil.hunt@oracle.com>
C= c: "scim@ietf.org WG" = <scim@ietf.org>
Subject: = Re: [scim] Comments so sections 1 through = 3.3

 

 

<snip>

2. - The section is titled "Authentication and Authorization" = but authorization isn't directly addressed. The sentence = "Appropriate security considerations of the selected authentication = and authorization schemes SHOULD be taken" isn't actionable - it is = a motherhood and apple pie statement. Do we want to specifically mention = scopes as an authorization mechanism? Do we just want to cut = "Authorization" from the section = header?

 

I have already attempted to create a better way of describing = this:

   Because SCIM uses HTTP protocol, it =
does not define a scheme for
   authentication and =
authorization.  It depends on standard =
HTTP
   authentication schemes.  It is =
RECOMMENDED that clients be
   implemented in such a way that new =
authentication schemes can be
   deployed.  Implementers SHOULD =
support existing authentication/
   authorization schemes.  In =
particular, OAuth2 [RFC6750] is
   RECOMMENDED.  Appropriate =
security considerations of the =
selected
   authentication and authorization =
schemes SHOULD be taken.  Because
   this protocol uses HTTP response =
status codes as the primary means of
   reporting the result of a request, =
servers are advised to respond to
   unauthorized or unauthenticated =
requests using the 401 response code
   in accordance with Section 3.1 of =
[RFC7235].
 
   All examples show an OAuth2 bearer =
token [RFC6750] (thought it is not
   required) ; =
e.g.,
 
   GET =
/Users/2819c223-7f76-453a-919d-413861904646 =
HTTP/1.1
   Host: example.com
   Authorization: Bearer =
h480djs93hd8
 
   The context of the request (i.e. the =
user for whom data is being
   requested) MUST be inferred by =
service providers.

That said, do we want to get into a standardized authorization model? =  Maybe this is something as a future draft specification. = Particularly if we want to talk about a future SCIM Directory = specification.

 

<= div>

Not a huge fan of of standardizing the authZ model right now. I think = there are more worms in that can than we want to deal with right = now. 

=

 

 

<snip>

------=_NextPart_001_0099_01CFA4D0.634087C0-- ------=_NextPart_000_0098_01CFA4D0.634087C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITIjCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIEnTCC A4WgAwIBAgIQND3pK6wnNP+PyzSU+8xwVDANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoX DTIwMDUzMDEwNDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2Fs dCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk 8n2rQTtiRjeuzcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTE hb2FUTV5pE5okHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov 66yhs2qqty5nNYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8 goqOpA6l14lD/BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6h hX71R2XL+E1XKHTSNP8wtu72YjAUjCzrAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6 xCZU7wO94CTLVBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNo dHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYB BQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQABvJzjYyiw8zEBwt973WKgAZ0jMQ+cknNTUeofTPrWn8TKL2d+eDMPdBa5kYeR 9Yom+mRwANge+QsEYlCHk4HU2vUj2zS7hVa0cDRueIM3HoUcxREVkl+HF72sav3xwtHMiV+xfPA+ UfI183zsYJhrOivg79+zfYbrtRv1W+yifJgT1wBQudEtc94DeHThBYUxXsuauZ2UxrmUN3Vy3ET7 Z+jw+iUeUqfaJelH4KDHPKBOsQo2+3dIn++Xivu0/uOUFKiDvFwtP9JgcWDuwnGCDOmINuPaILSj oGyqlku4gI51ykkH9jsUut/cBdmf2+Cy5k2geCbn5y1uf1/GHogVMIIFGjCCBAKgAwIBAgIQbRnq pxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVU MRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmly c3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1 MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09N T0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU 4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHff sReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kAB W0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJk JpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IB SzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4 Y2QnwS/ioFu8ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQK MAgwBgYEVR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVRO LVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVu dF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcN AQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjB MCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8 H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5 OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggUlMIIEDaADAgECAhAw2ACH 8WF9ex+PZrGbouVEMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGlt aXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTEzMTAyMzAwMDAwMFoXDTE0MTAyMzIzNTk1OVowIzEhMB8GCSqGSIb3DQEJARYS c2FsQGlkbWFjaGluZXMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsuTZeTEH CNgvmi6wljJrkNJjs5Pz7V+XNThwN9N6MN4sYkjyfAOHLHSPKRHDGkOozLN5IyjGsSGRfDBP8N7x 0tWTujRlNCb5WSTPmiz+7YxjUaDQLPp6NC4k60p0l3uBTEblNLQ7jljkP54yzFDhKUBr4V34oGQr t8CYM/n4b1/H1NBThYMYwxY+fcgZeZLEXUCpCBxd+vZ40422Yp6fCVBNAn3g/6Ui7iOBnksNdqVd A7niqyfA3V95FBg8KdBn4hX0gFgGtf5rN3QKm62Vz18HOOwjAZKWkxKaxxNAu4TGOewDqV6a1pQD k0KQaul8ps6R8j4UXhEdNHojiSAhKwIDAQABo4IB4jCCAd4wHwYDVR0jBBgwFoAUehNOAHRbxnhj ZCfBL+KgW7x5xXswHQYDVR0OBBYEFCl0wCQjyTSoet4B/SWTNiEvviXrMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0cDovL2NybC5j b21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy bDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9D T01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHQYDVR0RBBYwFIESc2FsQGlkbWFjaGluZXMuY29t MA0GCSqGSIb3DQEBBQUAA4IBAQBTS8NQyx8WR+ty/qItwB45qj6/wDKwFJkoZPNhYjjM4XQC3UQd XhDnUeQGjxs6fy4sBt2vM7pKIfy6LBi4jkDgF6GOEs0w+3idXlZ3dfbcFmMoYjPUMGAYw9Xe3vNK 9IIVGmrO4lYexmo6AqITaESXwQqpjFn2+x7GlpaAkw6UpfSaiadDIwo9qH7OPZRAD3AUYlKj4yRq xfXUl6KuBBiqM0UpdmItFCec4oPVpcY42u+v00P5rxeaT5nOHBWGIsCNcHSkL1sZARkBtQGdLedR QB2BsmUaNT8ObqK1K1c4wNZts5uqomHFPWgReqe9dEQtlI2Ajtlp/KAdOqHwzxe5MYIEZTCCBGEC AQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8g Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDDYAIfxYX17H49msZui 5UQwCQYFKw4DAhoFAKCCApEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTQwNzIxMTQ0MTU0WjAjBgkqhkiG9w0BCQQxFgQU+I7bTqzQiw5Sfe+fzLgG3IevFC0wgbcG CSqGSIb3DQEJDzGBqTCBpjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsG CWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZI hvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEw CgYIKoZIhvcNAgUwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQMNgAh/FhfXsfj2axm6LlRDCBuwYLKoZIhvcNAQkQAgsxgauggagwgZMxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDDYAIfxYX17H49msZui5UQwDQYJKoZIhvcN AQEBBQAEggEAjpsbM58WCkZs/qrZxP5MjOrJY76d9qqiBJigTL3I8A2KyouEYpieMNnbSc2vaVp2 TuQFa0CAbF2YRKpqHSqY/gh100KCr9zn04kYV2ei9O5bnQa91wedcDXGZ30A5TVhZ3sQtkNycyCA /QaYJdJJU6QDfUoMjddgNVkuyFsw1Jq7ZMuOX6HvGOwCByXNhB78f/qd92EET07riKz5JlOlNeua Hym/cV8ONBtrKqnt/bzyPZq3O6loC7JvbGhFfOty3J16NWkrxC168hZUafmHEqd2iW4Snzp2vM2v pM2VOhzNoIZCaIwUYF2ia/o3RwuUYHnR+PsHwII9+bSEMr/hcgAAAAAAAA== ------=_NextPart_000_0098_01CFA4D0.634087C0-- From nobody Mon Jul 21 07:56:54 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDDB1A016B for ; Mon, 21 Jul 2014 07:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdOxYgN7xWfi for ; Mon, 21 Jul 2014 07:56:47 -0700 (PDT) Received: from nm48-vm5.bullet.mail.bf1.yahoo.com (nm48-vm5.bullet.mail.bf1.yahoo.com [216.109.115.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06DCC1A0103 for ; Mon, 21 Jul 2014 07:56:46 -0700 (PDT) Received: from [66.196.81.173] by nm48.bullet.mail.bf1.yahoo.com with NNFMP; 21 Jul 2014 14:56:46 -0000 Received: from [98.139.212.246] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 21 Jul 2014 14:56:46 -0000 Received: from [127.0.0.1] by omp1055.mail.bf1.yahoo.com with NNFMP; 21 Jul 2014 14:56:46 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 242203.98038.bm@omp1055.mail.bf1.yahoo.com Received: (qmail 66676 invoked by uid 60001); 21 Jul 2014 14:56:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1405954606; bh=umVuEQToEIS0s50BVjG8ibfjrrjPvHcB1GLwcSpcoPo=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=aZvdl1o4TjNqfO0EeZb67jBtX+mH4Vrz9Tq93tul5eUdvu/bPPm0IF8PylFdjRw/GIf8GRLXwZYFL85GpjL8W/eeOdCz/AVmZUJ+N1blbgQAP4rBr+9aKbrTaWKbO1hYvjVFNwRe/cWQE0kWF9FUABxpYjFWYG8swr7T9VcnAqM= X-YMail-OSG: Qnqov.YVM1l0huwDmQNOdWCohV2Setq9tpodM5ArO0kdMAp io2A5u_moeB2rdGvNA1qwkwEOIldjdayg.HVkMGdG7xmn1VNoXEb8OqF64Pm TqovbfU2KKGNsJvH3qKZEGfFfbG2Bfj7n7pDA4ZMrWjc50RKYJrQIv5N5NOA RsAMn4og8iZPrjqyHSxVPzHINwrs1Dd4lAZZJyaz1HJlslw3FDzArsOhkg_k 6wr0iXd_YlzyEA55.3BvZoGF7Ta2YTspFF4A8SeZiGMUyrxczBSXJ2j92V7O fUWTpnUX8LCx_jiSWzvANzXAe1qK3S9s4ENw3JdJ2P1usYX148KPF_IWCYzF YmCZyQjynowmxa1jWWnDwk4NfmrP3.aN8ZBKoQS4tRZuAZrNyFVsYZHYDUrX 1nW3Z3HXyOuV1oCsUFpd23LKm6jTNGakvQwZRpSeYf7imlIjTRuieKQ3Bmr2 LQs5QP2Livwha7yVCtoD3_NC6wvdQpzR2mp3GuQPOSCGnJhIVKBNONY9MF7s _D3hUMZgnaBuf.lsbCYfh_yx8AohCej4gbFysGDBr8SSCMGonUwew1TcMXKe TgZKYamZ0YJtlYGkmCjCdZyRtJTyiRe6AWM.moBRMttnojEQbQZvjLJzl5ov 5tn00m4O8aLn3sjYAMqoe3mIBXQeLJ8wkNDrVzfogiJ6P.T80.Q-- Received: from [99.31.212.42] by web142804.mail.bf1.yahoo.com via HTTP; Mon, 21 Jul 2014 07:56:45 PDT X-Rocket-MIMEInfo: 002.001, SSB0aGluayBCdWxrIHNob3VsZCBiZSBkcm9wcGVkIGluIGZhdm9yIG9mIHNvbWV0aGluZyBsaWtlIHN1cHBvcnRpbmcgU1BEWSBmb3IgaGlnaCB2b2x1bWUuCgoKT24gTW9uZGF5LCBKdWx5IDIxLCAyMDE0IDc6NDEgQU0sIFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb20.IHdyb3RlOgogCgoKVGhlIGZvbGxvd2luZyBwYXJhZ3JhcGggaW4gQnVsayB3YXMgYnJvdWdodCB0byBteSBhdHRlbnRpb24gYXMgcHJvYmxlbWF0aWM6ClRoZXJlIGNhbiBiZSBtb3JlIHRoZW4gb25lIG9wZXJhdGlvbiBwZXIgcmUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.195.683 References: <36A7B56D-EBF4-4208-AA3A-2DA7D118F8C2@oracle.com> Message-ID: <1405954605.9443.YahooMailNeo@web142804.mail.bf1.yahoo.com> Date: Mon, 21 Jul 2014 07:56:45 -0700 From: Bill Mills To: Phil Hunt , SCIM WG In-Reply-To: <36A7B56D-EBF4-4208-AA3A-2DA7D118F8C2@oracle.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-2129327256-2095346290-1405954605=:9443" Archived-At: http://mailarchive.ietf.org/arch/msg/scim/7-q1BKcX2Yj3AzZmkmEreLYysQY Subject: Re: [scim] Bulk request has a non-deterministic condition X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:56:49 -0000 ---2129327256-2095346290-1405954605=:9443 Content-Type: text/plain; charset=us-ascii I think Bulk should be dropped in favor of something like supporting SPDY for high volume. On Monday, July 21, 2014 7:41 AM, Phil Hunt wrote: The following paragraph in Bulk was brought to my attention as problematic: There can be more then one operation per resource in each bulk job. The Service client MUST take notice of the unordered structure of JSON and the service provider can process operations in any order. For example, if the Service client sends two PUT operations in one request, the outcome is non-deterministic. >From our perspective this makes Bulk un-implementable, since other paragraphs seem to depend on serial processing (eg bulkId). Anybody have any background for this? It seems to come from SCIM 1. If we were to proceed with bulk, I would recommend striking this paragraph. Phil @independentid www.independentid.comphil.hunt@oracle.com _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim ---2129327256-2095346290-1405954605=:9443 Content-Type: text/html; charset=us-ascii
I think Bulk should be dropped in favor of something like supporting SPDY for high volume.


On Monday, July 21, 2014 7:41 AM, Phil Hunt <phil.hunt@oracle.com> wrote:


The following paragraph in Bulk was brought to my attention as problematic:
   There can be more then one operation per resource in each bulk job.
   The Service client MUST take notice of the unordered structure of
   JSON and the service provider can process operations in any order.
   For example, if the Service client sends two PUT operations in one
   request, the outcome is non-deterministic.

From our perspective this makes Bulk un-implementable, since other paragraphs seem to depend on serial processing (eg bulkId). Anybody have any background for this? It seems to come from SCIM 1.

If we were to proceed with bulk, I would recommend striking this paragraph.

Phil

@independentid
phil.hunt@oracle.com




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


---2129327256-2095346290-1405954605=:9443-- From nobody Mon Jul 21 08:23:49 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF981A02E6 for ; Mon, 21 Jul 2014 08:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0hG6JugJqPV for ; Mon, 21 Jul 2014 08:23:44 -0700 (PDT) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A87A1A02E4 for ; Mon, 21 Jul 2014 08:23:41 -0700 (PDT) Received: from NG-EX04.ad.nexusgroup.com (10.75.28.9) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 21 Jul 2014 17:23:27 +0200 Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX04.ad.nexusgroup.com (10.75.28.9) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 21 Jul 2014 17:23:26 +0200 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0847.030; Mon, 21 Jul 2014 17:23:26 +0200 From: =?Windows-1252?Q?Erik_Wahlstr=F6m?= To: Bill Mills Thread-Topic: [scim] Bulk request has a non-deterministic condition Thread-Index: AQHPpPEMFVmfcj1VekWZuyk4Z9ltJZuqfJGAgAAHdAA= Date: Mon, 21 Jul 2014 15:23:26 +0000 Message-ID: <6B1E5F3B-89FC-4EF9-915E-646379A75EB9@nexusgroup.com> References: <36A7B56D-EBF4-4208-AA3A-2DA7D118F8C2@oracle.com> <1405954605.9443.YahooMailNeo@web142804.mail.bf1.yahoo.com> In-Reply-To: <1405954605.9443.YahooMailNeo@web142804.mail.bf1.yahoo.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [94.234.170.18] Content-Type: multipart/alternative; boundary="_000_6B1E5F3B89FC4EF9915E646379A75EB9nexusgroupcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/z6uaq4bKKKCS0yeU4qkdmpnQ4Bc Cc: SCIM WG , Phil Hunt Subject: Re: [scim] Bulk request has a non-deterministic condition X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 15:23:46 -0000 --_000_6B1E5F3B89FC4EF9915E646379A75EB9nexusgroupcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I would like to keep bulk in the core spec. It=92s been implemented by some= vendors and it does the job. It=92s also an important part of a provisioni= ng protocol that does a huge on boarding or migration between different sys= tems. SPDY is not standardised and adopted everywhere yet and non of the existing= provisioning (standard and non standard) implementations that I know of us= es it. Lets stick with what we know works. A agree of removing the paragraph. I think it=92s based on a misunderstandi= ng from when writing it. It=92s JSON objects that=92s unordered, JSON array= s is ordered, so it will not be an issue. / Erik On 21 Jul 2014, at 16:56, Bill Mills > wrote: I think Bulk should be dropped in favor of something like supporting SPDY f= or high volume. On Monday, July 21, 2014 7:41 AM, Phil Hunt > wrote: The following paragraph in Bulk was brought to my attention as problematic: There can be more then one operation per resource in each bulk job. The Service client MUST take notice of the unordered structure of JSON and the service provider can process operations in any order. For example, if the Service client sends two PUT operations in one request, the outcome is non-deterministic. >From our perspective this makes Bulk un-implementable, since other paragrap= hs seem to depend on serial processing (eg bulkId). Anybody have any backgr= ound for this? It seems to come from SCIM 1. If we were to proceed with bulk, I would recommend striking this paragraph. 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 --_000_6B1E5F3B89FC4EF9915E646379A75EB9nexusgroupcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <71449E5AFE92B243A1E810D05ADAFB9A@nexusgroup.com> Content-Transfer-Encoding: quoted-printable I would like to keep bulk in the core spec. It=92s been implemented by some= vendors and it does the job. It=92s also an important part of a provisioni= ng protocol that does a huge on boarding or migration between different sys= tems. 

SPDY is not standardised and adopted everywhere yet and non of the exi= sting provisioning (standard and non standard) implementations that I know = of uses it. Lets stick with what we know works.

A agree of removing the paragraph. I think it=92s based on a misunders= tanding from when writing it. It=92s JSON objects that=92s unordered, JSON = arrays is ordered, so it will not be an issue.

/ Erik


On 21 Jul 2014, at 16:56, Bill Mills <wmills_92105@yahoo.com> wrote:

I think Bulk should be dropped in favor of something like suppor= ting SPDY for high volume.


On Monday, July 21, 2014 7= :41 AM, Phil Hunt <phil.hunt@ora= cle.com> wrote:


The following paragraph in Bulk was brought to my= attention as problematic: 
   There can be more then one operation per resource in =
each bulk job.
   The Service client MUST take notice of the unordered structure of
   JSON and the service provider can process operations in any order.
   For example, if the Service client sends two PUT operations in one
   request, the outcome is non-deterministic.

From our perspective this makes Bulk un-implementable, since other par= agraphs seem to depend on serial processing (eg bulkId). Anybody have any b= ackground for this? It seems to come from SCIM 1.

If we were to proceed with bulk, I would recommend striking this parag= raph.

Phil

@independentid
phil.hunt@oracle.com




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


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

--_000_6B1E5F3B89FC4EF9915E646379A75EB9nexusgroupcom_-- From nobody Mon Jul 21 08:33:04 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A46F1A01D9 for ; Mon, 21 Jul 2014 08:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXrBRaS0-lph for ; Mon, 21 Jul 2014 08:32:51 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6B241A0166 for ; Mon, 21 Jul 2014 08:32:40 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6LFWdqm012305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Jul 2014 15:32:40 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6LFWcqZ005687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jul 2014 15:32:39 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6LFWcQf006075; Mon, 21 Jul 2014 15:32:38 GMT Received: from [172.16.62.225] (/206.47.221.210) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 21 Jul 2014 08:32:38 -0700 References: <36A7B56D-EBF4-4208-AA3A-2DA7D118F8C2@oracle.com> <1405954605.9443.YahooMailNeo@web142804.mail.bf1.yahoo.com> Mime-Version: 1.0 (1.0) In-Reply-To: <1405954605.9443.YahooMailNeo@web142804.mail.bf1.yahoo.com> Content-Type: multipart/alternative; boundary=Apple-Mail-98A4FF29-FD8E-4E89-8E3B-033FFF95E4F1 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D257) From: Phil Hunt Date: Mon, 21 Jul 2014 11:32:30 -0400 To: Bill Mills X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Nql9XFWY-tHYKpezSKF45v4MSn8 Cc: SCIM WG Subject: Re: [scim] Bulk request has a non-deterministic condition X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 15:32:59 -0000 --Apple-Mail-98A4FF29-FD8E-4E89-8E3B-033FFF95E4F1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Not sure I understand the use of spdy.=20 Seems useful if you want to maintain a high rate update stream. But in this= case Bulk would simply be passing 1000s of changes at once which may be bet= ter than 1000s of separate req/responses which may get out of sequence if yo= u aren't careful to account for connection pooling.=20 Phil > On Jul 21, 2014, at 10:56, Bill Mills wrote: >=20 > I think Bulk should be dropped in favor of something like supporting SPDY f= or high volume. >=20 >=20 > On Monday, July 21, 2014 7:41 AM, Phil Hunt wrote: >=20 >=20 > The following paragraph in Bulk was brought to my attention as problematic= : > There can be more then one operation per resource in each bulk job. > The Service client MUST take notice of the unordered structure of > JSON and the service provider can process operations in any order. > For example, if the Service client sends two PUT operations in one > request, the outcome is non-deterministic. >=20 > =46rom our perspective this makes Bulk un-implementable, since other parag= raphs seem to depend on serial processing (eg bulkId). Anybody have any back= ground for this? It seems to come from SCIM 1. >=20 > If we were to proceed with bulk, I would recommend striking this paragraph= . >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 --Apple-Mail-98A4FF29-FD8E-4E89-8E3B-033FFF95E4F1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Not sure I understand the use of spdy.=  

Seems useful if you want to maintain a high r= ate update stream.  But in this case Bulk would simply be passing 1000s= of changes at once which may be better than 1000s of separate req/responses= which may get out of sequence if you aren't careful to account for connecti= on pooling. 

Phil

On Jul 21, 2014, at 10:56, Bill M= ills <wmills_92105@yahoo.com> wrote:





The following paragraph in Bulk was brought to my= attention as problematic:
   There can be more then o=
ne operation per resource in each bulk job.
   The Service client MUST take notice of the unordered structure of
   JSON and the service provider can process operations in any order.
   For example, if the Service client sends two PUT operations in one
   request, the outcome is non-deterministic.

=46rom our perspective this make= s Bulk un-implementable, since other paragraphs seem to depend on serial pro= cessing (eg bulkId). Anybody have any background for this? It seems to come f= rom SCIM 1.

If we were to proceed with bulk, I woul= d recommend striking this paragraph.

Phil

@independentid
phil.hunt@oracle.com

=



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


= --Apple-Mail-98A4FF29-FD8E-4E89-8E3B-033FFF95E4F1-- From nobody Mon Jul 21 10:00:26 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910BC1A002D for ; Mon, 21 Jul 2014 10:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJ1UwEKan0Fo for ; Mon, 21 Jul 2014 10:00:24 -0700 (PDT) Received: from nm49-vm6.bullet.mail.bf1.yahoo.com (nm49-vm6.bullet.mail.bf1.yahoo.com [216.109.115.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57BE71A0008 for ; Mon, 21 Jul 2014 10:00:24 -0700 (PDT) Received: from [66.196.81.172] by nm49.bullet.mail.bf1.yahoo.com with NNFMP; 21 Jul 2014 17:00:23 -0000 Received: from [98.139.212.196] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 21 Jul 2014 17:00:23 -0000 Received: from [127.0.0.1] by omp1005.mail.bf1.yahoo.com with NNFMP; 21 Jul 2014 17:00:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 373945.55573.bm@omp1005.mail.bf1.yahoo.com Received: (qmail 78544 invoked by uid 60001); 21 Jul 2014 17:00:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1405962023; bh=52LShr7bwFtFglwuXB/wkb/UGMEebAhso4+wzMxUd0U=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=eCDa+o8UzPxpYVuSflYN92DAEuJ6kIs31A3CZlOwXLp5nnZ33cbP7lSExPalM8aA/qyRzfqQvTK8/mZIQbKB5TuEJcjiJJ0XTsxxrsJMQr3azuHH0eJohov0zOZy9mu3bgQ+0XuF3F5w4LQ0wotS8AgZYgvr14FjjIaWcKFOhmo= X-YMail-OSG: YP1exEoVM1kPA3TDgGZvRK6xY28YTbqBoziQzAfU6hqD2yX 31TvQH_VD_eExhKiYRc8_uBMeyfzFOl2j0TkNJ7sww2MOh_eUDpHVinGi1GH LHe0QVxY6yJel2fHTAjUCIP2odl8Rs.mklbbye0p1P8qxyeIEI24aUPpO9es DtP5cvLvfl2FhPr_l9UuVnhn.wQDrIjSpHrX7.GdaOu1XqxM2tX1kxsCrsJP 9GOdNWn6tlGpmTctaPjKl_2ZDRE.2bJAJ41DyVoHgsqsuJmcdhGypqT6yIlL vxqndMOr7t6ZXKDpAHLQJTtufpvlLpHwz9Yw8WTw4d1tGZ83AMmzQMPFHGwZ pxWo2VOYf2Js15M3zb.Q82kGfi9k1HvnG5tGSGilOCMGjZQpkTVpnocTL_Oj EBud_LDw42I0ViL61jn4GMC5I7N0eCPwxzii2.6VCuJSrwLOO3OI2Y6BMJg2 FemWgrJ8eXmrjdeBbKoNO6mb4bG9.pb_cJlxZiK3U49dSB0mZTqdl3M3PKAf kDWNwjg.9WXhaOe6LsB1vhIuXtdgJIbHwLQuC_3ezm7k3N5LgTfYCKkYewAf x87SYfiGTkfE5eFINMpRQshCAEjSEsvifLOmLC6G1dPuKo5RQjSo9yxPvEKD 6q.dfmyEW0ejqpZrXrNXr.usXTRVWP0VDUKEd5ypfbCw5mGb.Cwr8 Received: from [167.220.24.190] by web142804.mail.bf1.yahoo.com via HTTP; Mon, 21 Jul 2014 10:00:23 PDT X-Rocket-MIMEInfo: 002.001, SW1wbHlpbmcgdGhhdCB0aGVyZSBpcyBhbiBvcmRlcmluZyBpbiBidWxrIHRyYW5zYWN0aW9ucyBpcyBpbnRlcmVzdGluZywgYW5kIEkgdGhpbmsgbm90IHN1cHBvcnRlZCBieSB0aGUgZHJhZnQgdGV4dC4gwqBJIGFsc28gZG91YnQgdGhlcmUgaXMgYW55IGdyZWF0IGVmZmljaWVuY3kgdG8gYmUgZ2FpbmVkIGJ5IGhhdmluZyAxayB0cmFuc2FjdGlvbnMgaW4gYSBzaW5nbGUgYnVsayBvcGVyYXRpb24gaW4gdGhlIGVuZCwgb3RoZXIgdGhhbiBhIHNpbmdsZSBhdXRobiBjaGVjayBpbnN0ZWFkIG9mIDFrLgoKU1ABMAEBAQE- X-Mailer: YahooMailWebService/0.8.195.683 References: <36A7B56D-EBF4-4208-AA3A-2DA7D118F8C2@oracle.com> <1405954605.9443.YahooMailNeo@web142804.mail.bf1.yahoo.com> Message-ID: <1405962023.65562.YahooMailNeo@web142804.mail.bf1.yahoo.com> Date: Mon, 21 Jul 2014 10:00:23 -0700 From: Bill Mills To: Phil Hunt In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-2129327256-1940524518-1405962023=:65562" Archived-At: http://mailarchive.ietf.org/arch/msg/scim/jjaVyetK_HH39qdgYNy6JROXpbk Cc: SCIM WG Subject: Re: [scim] Bulk request has a non-deterministic condition X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 17:00:25 -0000 ---2129327256-1940524518-1405962023=:65562 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Implying that there is an ordering in bulk transactions is interesting, and= I think not supported by the draft text. =A0I also doubt there is any grea= t efficiency to be gained by having 1k transactions in a single bulk operat= ion in the end, other than a single authn check instead of 1k.=0A=0ASPDY wo= uld get you equivalent throughput and you lose the complexity of the bulk e= rror message handling.=0A=0A=0AOn Monday, July 21, 2014 8:33 AM, Phil Hunt = wrote:=0A =0A=0A=0ANot sure I understand the use of = spdy.=A0=0A=0ASeems useful if you want to maintain a high rate update strea= m. =A0But in this case Bulk would simply be passing 1000s of changes at onc= e which may be better than 1000s of separate req/responses which may get ou= t of sequence if you aren't careful to account for connection pooling.=A0= =0A=0APhil=0A=0AOn Jul 21, 2014, at 10:56, Bill Mills wrote:=0A=0A=0AI think Bulk should be dropped in favor of something lik= e supporting SPDY for high volume.=0A>=0A>=0A>=0A>On Monday, July 21, 2014 = 7:41 AM, Phil Hunt wrote:=0A> =0A>=0A>=0A>The follow= ing paragraph in Bulk was brought to my attention as problematic:=0A>There = can be more then one operation per resource in each bulk job. The Service c= lient MUST take notice of the unordered structure of JSON and the service p= rovider can process operations in any order. For example, if the Service cl= ient sends two PUT operations in one request, the outcome is non-determinis= tic. =0A>=0A>=0A>From our perspective this makes Bulk un-implementable, sin= ce other paragraphs seem to depend on serial processing (eg bulkId). Anybod= y have any background for this? It seems to come from SCIM 1.=0A>=0A>=0A>If= we were to proceed with bulk, I would recommend striking this paragraph.= =0A>=0A>=0A>Phil=0A>=0A>=0A>@independentid=0A>www.independentid.comphil.hun= t@oracle.com=0A>=0A>=0A>=0A>=0A>___________________________________________= ____=0A>scim mailing list=0A>scim@ietf.org=0A>https://www.ietf.org/mailman/= listinfo/scim=0A>=0A>=0A>=0A=0A____________________________________________= ___=0Ascim mailing list=0Ascim@ietf.org=0Ahttps://www.ietf.org/mailman/list= info/scim ---2129327256-1940524518-1405962023=:65562 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Implying that there is an ordering in bulk transac= tions is interesting, and I think not supported by the draft text.  I = also doubt there is any great efficiency to be gained by having 1k transact= ions in a single bulk operation in the end, other than a single authn check= instead of 1k.

SPDY would get you equivalent throughput and you lose the complexity of the bulk error message handling.


On Monday, July 21, 2014 8:33 AM, Phil Hunt &l= t;phil.hunt@oracle.com> wrote:


Not sure I underst= and the use of spdy. 

Seems us= eful if you want to maintain a high rate update stream.  But in this c= ase Bulk would simply be passing 1000s of changes at once which may be bett= er than 1000s of separate req/responses which may get out of sequence if yo= u aren't careful to account for connection pooling. 

Phil

On Jul 21, 2014, at 10:56, Bill Mills <= ;wmills_92105@ya= hoo.com> wrote:

I think = Bulk should be dropped in favor of something like supporting SPDY for high = volume.


= On Monday, July 21, 2014 7:41 AM, Phil Hunt <phil.hunt@oracle.com> wrote:


The follo= wing paragraph in Bulk was brought to my attention as problematic:
There can be more then one operation per resource in each= bulk job.=0A The Service client MUST take notice of the unordered struct= ure of=0A JSON and the service provider can process operations in any ord= er.=0A For example, if the Service client sends two PUT operations in one= =0A request, the outcome is non-deterministic.=0A

=0A
From our perspective this makes Bulk un-implementable, since other= paragraphs seem to depend on serial processing (eg bulkId). Anybody have a= ny background for this? It seems to come from SCIM 1.

If we were to proceed with bulk, I would recommend str= iking this paragraph.

Phil

@independentid
phil.hunt@oracle.c= om

<= /div>

=0A
=0A

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


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


---2129327256-1940524518-1405962023=:65562-- From nobody Mon Jul 21 10:07:47 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACBC11A00F2 for ; Mon, 21 Jul 2014 10:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-2DI9g8UR0Y for ; Mon, 21 Jul 2014 10:07:31 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16CBC1A0085 for ; Mon, 21 Jul 2014 10:07:26 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6LH7OtW005130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Jul 2014 17:07:25 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6LH7Nfe027760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Jul 2014 17:07:24 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6LH7N1g000586; Mon, 21 Jul 2014 17:07:23 GMT Received: from dhcp-a4c6.meeting.ietf.org (/31.133.164.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 21 Jul 2014 10:07:23 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_2FFF48DC-F01B-4B8D-882B-AA139D846A0F" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <1405962023.65562.YahooMailNeo@web142804.mail.bf1.yahoo.com> Date: Mon, 21 Jul 2014 13:07:19 -0400 Message-Id: References: <36A7B56D-EBF4-4208-AA3A-2DA7D118F8C2@oracle.com> <1405954605.9443.YahooMailNeo@web142804.mail.bf1.yahoo.com> <1405962023.65562.YahooMailNeo@web142804.mail.bf1.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/E3ZdslFNRBjbfw-kZB4agCzn4Ug Cc: SCIM WG Subject: Re: [scim] Bulk request has a non-deterministic condition X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 17:07:39 -0000 --Apple-Mail=_2FFF48DC-F01B-4B8D-882B-AA139D846A0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Bill, Erik clarified that he believed the lack of ordering is a mistake. = Ordering is critical if you are using bulkIds (e.g. add a user then add = that user to a series of groups). One of our developers commented that Bulk is also potentially useful if = you want to take a series of operations like add a user and place them = all into a group and treat the whole thing as pass/fail. I=92ll do some more reading on SPDY. Curious to understand how that = would fit. It=92s seeming like there are a lot who still want it. Maybe splitting = it off so we can explore things like SPDY is something to consider? It = also gives a chance for implementations to catch up on it. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 21, 2014, at 1:00 PM, Bill Mills wrote: > Implying that there is an ordering in bulk transactions is = interesting, and I think not supported by the draft text. I also doubt = there is any great efficiency to be gained by having 1k transactions in = a single bulk operation in the end, other than a single authn check = instead of 1k. >=20 > SPDY would get you equivalent throughput and you lose the complexity = of the bulk error message handling. >=20 >=20 > On Monday, July 21, 2014 8:33 AM, Phil Hunt = wrote: >=20 >=20 > Not sure I understand the use of spdy.=20 >=20 > Seems useful if you want to maintain a high rate update stream. But = in this case Bulk would simply be passing 1000s of changes at once which = may be better than 1000s of separate req/responses which may get out of = sequence if you aren't careful to account for connection pooling.=20 >=20 > Phil >=20 > On Jul 21, 2014, at 10:56, Bill Mills wrote: >=20 >> I think Bulk should be dropped in favor of something like supporting = SPDY for high volume. >>=20 >>=20 >> On Monday, July 21, 2014 7:41 AM, Phil Hunt = wrote: >>=20 >>=20 >> The following paragraph in Bulk was brought to my attention as = problematic: >> There can be more then one operation per resource in each bulk = job. >> The Service client MUST take notice of the unordered structure of >> JSON and the service provider can process operations in any order. >> For example, if the Service client sends two PUT operations in one >> request, the outcome is non-deterministic. >>=20 >> =46rom our perspective this makes Bulk un-implementable, since other = paragraphs seem to depend on serial processing (eg bulkId). Anybody have = any background for this? It seems to come from SCIM 1. >>=20 >> If we were to proceed with bulk, I would recommend striking this = paragraph. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >>=20 >>=20 >=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 --Apple-Mail=_2FFF48DC-F01B-4B8D-882B-AA139D846A0F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Bill,

Erik clarified that he = believed the lack of ordering is a mistake.  Ordering is critical = if you are using bulkIds (e.g. add a user then add that user to a series = of groups).

One of our developers commented = that Bulk is also potentially useful if you want to take a series of = operations like add a user and place them all into a group and treat the = whole thing as pass/fail.

I=92ll do some more = reading on SPDY. Curious to understand how that would = fit.

It=92s seeming like there are a lot who = still want it.  Maybe splitting it off so we can explore things = like SPDY is something to consider?  It also gives a chance for = implementations to catch up on it.


On Jul 21, 2014, at 1:00 PM, Bill Mills <wmills_92105@yahoo.com> = wrote:

Implying that there is = an ordering in bulk transactions is interesting, and I think not = supported by the draft text.  I also doubt there is any great = efficiency to be gained by having 1k transactions in a single bulk = operation in the end, other than a single authn check instead of = 1k.

SPDY would get you equivalent = throughput and you lose the complexity of the bulk error message = handling.


On Monday, July 21, 2014 8:33 AM, Phil Hunt <phil.hunt@oracle.com> = wrote:


Not sure I understand the use of = spdy. 

Seems useful if you = want to maintain a high rate update stream.  But in this case Bulk = would simply be passing 1000s of changes at once which may be better = than 1000s of separate req/responses which may get out of sequence if = you aren't careful to account for connection pooling. 

Phil

On Jul 21, 2014, at = 10:56, Bill Mills <wmills_92105@yahoo.com> = wrote:

I think Bulk should be = dropped in favor of something like supporting SPDY for high = volume.


On Monday, July 21, 2014 7:41 AM, Phil Hunt = <phil.hunt@oracle.com> = wrote:


The following paragraph in Bulk was brought to my = attention as problematic:
   There can =
be more then one operation per resource in each bulk job.
   The Service client MUST take notice of the unordered structure of
   JSON and the service provider can process operations in any order.
   For example, if the Service client sends two PUT operations in one
   request, the outcome is non-deterministic.

=46rom our = perspective this makes Bulk un-implementable, since other paragraphs = seem to depend on serial processing (eg bulkId). Anybody have any = background for this? It seems to come from SCIM 1.

If we were to proceed with bulk, I would = recommend striking this paragraph.

Phil

@independentid
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/mailman/listinfo/scim


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

= --Apple-Mail=_2FFF48DC-F01B-4B8D-882B-AA139D846A0F-- From nobody Mon Jul 21 11:14:09 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32CE41A0336 for ; Mon, 21 Jul 2014 11:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPCzT18rggIs for ; Mon, 21 Jul 2014 11:14:03 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 464911A002D for ; Mon, 21 Jul 2014 11:14:03 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) with Microsoft SMTP Server (TLS) id 15.0.990.7; Mon, 21 Jul 2014 18:14:01 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.122]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.122]) with mapi id 15.00.0990.007; Mon, 21 Jul 2014 18:14:01 +0000 From: Kelly Grizzle To: Phil Hunt , Ian Glazer Thread-Topic: [scim] Comments for sections 3.4 to the end Thread-Index: AQHPoEHXsYU0SdeevUOuHQ6VU+HA2pumruqAgAM8xbA= Date: Mon, 21 Jul 2014 18:14:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 06AB1631007AEE06AB177E x-originating-ip: [70.114.158.171] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0279B3DD0D x-forefront-antispam-report: SFV:NSPM; SFS:(51704005)(377454003)(24454002)(189002)(199002)(43784003)(51444003)(106356001)(81342001)(19617315012)(106116001)(80022001)(95666004)(99286002)(81542001)(83322001)(74502001)(107046002)(76482001)(77096002)(15975445006)(85306003)(74316001)(19609705001)(77982001)(64706001)(74662001)(20776003)(92566001)(86362001)(551544002)(4396001)(83072002)(85852003)(87936001)(31966008)(66066001)(99396002)(2656002)(33646002)(105586002)(19580395003)(76576001)(19300405004)(21056001)(19625215002)(46102001)(16601075003)(79102001)(15202345003)(19580405001)(101416001)(76176999)(16236675004)(54356999)(50986999)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_a1420dfdc6744b469413da6030854886BN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/CAKVtucy8vW1FwDu_nFf89eq3vM Cc: "scim@ietf.org WG" Subject: Re: [scim] Comments for sections 3.4 to the end X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 18:14:07 -0000 --_000_a1420dfdc6744b469413da6030854886BN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Yet, I can see it is perfectly reasonable that a SP may never release a u= sername once used. Maybe the wording we have is a bit too tight? +1 for loosening the requirement here. > 6.4 - Universal Identifiers - ? > > I saw that today. I can't recall what that was about. I think it was goi= ng to be a caution about > using things like DN's as identifiers and the need to ensure universality= and stability (does not change). > > Maybe someone else recalls? I think that you added this in draft 5 (it doesn't show up in -04.xml). https://code.google.com/p/scim/source/detail?spec=3Dsvn248&r=3D241 I just looked through the tickets mentioned in this changeset and didn't se= e anything really related to universal identifiers (as far as I can tell). = I'd say just drop the section. --Kelly From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Friday, July 18, 2014 7:18 PM To: Ian Glazer Cc: scim@ietf.org WG Subject: Re: [scim] Comments for sections 3.4 to the end Ian... thanks again. Comments inline Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 15, 2014, at 8:29 AM, Ian Glazer > wrote: Here's a few more comments: 3.4 Delete - Does an SP who chooses not to permanently delete a resource ha= ve to tell the client of that choice? The wording in 3.4 is intentional and leaves room for the record to be reta= ined. However, as far as the REST API is concerned the record is gone. I've had some thought that we may need to define functions down the road th= e provide high-level IDM functions like password self service, de-provision= ing/de-activation, etc that go beyond simple state changes. If we do that,= the way we've worded DELETE for now should be compatible. 3.4 Delete conflicts - "SP MUST not consider deleted resource in conflict c= alculation" - What about situations where the SP requires all userNames to= be unique and holds delete accounts to ensure no repetition of userNames? = This might cause a problem for Salesforce. Yes. This is an issue. The current text says the SP is to act as if the res= ource is gone. That potentially means freeing up old user-ids. Yet, I can see it is perfectly reasonable that a SP may never release a use= rname once used. Maybe the wording we have is a bit too tight? 3.5 Bulk - Maybe my memory failed me here but I thought we were carving Bul= k out as its own profile to be dealt with later. Given that no one has impl= emented it I wonder if it doesn't make sense to completely pull it and put = it into a future profile. I think I commented earlier - several orgs were starting implementation the= last time we discussed. I think the idea will be to discuss in Toronto and= confirm we are keeping it. 3.5 Bulk - formatting issue - Page 38 of the pdf. The paragraph beginning "= The following example shows how to add..." is formatted like example code n= ot regular text. Will fix. 3.5 Bulk - formatting issue - Page 40 of the pdf. The paragraph beginning "= The following response is returned if an error occurred..." is formatted li= ke example code not regular text. Will fix 3.5 Bulk - formatting issue - same problems on pages 41 and 42 as 38 and 40= . Ditto. 3.7 attributes - If "attributes" are specified, it isn't clear if default a= ttributes are also returned along with the minimum set and those specified.= I think this needs to say explicitly that default attributes are not retur= ned when "attributes" are specified. Will correct. 6.4 - Universal Identifiers - ? I saw that today. I can't recall what that was about. I think it was going= to be a caution about using things like DN's as identifiers and the need t= o ensure universality and stability (does not change). Maybe someone else recalls? -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_a1420dfdc6744b469413da6030854886BN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> Yet, I can see it is perfectly reasonable that a SP may never releas= e a username once used. Maybe the wording we have is a bit too tight?

+1 for loosening the = requirement here.

 <= /p>

 <= /p>

 

> 6.4 - Universal Identifiers - ?

>

> I saw that today. I can’t recall what tha= t was about.  I think it was going to be a caution about

> using things like DN’s as identifiers and= the need to ensure universality and stability (does not change). 

> 

> Maybe someone else recalls?

I think that you added th= is in draft 5 (it doesn’t show up in -04.xml).

 <= /p>

https://code.goog= le.com/p/scim/source/detail?spec=3Dsvn248&r=3D241=

 <= /p>

I just looked through the= tickets mentioned in this changeset and didn’t see anything really r= elated to universal identifiers (as far as I can tell).  I’d say just drop the section.

 <= /p>

--Kelly=

 <= /p>

From: scim [ma= ilto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Friday, July 18, 2014 7:18 PM
To: Ian Glazer
Cc: scim@ietf.org WG
Subject: Re: [scim] Comments for sections 3.4 to the end<= /span>

 

Ian… thanks again.  Comments inline<= /o:p>

 

Phil

 

@independentid<= /span>

ph= il.hunt@oracle.com

 

 

 

On Jul 15, 2014, at 8:29 AM, Ian Glazer <iglazer@salesforce.com> wrote:



Here's a few more comments:

 

3.4 Delete - Does an SP who chooses not to permanent= ly delete a resource have to tell the client of that choice?

 

The wording in 3.4 is intentional and leaves room fo= r the record to be retained. However, as far as the REST API is concerned t= he record is gone.

 

I’ve had some thought that we may need to defi= ne functions down the road the provide high-level IDM functions like passwo= rd self service, de-provisioning/de-activation, etc that go beyond simple s= tate changes.  If we do that, the way we’ve worded DELETE for now should be compatible. 

 

3.4 Delete conflicts - "SP MUST not consider de= leted resource in conflict calculation" -  What about situations = where the SP requires all userNames to be unique and holds delete accounts = to ensure no repetition of userNames? This might cause a problem for Salesforce.

 

Yes. This is an issue. The current text says the SP = is to act as if the resource is gone.  That potentially means freeing = up old user-ids. 

 

Yet, I can see it is perfectly reasonable that a SP = may never release a username once used. Maybe the wording we have is a bit = too tight?

 

3.5 Bulk - Maybe my memory failed me here but I thou= ght we were carving Bulk out as its own profile to be dealt with later. Giv= en that no one has implemented it I wonder if it doesn't make sense to comp= letely pull it and put it into a future profile.

 

I think I commented earlier — several orgs wer= e starting implementation the last time we discussed. I think the idea will= be to discuss in Toronto and confirm we are keeping it.

 

3.5 Bulk - formatting issue - Page 38 of the pdf. Th= e paragraph beginning "The following example shows how to add..."= is formatted like example code not regular text.

 

Will fix.

 

3.5 Bulk - formatting issue - Page 40 of the pdf. Th= e paragraph beginning "The following response is returned if an error = occurred..." is formatted like example code not regular text.

Will fix

 

3.5 Bulk - formatting issue - same problems on pages= 41 and 42 as 38 and 40.

Ditto.

 

3.7 attributes - If "attributes" are speci= fied, it isn't clear if default attributes are also returned along with the= minimum set and those specified. I think this needs to say explicitly that= default attributes are not returned when "attributes" are specified.

 

Will correct.

 

6.4 - Universal Identifiers - ?

 

I saw that today. I can’t recall what that was= about.  I think it was going to be a caution about using things like = DN’s as identifiers and the need to ensure universality and stability= (does not change). 

 

Maybe someone else recalls?

 

 

--

Ian Glazer

Senior Director, Identity

+1 202 255 3166

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

 

--_000_a1420dfdc6744b469413da6030854886BN1PR04MB392namprd04pro_-- From nobody Mon Jul 21 13:13:35 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4AA11A008D for ; Mon, 21 Jul 2014 13:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyFAKKiJ5S6h for ; Mon, 21 Jul 2014 13:13:27 -0700 (PDT) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B34731A0062 for ; Mon, 21 Jul 2014 13:13:24 -0700 (PDT) Received: from NG-EX04.ad.nexusgroup.com (10.75.28.9) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 21 Jul 2014 22:13:08 +0200 Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX04.ad.nexusgroup.com (10.75.28.9) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 21 Jul 2014 22:13:07 +0200 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0847.030; Mon, 21 Jul 2014 22:13:01 +0200 From: =?Windows-1252?Q?Erik_Wahlstr=F6m?= To: Ian Glazer Thread-Topic: [scim] Comments for sections 3.4 to the end Thread-Index: AQHPoEHffZEGnh4ka0yB2U7n5xtwPJuq3kqA Date: Mon, 21 Jul 2014 20:13:01 +0000 Message-ID: <009DE5E3-D0C2-45FC-AB88-BE80FE3BF86A@nexusgroup.com> 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: [94.234.170.213] Content-Type: multipart/alternative; boundary="_000_009DE5E3D0C245FCAB88BE80FE3BF86Anexusgroupcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/U2Pyya8-UVOV7aVaIKgM2rA1QpM Cc: "scim@ietf.org WG" Subject: Re: [scim] Comments for sections 3.4 to the end X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 20:13:30 -0000 --_000_009DE5E3D0C245FCAB88BE80FE3BF86Anexusgroupcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable My comments on the API doc. Might be some duplicates in there. Mostly minor= comments. General comments: - I think that the Protocol document requires more examples when it comes t= o the Schema, ResourceTypes and the ServiceProviderConfigs end points. They= are kinda special, how are they handled when it comes to search for exampl= e. - The ResourceType is messy. Merge it with a resource instead? =97=97=97=97=97=97=97=97=97 1. Introduction and Overview Current: The protocol supports creation, modification, retrieval, and discovery of core identity resources; i.e., Users and Groups, as well as custom resource extensions. Comment: The last sentence limits the protocol to just extensions to Users and G= roups. SCIM can also provision other types of resources (Schema and Service= ProviderConfigs) and it can also be extended with new types of Resources li= ke Machine or Device. =97=97=97=97=97=97=97=97=97 1.1. Intended Audience Current: This document is intended as a guide to SCIM API usage for both identity service providers and clients. To: This document is intended as a guide to SCIM Protocol usage for both identity service providers and clients. =97=97=97=97=97=97=97=97=97 1.3. Definitions Current: The SCIM HTTP API is always relative to a Base URL. To: The SCIM HTTP Protocol is always relative to a Base URL. -------------- 3. API Current text: Change title from "3. API" To: "3. Protocol" ----------- 3. API (The Resource endpoint table) It's not totally up to date. Only DELETE have links to the delete section i= n the document. On both User and Group, current text says: "Retrieve/Add/Modify Users" To: "Retrieve/Add/Modify/Delete Users" -------- 3. API Current: "Retrieve a resource's schema" Comment: It can read more then just one schemas resource, it can also be used to lis= t all supported schemas. ----------- 3. API Current: "To create new resources, clients send POST requests to the resource contai= ner endpoint such as: "/Users" or "/Groups"." To: "To create new resources, clients send POST requests to the resource endpoi= nt such as: "/Users" or "/Groups"." Comment: Why use the word container? ---------- 3.1.1. Resource Types Current: "When adding a resource to a specific endpoint, the meta attribute "resourceType" SHALL be set by the service provider to the corresponding resource Type for the endpoint." Comment: Why SHALL? Why not MUST? --------- 3.2. Retrieving Resources Current: ""User" and "Group" resources are retrieved via opaque, unique URLs or via = Query." To: Resources are retrieved via opaque, unique URLs or via Query. Comment: It applies to more resources then just User and Groups (even Resources defi= ned in the document). --------- 3.2.1. Retrieving a known Resource Current: "To retrieve a known resource, clients send GET requests to the resource endpoint; e.g., "/Users/{id}" or "/Groups/{id}"."" To: "To retrieve a known resource, clients send GET requests to the resource endpoint; e.g., "/Users/{id}", "/Groups/{id}" or "/Schema/{id}". Comment: How about adding some of the other resources types for clarity? --------- 3.2.2.1. Query Endpoints Current: "/Users/{userid}" Comment: Sometimes we use /Users/{id} and sometimes /Users/{userid}. I propose that = we always use {id}. -------- 3.2.2.2. Filtering Current: "The attribute name and attribute operator are case insensitive." Comment: Something feels wrong with this? English is not native language, like C :),= but itn's it "is" instead of "are"? --------- 3.2.2.3. Sorting Current: "for caee insensitive attributes" To: "for case insensitive attributes" ---------- 3.3. Modifying Resources Current: "PATCH [RFC5789] to " Comment: Links to the RFC, should be linked to Normative References secion instead. -------- 3.3.1. Replacing with PUT Current: "Clients that would like to override a server defaults, MAY specify "null" for a single-valued attribute or an empty array "[]" for a multi-valued attribute to clear all values." Comment: Why do we have something like this? It adds a complexity to the service pro= vider and for not so much reasons. Should be up to the SP what to store and= how to interpritate the clients requests. We even state in the next sectio= n "Since the server is free to alter and/or ignore POSTed content". I propose to remove that capability= for the client. --------- 3.3.1. Replacing with PUT Current: "to correlate the client's and Provider's views of the updated resource" To: "to correlate the Client's and Service Provider's views of the updated reso= urce" --------- 3.3.2. Modifying with PATCH Current: "If a request fails. the server SHALL" To: "If a request fails, the server SHALL" Comment: Comma instead of period. ---------- 3.4. Deleting Resources Current: "operations associated with the previously deleted Id" To: "operations associated with the previously deleted id" Comment: Capital I in Id. ------------- 3.5. Bulk Current: "version The current resource version. Version is REQUIRED if the service provider supports ETags and the method is PUT, DELETE, or PATCH." To: "version The current resource version." Comment: In "3.12. Versioning Resources" we now state that client MAY send it in PU= T and PATCH (not DELETE, we just delete the resource) We should also remove the version attribute in the DELETE requests in the b= ulk jobs. Example: Current: { "method":"DELETE", "path":"/Users/e9025315-6bea-44e1-899c-1e07454e468b", "version":"W\/\"0ee8add0a938e1a\"" } ] } To: { "method":"DELETE", "path":"/Users/e9025315-6bea-44e1-899c-1e07454e468b" } ] } ---------- 3.7. Additional Operation Response Parameters Comment: It feels like we usually talk about MUST attributes in the core sc= hema, this is more generic, but a bit fuzzier. Can we say both? -------------------- 3.7. Additional Operation Response Parameters Current: "The defaut attribute set are those attributes whose schema have "returned"= set to "default"." To: "The default attribute set are those attributes whose schema have "returned= " set to "default"." ------------ 3.9. "/Me" Authenticated Subject Alias Current: "A client MAY use a URL of the form "/Me" as an URL alias" Comment: Shoudn't it be "/Me"? We have a /Me interface, but it's not hoste= d on the server-root. ------------- Authors' Addresses From: Erik Wahlstroem Technology Nexus Email: erik.wahlstrom@nexussafe.com To: Erik Wahlstroem Nexus Technology Email: erik.wahlstrom@nexusgroup.com Comment: New legal name, and new email address. =97=97=97=97=97=97=97=97=97 / Erik On 15 Jul 2014, at 17:29, Ian Glazer > wrote: Here's a few more comments: 3.4 Delete - Does an SP who chooses not to permanently delete a resource ha= ve to tell the client of that choice? 3.4 Delete conflicts - "SP MUST not consider deleted resource in conflict c= alculation" - What about situations where the SP requires all userNames to= be unique and holds delete accounts to ensure no repetition of userNames? = This might cause a problem for Salesforce. 3.5 Bulk - Maybe my memory failed me here but I thought we were carving Bul= k out as its own profile to be dealt with later. Given that no one has impl= emented it I wonder if it doesn't make sense to completely pull it and put = it into a future profile. 3.5 Bulk - formatting issue - Page 38 of the pdf. The paragraph beginning "= The following example shows how to add..." is formatted like example code n= ot regular text. 3.5 Bulk - formatting issue - Page 40 of the pdf. The paragraph beginning "= The following response is returned if an error occurred..." is formatted li= ke example code not regular text. 3.5 Bulk - formatting issue - same problems on pages 41 and 42 as 38 and 40= . 3.7 attributes - If "attributes" are specified, it isn't clear if default a= ttributes are also returned along with the minimum set and those specified.= I think this needs to say explicitly that default attributes are not retur= ned when "attributes" are specified. 6.4 - Universal Identifiers - ? -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_009DE5E3D0C245FCAB88BE80FE3BF86Anexusgroupcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <011E2985A9013E4F8C5E2EA396741BFE@nexusgroup.com> Content-Transfer-Encoding: quoted-printable My comments on the API doc. Might be some duplicates in there. Mostly minor= comments.


General comments:
- I think that the Protocol document requires more examples when it co= mes to the Schema, ResourceTypes and the ServiceProviderConfigs end points.= They are kinda special, how are they handled when it comes to search for e= xample. 
- The ResourceType is messy. Merge it with a resource instead? 

=97=97=97=97=97=97=97=97=97

1.  Introduction and Overview

Current:
   The protocol
   supports creation, modification, retrieval, and discovery= of core
   identity resources; i.e., Users and Groups, as well as cu= stom
   resource extensions.

Comment:
    The last sentence limits the protocol to just extensions= to Users and Groups. SCIM can also provision other types of resources (Sch= ema and ServiceProviderConfigs) and it can also be extended with new types = of Resources like Machine or Device.

=97=97=97=97=97=97=97=97=97


1.1.  Intended Audience

Current:
   This document is intended as a guide to SCIM API usage fo= r both
   identity service providers and clients.

To:
   This document is intended as a guide to SCIM Protocol usa= ge for both
   identity service providers and clients.

=97=97=97=97=97=97=97=97=97

1.3.  Definitions

Current:
The SC= IM HTTP API is always relative to a Base URL.  

To:
The SC= IM HTTP Protocol is always relative to a Base URL.  

--------------

3.  API

Current text: Change title from "3. API"

To: "3. Protocol"

-----------

3.  API (The Resource endpoint table)

It's not totally up to date. Only DELETE have links to the delete sect= ion in the document.

On both User and Group, current text says:
"= Retrieve/Add/Modify Users"
To:
"= Retrieve/Add/Modify/Delete Users"

--------

3.  API

Current:
"= Retrieve a resource's schema"
Comment:
It can= read more then just one schemas resource, it can also be used to list all = supported schemas.

----------- <= /span>

3.  API

Current:
"= To create new resources, clients send POST requests to the resource contain= er endpoint such as: "/Users" or "/Groups"."
To:
"= To create new resources, clients send POST requests to the resource endpoin= t such as: "/Users" or "/Groups"."
Comment:
Why us= e the word container?

----------


3.1.1.  Resource Types

Current: "When adding a resource to a specific endpoint, the meta attribute<= /div>
 = "resourceType" SHALL be set by the service provider to the
 = corresponding resource Type for the endpoint."
Comment: 
Why SH= ALL? Why not MUST?

---------

3.2.  Retrieving Resources

Current:   
"= "User" and "Group" resources are retrieved via opaque, = unique URLs or via Query."
To: 
Resour= ces are retrieved via opaque, unique URLs or via Query.
Comment:
It app= lies to more resources then just User and Groups (even Resources defined in= the document).

---------

3.2.1.  Retrieving a known Resource

Current:
   "To retrieve a known resource, clients send GET requ= ests to the
   resource endpoint; e.g., "/Users/{id}" or "= ;/Groups/{id}".""

To:
"= To retrieve a known resource, clients send GET requests to the
resour= ce endpoint; e.g., "/Users/{id}", "/Groups/{id}" or &qu= ot;/Schema/{id}".

Comment:
How ab= out adding some of the other resources types for clarity? 

---------

3.2.2.1.  Query Endpoints
Current: 
"= /Users/{userid}"
Comment:
Someti= mes we use /Users/{id} and sometimes /Users/{userid}. I propose that we alw= ays use {id}.

--------

3.2.2.2.  Filtering

Current:
"= The attribute name and attribute operator are case insensitive."
Comment:
Someth= ing feels wrong with this? English is not native language, like C :), but i= tn's it "is" instead of "are"?

---------

3.2.2.3.  Sorting

Current:
"= for caee insensitive attributes"
To:
"= for case insensitive attributes"
----------

3.3.  Modifying Resources

Current:
"= PATCH [RFC5789] to "
Comment: 
Links = to the RFC, should be linked to Normative References secion instead.

--------

3.3.1.  Replacing with PUT

Current:
"= Clients that would like to override a
   server defaults, MAY specify "null" for a singl= e-valued attribute or
   an empty array "[]" for a multi-valued attribut= e to clear all values."
Comment:
Why do= we have something like this? It adds a complexity to the service provider = and for not so much reasons. Should be up to the SP what to store and how t= o interpritate the clients requests. We even state in the next section "Since the server is free to
   alter and/or ignore POSTed content". I propose to re= move that capability for the client.

---------

3.3.1.  Replacing with PUT

Current:
"= to correlate the client's and Provider's views of the updated resource"= ;
To:
"= to correlate the Client's and Service Provider's views of the updated resou= rce"

---------

3.3.2.  Modifying with PATCH

Current:
"= If a request fails. the server SHALL"
To:
"= If a request fails, the server SHALL"
Comment:
Comma = instead of period.

----------

3.4.  Deleting Resources

Current: "operations associated with the previously deleted Id&qu= ot;
To: "operations associated with the previously deleted id"
Comment: Capital I in Id.

-------------

3.5.  Bulk

Current: 
"= version  The current resource version.  Version is REQUIRED if th= e
         service provider supports ETags and = the method is PUT, DELETE,
         or PATCH."

To:
"= version  The current resource version."

Comment:
In "3.12.  Versioning Resources" we now state that clie= nt MAY send it in PUT and PATCH (not DELETE, we just delete the resource)

We should also remove the version attribute in the DELETE requests in = the bulk jobs. Example:

Current:
       {
         "method":"DELETE"= ;,
         "path":"/Users/e90253= 15-6bea-44e1-899c-1e07454e468b",
         "version":"W\/\"= 0ee8add0a938e1a\""
       }
     ]
   }

To:
       {
         "method":"DELETE"= ;,
         "path":"/Users/e90253= 15-6bea-44e1-899c-1e07454e468b"
       }
     ]
   }

----------

3.7.  Additional Operation Response Parameters

Comment: It feels like we usually talk about MUST attributes in the co= re schema, this is more generic, but a bit fuzzier. Can we say both?

--------------------

3.7.  Additional Operation Response Parameters

Current: 
"= The defaut attribute set are those attributes whose schema have "retur= ned" set to "default"."
To:
"= The default attribute set are those attributes whose schema have "retu= rned" set to "default"."

------------

3.9.  "/Me" Authenticated Subject Alias

Current:
"= A client MAY use a URL of the form "<server-root>/Me" as an= URL alias"
Comment:
Shoudn= 't it be "<base-url>/Me"? We have a /Me interface, but it's= not hosted on the server-root.

-------------   
   

Authors' Addresses

From:

   Erik Wahlstroem
   Technology Nexus


To:

   Erik Wahlstroem
   Nexus Technology


Comment:
New le= gal name, and new email address.

=97=97=97=97=97=97=97=97=97


/ Erik


On 15 Jul 2014, at 17:29, Ian Glazer <iglazer@salesforce.com> wrote:

Here's a few more comments:

3.4 Delete - Does an SP who chooses not to permanently delete a resour= ce have to tell the client of that choice?

3.4 Delete conflicts - "SP MUST not consider deleted resource in = conflict calculation" -  What about situations where the SP requi= res all userNames to be unique and holds delete accounts to ensure no repet= ition of userNames? This might cause a problem for Salesforce.

3.5 Bulk - Maybe my memory failed me here but I thought we were carvin= g Bulk out as its own profile to be dealt with later. Given that no one has= implemented it I wonder if it doesn't make sense to completely pull it and= put it into a future profile.

3.5 Bulk - formatting issue - Page 38 of the pdf. The paragraph beginn= ing "The following example shows how to add..." is formatted like= example code not regular text.

3.5 Bulk - formatting issue - Page 40 of the pdf. The paragraph beginn= ing "The following response is returned if an error occurred..." = is formatted like example code not regular text.

3.5 Bulk - formatting issue - same problems on pages 41 and 42 as 38 a= nd 40.

3.7 attributes - If "attributes" are specified, it isn't cle= ar if default attributes are also returned along with the minimum set and t= hose specified. I think this needs to say explicitly that default attribute= s are not returned when "attributes" are specified.

6.4 - Universal Identifiers - ?


--
Ian Glazer
Senior Director, Identity
+1 202 255 3166
_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

--_000_009DE5E3D0C245FCAB88BE80FE3BF86Anexusgroupcom_-- From nobody Mon Jul 21 14:03:22 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC621A035E for ; Mon, 21 Jul 2014 14:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXZC_KySPrdw for ; Mon, 21 Jul 2014 14:03:17 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F641A02E3 for ; Mon, 21 Jul 2014 14:03:17 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6LL3Fd2012068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Jul 2014 21:03:16 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s6LL3ETu023348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jul 2014 21:03:14 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s6LL3Dx3023217; Mon, 21 Jul 2014 21:03:13 GMT Received: from dhcp-8ab1.meeting.ietf.org (/31.133.138.177) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 21 Jul 2014 14:03:09 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_C17CACD1-BEA6-4948-9888-EA22F739148A" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <009DE5E3-D0C2-45FC-AB88-BE80FE3BF86A@nexusgroup.com> Date: Mon, 21 Jul 2014 17:03:06 -0400 Message-Id: References: <009DE5E3-D0C2-45FC-AB88-BE80FE3BF86A@nexusgroup.com> To: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= X-Mailer: Apple Mail (2.1878.6) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/DXRTtHG8SpaAFBD-qAOaWyfp3iY Cc: "scim@ietf.org WG" , Ian Glazer Subject: Re: [scim] Comments for sections 3.4 to the end X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 21:03:21 -0000 --Apple-Mail=_C17CACD1-BEA6-4948-9888-EA22F739148A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Erik, I think in general, we will align around HTTP protocol=85.no need for = everyone to enumerate them. See other comments below=85 Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 21, 2014, at 4:13 PM, Erik Wahlstr=F6m = wrote: > My comments on the API doc. Might be some duplicates in there. Mostly = minor comments. >=20 >=20 > General comments: > - I think that the Protocol document requires more examples when it = comes to the Schema, ResourceTypes and the ServiceProviderConfigs end = points. They are kinda special, how are they handled when it comes to = search for example.=20 > - The ResourceType is messy. Merge it with a resource instead?=20 >=20 Can you make some suggestions? > =97=97=97=97=97=97=97=97=97 >=20 > 1. Introduction and Overview >=20 > Current: > The protocol > supports creation, modification, retrieval, and discovery of core > identity resources; i.e., Users and Groups, as well as custom > resource extensions. >=20 > Comment: > The last sentence limits the protocol to just extensions to Users = and Groups. SCIM can also provision other types of resources (Schema and = ServiceProviderConfigs) and it can also be extended with new types of = Resources like Machine or Device. >=20 Agreed > =97=97=97=97=97=97=97=97=97 >=20 >=20 > 1.1. Intended Audience >=20 > Current: > This document is intended as a guide to SCIM API usage for both > identity service providers and clients. >=20 > To: > This document is intended as a guide to SCIM Protocol usage for = both > identity service providers and clients. >=20 > =97=97=97=97=97=97=97=97=97 >=20 > 1.3. Definitions >=20 > Current: > The SCIM HTTP API is always relative to a Base URL. =20 >=20 > To: > The SCIM HTTP Protocol is always relative to a Base URL. =20 >=20 > -------------- >=20 > 3. API >=20 > Current text: Change title from "3. API" >=20 > To: "3. Protocol" >=20 We should discuss at meeting. > ----------- >=20 > 3. API (The Resource endpoint table) >=20 > It's not totally up to date. Only DELETE have links to the delete = section in the document. >=20 > On both User and Group, current text says: > "Retrieve/Add/Modify Users" > To: > "Retrieve/Add/Modify/Delete Users=94 There seems to be a bug in the xml2rfc processor. Only random links are = being generated. I=92ve checked and the underlying xml is correct. I think we have to leave this to the final RFC editors who will fix this = stuff. >=20 > -------- >=20 > 3. API >=20 > Current: > "Retrieve a resource's schema" > Comment: > It can read more then just one schemas resource, it can also be used = to list all supported schemas. >=20 Agreed: > -----------=20 >=20 > 3. API >=20 > Current: > "To create new resources, clients send POST requests to the resource = container endpoint such as: "/Users" or "/Groups"." > To: > "To create new resources, clients send POST requests to the resource = endpoint such as: "/Users" or "/Groups"." > Comment: > Why use the word container? I notice this is a common term being using in REST. =93/Users=94 is a = container (a folder). =93Endpoint=94 is not distinguished from a user=92s = specific endpoint. Not sure this is a big deal. But we should be editorially consistent. >=20 > ---------- >=20 >=20 > 3.1.1. Resource Types >=20 > Current: "When adding a resource to a specific endpoint, the meta = attribute > "resourceType" SHALL be set by the service provider to the > corresponding resource Type for the endpoint." > Comment:=20 > Why SHALL? Why not MUST? It sounded better. SHALL is equivalent of MUST in RFC terms. SHALL also = implies the service provider is doing it in response to the client. >=20 > --------- >=20 > 3.2. Retrieving Resources >=20 > Current: =20 > ""User" and "Group" resources are retrieved via opaque, unique URLs or = via Query." > To:=20 > Resources are retrieved via opaque, unique URLs or via Query. > Comment: > It applies to more resources then just User and Groups (even Resources = defined in the document). >=20 Agreed - -we should make sure the entire spec is generic. > --------- >=20 > 3.2.1. Retrieving a known Resource >=20 > Current: > "To retrieve a known resource, clients send GET requests to the > resource endpoint; e.g., "/Users/{id}" or "/Groups/{id}"."" >=20 > To: > "To retrieve a known resource, clients send GET requests to the > resource endpoint; e.g., "/Users/{id}", "/Groups/{id}" or = "/Schema/{id}". >=20 > Comment: > How about adding some of the other resources types for clarity?=20 >=20 Agreed. More examples or at least genericize > --------- >=20 > 3.2.2.1. Query Endpoints > Current:=20 > "/Users/{userid}" > Comment: > Sometimes we use /Users/{id} and sometimes /Users/{userid}. I propose = that we always use {id}. Agreed. >=20 > -------- >=20 > 3.2.2.2. Filtering >=20 > Current: > "The attribute name and attribute operator are case insensitive." > Comment: > Something feels wrong with this? English is not native language, like = C :), but itn's it "is" instead of "are=94? Not quite right. Attribute names and operators are case insensitive. >=20 > --------- >=20 > 3.2.2.3. Sorting >=20 > Current: > "for caee insensitive attributes" > To: > "for case insensitive attributes" > ---------- >=20 agreed > 3.3. Modifying Resources >=20 > Current: > "PATCH [RFC5789] to " > Comment:=20 > Links to the RFC, should be linked to Normative References secion = instead. The xml2rfc generator takes care of this. Current style seems to be = direct links. >=20 > -------- >=20 > 3.3.1. Replacing with PUT >=20 > Current: > "Clients that would like to override a > server defaults, MAY specify "null" for a single-valued attribute = or > an empty array "[]" for a multi-valued attribute to clear all = values." > Comment: > Why do we have something like this? It adds a complexity to the = service provider and for not so much reasons. Should be up to the SP = what to store and how to interpritate the clients requests. We even = state in the next section "Since the server is free to > alter and/or ignore POSTed content". I propose to remove that = capability for the client. The change is intended to be minor. Rather than trying to infer meaning = of a missing value we instead go back to what the client is trying to = express. =46rom what I could figure out from the comments was that there are = times when a server will =93default=94 unasserted values (e.g. provide a = default set of roles). In the case where the client wants to have no = roles, the client can simply include =93roles=94:[] to indicate no roles = should be assigned. If the client includes no value, the logic is the = same as before. >=20 > --------- >=20 > 3.3.1. Replacing with PUT >=20 > Current: > "to correlate the client's and Provider's views of the updated = resource" > To: > "to correlate the Client's and Service Provider's views of the updated = resource=94 agreed >=20 > --------- >=20 > 3.3.2. Modifying with PATCH >=20 > Current: > "If a request fails. the server SHALL" > To: > "If a request fails, the server SHALL" > Comment: > Comma instead of period. >=20 agreed > ---------- >=20 > 3.4. Deleting Resources >=20 > Current: "operations associated with the previously deleted Id" > To: "operations associated with the previously deleted id" > Comment: Capital I in Id. >=20 check > ------------- >=20 > 3.5. Bulk >=20 > Current:=20 > "version The current resource version. Version is REQUIRED if the > service provider supports ETags and the method is PUT, = DELETE, > or PATCH." >=20 > To: > "version The current resource version." >=20 Is this meant to be an ETag? Why not use etag? > Comment: > In "3.12. Versioning Resources" we now state that client MAY send it = in PUT and PATCH (not DELETE, we just delete the resource) >=20 > We should also remove the version attribute in the DELETE requests in = the bulk jobs. Example: >=20 > Current: > { > "method":"DELETE", > "path":"/Users/e9025315-6bea-44e1-899c-1e07454e468b", > "version":"W\/\"0ee8add0a938e1a\"" > } > ] > } >=20 > To: > { > "method":"DELETE", > "path":"/Users/e9025315-6bea-44e1-899c-1e07454e468b" > } > ] > } >=20 > ---------- >=20 > 3.7. Additional Operation Response Parameters >=20 > Comment: It feels like we usually talk about MUST attributes in the = core schema, this is more generic, but a bit fuzzier. Can we say both? >=20 > -------------------- >=20 > 3.7. Additional Operation Response Parameters >=20 > Current:=20 > "The defaut attribute set are those attributes whose schema have = "returned" set to "default"." > To: > "The default attribute set are those attributes whose schema have = "returned" set to "default"." >=20 not sure what the differnence is > ------------ >=20 > 3.9. "/Me" Authenticated Subject Alias >=20 > Current: > "A client MAY use a URL of the form "/Me" as an URL = alias" > Comment: > Shoudn't it be "/Me"? We have a /Me interface, but it's not = hosted on the server-root. If SCIM defines this it has to be within the SCIM server=92s endpoint. = I wanted to say the root because I want to avoid tying it to =93Users=94. = =93/Me=94 might map back to /Clients/{id} (e.g. an oauth client).. >=20 > ------------- =20 > =20 >=20 > Authors' Addresses >=20 > From: >=20 > Erik Wahlstroem > Technology Nexus >=20 > Email: erik.wahlstrom@nexussafe.com >=20 > To: >=20 > Erik Wahlstroem > Nexus Technology >=20 > Email: erik.wahlstrom@nexusgroup.com >=20 > Comment: > New legal name, and new email address. ok >=20 > =97=97=97=97=97=97=97=97=97 >=20 >=20 > / Erik >=20 >=20 > On 15 Jul 2014, at 17:29, Ian Glazer wrote: >=20 >> Here's a few more comments: >>=20 >> 3.4 Delete - Does an SP who chooses not to permanently delete a = resource have to tell the client of that choice? >>=20 >> 3.4 Delete conflicts - "SP MUST not consider deleted resource in = conflict calculation" - What about situations where the SP requires all = userNames to be unique and holds delete accounts to ensure no repetition = of userNames? This might cause a problem for Salesforce. >>=20 >> 3.5 Bulk - Maybe my memory failed me here but I thought we were = carving Bulk out as its own profile to be dealt with later. Given that = no one has implemented it I wonder if it doesn't make sense to = completely pull it and put it into a future profile. >>=20 >> 3.5 Bulk - formatting issue - Page 38 of the pdf. The paragraph = beginning "The following example shows how to add..." is formatted like = example code not regular text. >>=20 >> 3.5 Bulk - formatting issue - Page 40 of the pdf. The paragraph = beginning "The following response is returned if an error occurred..." = is formatted like example code not regular text. >>=20 >> 3.5 Bulk - formatting issue - same problems on pages 41 and 42 as 38 = and 40. >>=20 >> 3.7 attributes - If "attributes" are specified, it isn't clear if = default attributes are also returned along with the minimum set and = those specified. I think this needs to say explicitly that default = attributes are not returned when "attributes" are specified. >>=20 >> 6.4 - Universal Identifiers - ? >>=20 >>=20 >> --=20 >> Ian Glazer >> Senior Director, Identity >> +1 202 255 3166 >> @iglazer >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_C17CACD1-BEA6-4948-9888-EA22F739148A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Erik,

I think in general, we will = align around HTTP protocol=85.no need for everyone to enumerate = them.

See other comments = below=85


On Jul 21, 2014, at 4:13 PM, Erik Wahlstr=F6m <erik.wahlstrom@nexusgroup.co= m> wrote:

My comments on the API doc. Might be some duplicates in there. Mostly = minor comments.


General comments:
- I think that the Protocol document requires more examples when it = comes to the Schema, ResourceTypes and the ServiceProviderConfigs end = points. They are kinda special, how are they handled when it comes to = search for example. 
- The ResourceType is messy. Merge it with a resource = instead? 

Can you make some = suggestions?
=97=97=97=97=97=97=97=97=97

1.  Introduction and Overview

Current:
   The protocol
   supports creation, modification, retrieval, and = discovery of core
   identity resources; i.e., Users and Groups, as well as = custom
   resource extensions.

Comment:
    The last sentence limits the protocol to just = extensions to Users and Groups. SCIM can also provision other types of = resources (Schema and ServiceProviderConfigs) and it can also be = extended with new types of Resources like Machine or Device.

Agreed
=97=97=97=97=97=97=97=97=97


1.1.  Intended Audience

Current:
   This document is intended as a guide to SCIM API usage = for both
   identity service providers and clients.

To:
   This document is intended as a guide to SCIM Protocol = usage for both
   identity service providers and clients.

=97=97=97=97=97=97=97=97=97

1.3.  Definitions

Current:
The = SCIM HTTP API is always relative to a Base URL.  

To:
The = SCIM HTTP Protocol is always relative to a Base URL.  

--------------

3.  API

Current text: Change title from "3. API"

To: "3. Protocol"

We should discuss at = meeting.
-----------

3.  API (The Resource endpoint table)

It's not totally up to date. Only DELETE have links to the delete = section in the document.

On both User and Group, current text says:
"Retrieve/Add/Modify Users"
To:
"Retrieve/Add/Modify/Delete = Users=94

There seems = to be a bug in the xml2rfc processor. Only random links are being = generated. I=92ve checked and the underlying xml is = correct.

I think we have to leave this to the = final RFC editors who will fix this stuff.

--------

3.  API

Current:
"Retrieve a resource's schema"
Comment:
It = can read more then just one schemas resource, it can also be used to = list all supported schemas.

Agreed:
----------- =

3.  API

Current:
"To = create new resources, clients send POST requests to the resource = container endpoint such as: "/Users" or "/Groups"."
To:
"To = create new resources, clients send POST requests to the resource = endpoint such as: "/Users" or "/Groups"."
Comment:
Why = use the word = container?

I notice = this is a common term being using in REST.  =93/Users=94 is a = container (a folder). =93Endpoint=94 is not distinguished from a user=92s = specific endpoint.

Not sure this is a big deal. =  But we should be editorially consistent.

----------


3.1.1.  Resource Types

Current: = "When adding a resource to a specific endpoint, the meta = attribute
  "resourceType" SHALL be set by = the service provider to the
  corresponding resource Type for = the endpoint."
Comment: 
Why = SHALL? Why not = MUST?

It sounded = better. SHALL is equivalent of MUST in RFC terms.  SHALL also = implies the service provider is doing it in response to the = client.

---------

3.2.  Retrieving Resources

Current:   
""User" and "Group" resources are = retrieved via opaque, unique URLs or via Query."
To: 
Resources are retrieved via opaque, = unique URLs or via Query.
Comment:
It = applies to more resources then just User and Groups (even Resources = defined in the document).

Agreed - -we should make = sure the entire spec is generic.
---------

3.2.1.  Retrieving a known Resource

Current:
   "To retrieve a known resource, clients send GET = requests to the
   resource endpoint; e.g., "/Users/{id}" or = "/Groups/{id}".""

To:
"To = retrieve a known resource, clients send GET requests to the
resource endpoint; e.g., "/Users/{id}", = "/Groups/{id}" or "/Schema/{id}".

Comment:
How = about adding some of the other resources types for clarity? 

Agreed. More examples or = at least genericize
---------

3.2.2.1.  Query Endpoints
Current: 
"/Users/{userid}"
Comment:
Sometimes we use /Users/{id} and = sometimes /Users/{userid}. I propose that we always use = {id}.

Agreed.

--------

3.2.2.2.  Filtering

Current:
"The = attribute name and attribute operator are case insensitive."
Comment:
Something feels wrong with this? = English is not native language, like C :), but itn's it "is" instead of = "are=94?

Not quite = right.

Attribute names and operators are case = insensitive.


---------

3.2.2.3.  Sorting

Current:
"for = caee insensitive attributes"
To:
"for = case insensitive attributes"
----------
=

agreed

3.3.  Modifying Resources

Current:
"PATCH [RFC5789] to "
Comment: 
Links= to the RFC, should be linked to Normative References secion = instead.

The xml2rfc = generator takes care of this. Current style seems to be direct = links.

--------

3.3.1.  Replacing with PUT

Current:
"Clients that would like to override = a
   server defaults, MAY specify "null" for a = single-valued attribute or
   an empty array "[]" for a multi-valued attribute to = clear all values."
Comment:
Why = do we have something like this? It adds a complexity to the service = provider and for not so much reasons. Should be up to the SP what to = store and how to interpritate the clients requests. We even state in the next section "Since the server is free to
   alter and/or ignore POSTed content". I propose to = remove that capability for the = client.

The = change is intended to be minor. Rather than trying to infer meaning of a = missing value we instead go back to what the client is trying to = express.

=46rom what I could figure out from = the comments was that there are times when a server will =93default=94 = unasserted values (e.g. provide a default set of roles).  In the = case where the client wants to have no roles, the client can simply = include =93roles=94:[] to indicate no roles should be assigned.  If = the client includes no value, the logic is the same as = before.


---------

3.3.1.  Replacing with PUT

Current:
"to = correlate the client's and Provider's views of the updated = resource"
To:
"to = correlate the Client's and Service Provider's views of the updated = resource=94

agreed
<= blockquote type=3D"cite">

---------

3.3.2.  Modifying with PATCH

Current:
"If = a request fails. the server SHALL"
To:
"If = a request fails, the server SHALL"
Comment:
Comma= instead of period.

agreed
----------

3.4.  Deleting Resources

Current: "operations associated with the previously deleted = Id"
To: "operations associated with the previously deleted id"
Comment: Capital I in Id.

check
-------------

3.5.  Bulk

Current: 
"version  The current resource = version.  Version is REQUIRED if the
         service provider supports ETags = and the method is PUT, DELETE,
         or PATCH."

To:
"version  The current resource = version."

Is this meant to be an = ETag?  Why not use etag?
Comment:
In "3.12.  Versioning Resources" we now state that client MAY = send it in PUT and PATCH (not DELETE, we just delete the resource)

We should also remove the version attribute in the DELETE requests = in the bulk jobs. Example:

Current:
       {
         "method":"DELETE",
        =  "path":"/Users/e9025315-6bea-44e1-899c-1e07454e468b",
        =  "version":"W\/\"0ee8add0a938e1a\""
       }
     ]
   }

To:
       {
         "method":"DELETE",
        =  "path":"/Users/e9025315-6bea-44e1-899c-1e07454e468b"
       }
     ]
   }

----------

3.7.  Additional Operation Response Parameters

Comment: It feels like we usually talk about MUST attributes in the = core schema, this is more generic, but a bit fuzzier. Can we say = both?

--------------------

3.7.  Additional Operation Response Parameters

Current: 
"The = defaut attribute set are those attributes whose schema have "returned" = set to "default"."
To:
"The = default attribute set are those attributes whose schema have "returned" = set to "default"."

not sure what the = differnence is
------------

3.9.  "/Me" Authenticated Subject Alias

Current:
"A = client MAY use a URL of the form "<server-root>/Me" as an URL = alias"
Comment:
Shoudn't it be "<base-url>/Me"? = We have a /Me interface, but it's not hosted on the = server-root.

If SCIM = defines this it has to be within the SCIM server=92s endpoint.  I = wanted to say the root because I want to avoid tying it to =93Users=94. = =93/Me=94 might map back to /Clients/{id}  (e.g. an oauth = client)..


-------------   
   

Authors' Addresses

From:

   Erik Wahlstroem
   Technology Nexus


To:

   Erik Wahlstroem
   Nexus Technology

Comment:
New = legal name, and new email = address.

ok

=97=97=97=97=97=97=97=97=97


/ Erik


On 15 Jul 2014, at 17:29, Ian Glazer <iglazer@salesforce.com> = wrote:

Here's a few more comments:

3.4 Delete - Does an SP who chooses not to permanently delete a = resource have to tell the client of that choice?

3.4 Delete conflicts - "SP MUST not consider deleted resource in = conflict calculation" -  What about situations where the SP = requires all userNames to be unique and holds delete accounts to ensure = no repetition of userNames? This might cause a problem for Salesforce.

3.5 Bulk - Maybe my memory failed me here but I thought we were = carving Bulk out as its own profile to be dealt with later. Given that = no one has implemented it I wonder if it doesn't make sense to = completely pull it and put it into a future profile.

3.5 Bulk - formatting issue - Page 38 of the pdf. The paragraph = beginning "The following example shows how to add..." is formatted like = example code not regular text.

3.5 Bulk - formatting issue - Page 40 of the pdf. The paragraph = beginning "The following response is returned if an error occurred..." = is formatted like example code not regular text.

3.5 Bulk - formatting issue - same problems on pages 41 and 42 as = 38 and 40.

3.7 attributes - If "attributes" are specified, it isn't clear if = default attributes are also returned along with the minimum set and = those specified. I think this needs to say explicitly that default = attributes are not returned when "attributes" are specified.

6.4 - Universal Identifiers - ?


--
Ian Glazer
Senior Director, Identity
+1 202 255 3166
_______________________________________________
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=_C17CACD1-BEA6-4948-9888-EA22F739148A-- From nobody Mon Jul 21 14:34:08 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77381A063E for ; Mon, 21 Jul 2014 14:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVeCSFWU-Kfy for ; Mon, 21 Jul 2014 14:34:04 -0700 (PDT) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2156C1A063C for ; Mon, 21 Jul 2014 14:34:03 -0700 (PDT) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 21 Jul 2014 23:33:42 +0200 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0847.030; Mon, 21 Jul 2014 23:33:24 +0200 From: =?Windows-1252?Q?Erik_Wahlstr=F6m?= To: Phil Hunt Thread-Topic: [scim] Comments for sections 3.4 to the end Thread-Index: AQHPoEHffZEGnh4ka0yB2U7n5xtwPJuq3kqAgAAOAQCAAAh4gA== Date: Mon, 21 Jul 2014 21:33:23 +0000 Message-ID: References: <009DE5E3-D0C2-45FC-AB88-BE80FE3BF86A@nexusgroup.com> In-Reply-To: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [94.234.170.213] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/qzHgGpNbqXCinrXxG7N9Mcm2wbA Cc: "scim@ietf.org WG" , Ian Glazer Subject: Re: [scim] Comments for sections 3.4 to the end X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 21:34:06 -0000 Hi Phil, >> - The ResourceType is messy. Merge it with a resource instead?=20 >>=20 > Can you make some suggestions? Ok. I=92ll have a look at it. Just something to make the differentiation in= between Schema/Resource/Resouce type and endpoint extra super clear. >>=20 >> "Clients that would like to override a >> server defaults, MAY specify "null" for a single-valued attribute or >> an empty array "[]" for a multi-valued attribute to clear all values.= " >> Comment: >> Why do we have something like this? It adds a complexity to the service = provider and for not so much reasons. Should be up to the SP what to store = and how to interpritate the clients requests. We even state in the next sec= tion "Since the server is free to >> alter and/or ignore POSTed content". I propose to remove that capabil= ity for the client. >=20 > The change is intended to be minor. Rather than trying to infer meaning o= f a missing value we instead go back to what the client is trying to expres= s. >=20 > From what I could figure out from the comments was that there are times w= hen a server will =93default=94 unasserted values (e.g. provide a default s= et of roles). In the case where the client wants to have no roles, the cli= ent can simply include =93roles=94:[] to indicate no roles should be assign= ed. If the client includes no value, the logic is the same as before. Ok. I understand the requirement now. Works for me. >>=20 >> Current:=20 >> "version The current resource version. Version is REQUIRED if the >> service provider supports ETags and the method is PUT, DELETE, >> or PATCH." >>=20 >> To: >> "version The current resource version." >>=20 > Is this meant to be an ETag? Why not use stag? Yes, it=92s an ETag. The reason it was named version instead of ETag is tha= t ETag is so bound i HTTP. And it could be sent through any potential trans= port protocol in the future (SAML, XMPP=85). version is a bit more generic= and future proof. >>=20 >> Current:=20 >> "The defaut attribute set are those attributes whose schema have "return= ed" set to "default"." >> To: >> "The default attribute set are those attributes whose schema have "retur= ned" set to "default"." >>=20 > not sure what the difference is =93defaut=94 is missing an L :) Cheers Erik From nobody Mon Jul 21 14:38:47 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9CF91A0A40 for ; Mon, 21 Jul 2014 14:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYRSne-WJGYB for ; Mon, 21 Jul 2014 14:38:38 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D76251A063C for ; Mon, 21 Jul 2014 14:38:37 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) with Microsoft SMTP Server (TLS) id 15.0.990.7; Mon, 21 Jul 2014 21:38:35 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.122]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.122]) with mapi id 15.00.0990.007; Mon, 21 Jul 2014 21:38:35 +0000 From: Kelly Grizzle To: Phil Hunt , Ian Glazer Thread-Topic: [scim] Comments so sections 1 through 3.3 Thread-Index: AQHPn42FUyoMTdZmXkS/lketPGZbfZuk86QAgAT7xPA= Date: Mon, 21 Jul 2014 21:38:33 +0000 Message-ID: <33cc8bfea8454705b6788e5c7eedcd2f@BN1PR04MB392.namprd04.prod.outlook.com> References: <3ADF1D27-C771-4645-814E-324D51353674@oracle.com> In-Reply-To: <3ADF1D27-C771-4645-814E-324D51353674@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 0765DEC1007AF20765E00E x-originating-ip: [97.79.140.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0279B3DD0D x-forefront-antispam-report: SFV:NSPM; SFS:(51704005)(51914003)(24454002)(377454003)(189002)(199002)(76576001)(86362001)(20776003)(31966008)(19300405004)(64706001)(2656002)(99396002)(87936001)(66066001)(85852003)(79102001)(15975445006)(92566001)(19617315012)(83072002)(80022001)(85306003)(16236675004)(33646002)(16601075003)(83322001)(105586002)(81542001)(77982001)(77096002)(19580405001)(76176999)(106116001)(15202345003)(50986999)(95666004)(54356999)(107046002)(74316001)(81342001)(19625215002)(19580395003)(101416001)(106356001)(74662001)(21056001)(76482001)(4396001)(74502001)(46102001)(19609705001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB392; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_33cc8bfea8454705b6788e5c7eedcd2fBN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/vLwnccIh4wfTEingCchRzBNNToU Cc: "scim@ietf.org WG" Subject: Re: [scim] Comments so sections 1 through 3.3 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 21:38:45 -0000 --_000_33cc8bfea8454705b6788e5c7eedcd2fBN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > > 3. PUT - The draft reads "PUT SHOULD NOT be used to create new resource= s." Should that SHOULD actually be a MUST? > > I'm open to some discussion here. I'm not sure if there are limited scena= rios whereby the implementation has to allow this. I don't know of any. I'd be in favor of changing this to a MUST. From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Thursday, July 17, 2014 4:47 PM To: Ian Glazer Cc: scim@ietf.org WG Subject: Re: [scim] Comments so sections 1 through 3.3 Ian, Thanks for the thorough walk through. Comments in line below. Thanks for the feedback. Many of these are obvious and will plan to put the= m in the document following Toronto (unless I hear objections). Others I wi= ll add to the list of discussion items for Toronto. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 14, 2014, at 11:00 AM, Ian Glazer > wrote: Here are my early comments on the above sections. I'll grind through more o= f this a bit later. 1.1 - "identity service providers and client" - This is a little confusing.= Do we mean identity providers and consumers? providers of identity service= s and organizations that consume those services? How about just "web service providers and clients". The fact that it is a = protocol around identity isn't near as important as that it is an HTTP prot= ocol. 1.3 - URL versus URI - There might be a bit of a inconsistency here. Will Fix. I think the issue here is that it must be a URL (accessible via H= TTP) but IETF seems to always want URIs regardless. 2. - The section is titled "Authentication and Authorization" but authoriza= tion isn't directly addressed. The sentence "Appropriate security considera= tions of the selected authentication and authorization schemes SHOULD be ta= ken" isn't actionable - it is a motherhood and apple pie statement. Do we w= ant to specifically mention scopes as an authorization mechanism? Do we jus= t want to cut "Authorization" from the section header? I have already attempted to create a better way of describing this: Because SCIM uses HTTP protocol, it does not define a scheme for authentication and authorization. It depends on standard HTTP authentication schemes. It is RECOMMENDED that clients be implemented in such a way that new authentication schemes can be deployed. Implementers SHOULD support existing authentication/ authorization schemes. In particular, OAuth2 [RFC6750] is RECOMMENDED. Appropriate security considerations of the selected authentication and authorization schemes SHOULD be taken. Because this protocol uses HTTP response status codes as the primary means of reporting the result of a request, servers are advised to respond to unauthorized or unauthenticated requests using the 401 response code in accordance with Section 3.1 of [RFC7235]. All examples show an OAuth2 bearer token [RFC6750] (thought it is not required) ; e.g., GET /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1 Host: example.com Authorization: Bearer h480djs93hd8 The context of the request (i.e. the user for whom data is being requested) MUST be inferred by service providers. That said, do we want to get into a standardized authorization model? Mayb= e this is something as a future draft specification. Particularly if we wan= t to talk about a future SCIM Directory specification. 3. API - Did we decided whether SCIM is an API or a protocol? For consisten= cy-sake, the title of this section and the first sentence may need to chang= e accordingly. Per my previous email. I've had some recommendation that API always refers = to a programming library interface rather than over the wire semantics. Thu= s I have begun changing to the SCIM protocol or SCIM HTTP protocol where ap= propriate. Note we need to discuss the issue of renaming the SCIM API draft to SCIM Pr= otocol draft. 3. POST - "or bulk modify resources" - Bulk? I thought that bulk was off th= e table for this draft? There was some discussion on one of the calls (I can't remember if we follo= wed up on the list). The feeling was that many are beginning to implement n= ow. We'd like to keep it in place for now but we agreed it may not make the= final cut. This should be a discussion item for Toronto. 3. PUT - The draft reads "PUT SHOULD NOT be used to create new resources." = Should that SHOULD actually be a MUST? I'm open to some discussion here. I'm not sure if there are limited scenari= os whereby the implementation has to allow this. 3. API Table - minor nit - only some of the sections are properly linked in= the PDF Ok. Weird. Will take a look. Seems like an xml2rfc issue (the xml reference= s the same way for each item). 3. API Table - /Bulk - I thought we weren't dealing with Bulk for v2 and we= re going to handle it via profile later See above 3.1 - "Successful resource creation..." - It is unclear from the second sen= tence whether the entire object MUST be returned or can the server simply r= eturn back a pointer to the newly created object? Assume you are referring to: Upon successful creation, the response body MUST contain the newly created resource. Maybe it should say "the newly created service provider representation of t= he full resource"? 3.1 - Is the server required to return a Location header when a resource is= successfully created? Text does not make that clear. Agreed it should say this. 3.1.1. - Just a clarification - "SHALL be set by the service provider" - in= this case service provider means SCIM server and not the client, is that c= orrect? In all cases "service provider" means the HTTP service, not the provider of= identity data (the client). Maybe we need more terminology text in the int= ro on this point. 3.2 Consistency question - Query or Search? Agreed. Any preferences? 3.2.2 Consistency question - it appears that this draft refers to "service = providers," "Providers," and "servers" - does this need to be cleaned up an= d made consistent? Agreed see above. 3.2.2.1 - Do we really want to allow a search against the server root that = would result is all objects being returned? Seems like we ought to endorse = a pattern of querying resourceTypes and then a specific resourceType is a b= etter way to go. This is regulated by the max results limits. There was a specific example o= f being able to search without regard to resource type, or a specific set o= f resource types. The use case was a search-as-user-types scenario where th= e result was not known to be a user or a group. 3.2.2.2 - What happens if someone includes a "ge" search against a non-nume= ric or non-date type field? The next isn't clear about a failure condition. Maybe you mis-read. If anything, I see it doesn't say how numeric compariso= ns are made. For strings it is the normal lexicographical comparison. 3.2.2.3 - Primary attributed - it isn't clear from the text what a primary = attribute is. Will add a reference to the multi-valued attribute definition where primary= is defined. 3.2.2.5 - Meta-question - how does a SCIM server indicate whether it suppor= ts attributes and excludedAttributes to be returned (or not) for a Query? Not sure what you mean. There's no optionality here. 3.2.3 - Figure 2 - the example doesn't use a meta.resourceType attribute wh= ich I think it should to indicate a best practice. Sure. Why not. Might be a good way to say how to search both users and gro= ups. 3.3.1 - HTTP PUT "SHOULD NOT" or "MUST NOT" be used to create new resources= ? See above. 3.3.1 - "If an attribute is required..." - What if the attribute's value is= n't going to change? Does it still need to be sent along? Yes. Since it is a replace, but value must always be supplied - even when n= o change. Otherwise it makes missing value logic even more complex. :-) 3.3.1 - "Attributes whose mutability is 'readWrite.' This paragraph seem ve= ry squishy. The server is afforded a lot of latitude which the client may n= ot be aware of. Should be more prescriptive? Attributes that are omitted ar= e not changed? The problem here was the issue I raised earlier about understanding the imp= lied meaning of a missing value: * omitted because client isn't aware of it * omitted because the client does not intend to change it * omitted because the client wants to default it * omitted because the client wants to delete it * omitted because the client doesn't care The squishiness was a result of trying to give the server some room to inte= rpret. This probably still needs more discussion. 3.3.2.1 - I'd move the paragraph before the example up before the list of p= ossible outcomes. ok 3.3.2.2 - I get what happens here but there could be confusion as to whethe= r Remove sets a value to "null" or not. Is removing an attribute equivalent= to nulling it? I think we've informally discussed that for scim, null =3D=3D removed. We s= hould discuss this in Toronto and formalize this in the spec. Having null = equal to removed makes the missing/omitted attribute logic on PUT etc easie= r to define. 3.3.2.2 - What about mutability? If I attempt to remove a readOnly, can I? = What about "required" attributes? Good point. 3.3.2.3 - What about mutability? Agreed. -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_33cc8bfea8454705b6788e5c7eedcd2fBN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> > 3. PUT - The draft reads "PUT SHOULD NOT be used to create new = resources." Should that SHOULD actually be a MUST?

> 

> I’m open to some discussion here. I’= ;m not sure if there are limited scenarios whereby the implementation has t= o allow this.

I don’t know of any= .  I’d be in favor of changing this to a MUST.=

 <= /p>

From: scim [ma= ilto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, July 17, 2014 4:47 PM
To: Ian Glazer
Cc: scim@ietf.org WG
Subject: Re: [scim] Comments so sections 1 through 3.3

 

Ian,

 

Thanks for the thorough walk through.

 

Comments in line below.

 

Thanks for the feedback. Many of these are obvious a= nd will plan to put them in the document following Toronto (unless I hear o= bjections). Others I will add to the list of discussion items for Toronto.<= o:p>

 

Phil

 

@independentid<= /span>

ph= il.hunt@oracle.com

 

 

 

On Jul 14, 2014, at 11:00 AM, Ian Glazer <iglazer@salesforce.com> wrote:



Here are my early comments on the above sections. I'= ll grind through more of this a bit later.

 

1.1 - "identity service providers and client&qu= ot; - This is a little confusing. Do we mean identity providers and consume= rs? providers of identity services and organizations that consume those ser= vices?

 

How about just “web service providers and clie= nts”.  The fact that it is a protocol around identity isn’= t near as important as that it is an HTTP protocol.

 

1.3 - URL versus URI - There might be a bit of a inc= onsistency here.

 

Will Fix. I think the issue here is that it must be = a URL (accessible via HTTP) but IETF seems to always want URIs regardless. =  

 

2. - The section is titled "Authentication and = Authorization" but authorization isn't directly addressed. The sentenc= e "Appropriate security considerations of the selected authentication = and authorization schemes SHOULD be taken" isn't actionable - it is a motherhood and apple pie statement. Do we want to spe= cifically mention scopes as an authorization mechanism? Do we just want to = cut "Authorization" from the section header?

 

I have already attempted to create a better way of d= escribing this:

   Beca=
use SCIM uses HTTP protocol, it does not define a scheme for

   authentication and authorization.  It depends on sta=
ndard HTTP


   authentication schemes.  It is RECOMMENDED that clie=
nts be


   implemented in such a way that new authentication schemes=
 can be


   deployed.  Implementers SHOULD support existing auth=
entication/


   authorization schemes.  In particular, OAuth2 [RFC67=
50] is


   RECOMMENDED.  Appropriate security considerations of=
 the selected


   authentication and authorization schemes SHOULD be taken.=
  Because


   this protocol uses HTTP response status codes as the prim=
ary means of


   reporting the result of a request, servers are advised to=
 respond to


   unauthorized or unauthenticated requests using the 401 re=
sponse code


   in accordance with Section 3.1 of [RFC7235].

 


   All examples show an OAuth2 bearer token [RFC6750] (thoug=
ht it is not


   required) ; e.g.,


 


   GET /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1<=
o:p>


   Host: example.com=



   Authorization: Bearer h480djs93hd8


 


   The context of the request (i.e. the user for whom data i=
s being


   requested) MUST be inferred by service providers.




That said, do we want to get into a standardized aut=
horization model?  Maybe this is something as a future draft specifica=
tion. Particularly if we want to talk about a future SCIM Directory specifi=
cation.






 












 






3. API - Did we decided whether SCIM is an API or a =
protocol? For consistency-sake, the title of this section and the first sen=
tence may need to change accordingly.












 




Per my previous email. I’ve had some recommend=
ation that API always refers to a programming library interface rather than=
 over the wire semantics. Thus I have begun changing to the SCIM protocol o=
r SCIM HTTP protocol where appropriate.

 

Note we need to discuss the issue of renaming the SC= IM API draft to SCIM Protocol draft.

 

3. POST - "or bulk modify resources" - Bul= k? I thought that bulk was off the table for this draft?

 

There was some discussion on one of the calls (I can= ’t remember if we followed up on the list). The feeling was that many= are beginning to implement now. We’d like to keep it in place for no= w but we agreed it may not make the final cut.  This should be a discussion item for Toronto.

 

3. PUT - The draft reads "PUT SHOULD NOT be use= d to create new resources." Should that SHOULD actually be a MUST?

 

I’m open to some discussion here. I’m no= t sure if there are limited scenarios whereby the implementation has to all= ow this.

 

3. API Table - minor nit - only some of the sections= are properly linked in the PDF

 

Ok. Weird. Will take a look. Seems like an xml2rfc i= ssue (the xml references the same way for each item).

 

3. API Table - /Bulk - I thought we weren't dealing = with Bulk for v2 and were going to handle it via profile later

See above

 

3.1 - "Successful resource creation..." - = It is unclear from the second sentence whether the entire object MUST be re= turned or can the server simply return back a pointer to the newly created = object?

Assume you are referring to:

Up=
on successful creation, the response body MUST
&n=
bsp;  contain the newly created resource.

 

Maybe it should say “the newly created service= provider representation of the full resource”?

 

3.1 - Is the server required to return a Location he= ader when a resource is successfully created? Text does not make that clear= .

 

Agreed it should say this.

 

3.1.1. - Just a clarification - "SHALL be set b= y the service provider" - in this case service provider means SCIM ser= ver and not the client, is that correct?

 

In all cases “service provider” means th= e HTTP service, not the provider of identity data (the client). Maybe we ne= ed more terminology text in the intro on this point.

 

3.2 Consistency question - Query or Search?

 

Agreed. Any preferences?

 

3.2.2 Consistency question - it appears that this dr= aft refers to "service providers," "Providers," and &qu= ot;servers" - does this need to be cleaned up and made consistent?

 

Agreed see above.

 

3.2.2.1 - Do we really want to allow a search agains= t the server root that would result is all objects being returned? Seems li= ke we ought to endorse a pattern of querying resourceTypes and then a speci= fic resourceType is a better way to go.

 

This is regulated by the max results limits. There w= as a specific example of being able to search without regard to resource ty= pe, or a specific set of resource types. The use case was a search-as-user-= types scenario where the result was not known to be a user or a group.

 

3.2.2.2 - What happens if someone includes a "g= e" search against a non-numeric or non-date type field? The next isn't= clear about a failure condition.

Maybe you mis-read. If anything, I see it doesn̵= 7;t say how numeric comparisons are made. For strings it is the normal lexi= cographical comparison.

 

3.2.2.3 - Primary attributed - it isn't clear from t= he text what a primary attribute is.

 

Will add a reference to the multi-valued attribute d= efinition where primary is defined.

 

3.2.2.5 - Meta-question - how does a SCIM server ind= icate whether it supports attributes and excludedAttributes to be returned = (or not) for a Query?

 

Not sure what you mean. There’s no optionality= here.

 

3.2.3 - Figure 2 - the example doesn't use a meta.re= sourceType attribute which I think it should to indicate a best practice.

 

Sure. Why not.  Might be a good way to say how = to search both users and groups.

 

3.3.1 - HTTP PUT "SHOULD NOT" or "MUS= T NOT" be used to create new resources?

 

See above.

 

3.3.1 - "If an attribute is required..." -= What if the attribute's value isn't going to change? Does it still need to= be sent along?

 

Yes. Since it is a replace, but value must always be= supplied - even when no change. Otherwise it makes missing value logic eve= n more complex. :-)



 

3.3.1 - "Attributes whose mutability is 'readWr= ite.' This paragraph seem very squishy. The server is afforded a lot of lat= itude which the client may not be aware of. Should be more prescriptive? At= tributes that are omitted are not changed?

 

The problem here was the issue I raised earlier abou= t understanding the implied meaning of a missing value:

* omitted because client isn’t aware of it

* omitted because the client does not intend to chan= ge it

* omitted because the client wants to default it

* omitted because the client wants to delete it=

* omitted because the client doesn’t care=

 

The squishiness was a result of trying to give the s= erver some room to interpret.

 

This probably still needs more discussion.

 

3.3.2.1 - I'd move the paragraph before the example = up before the list of possible outcomes.

ok

 

3.3.2.2 - I get what happens here but there could be= confusion as to whether Remove sets a value to "null" or not. Is= removing an attribute equivalent to nulling it?

 

I think we’ve informally discussed that for sc= im, null =3D=3D removed. We should discuss this in Toronto and formalize th= is in the spec.  Having null equal to removed makes the missing/omitte= d attribute logic on PUT etc easier to define.

 

3.3.2.2 - What about mutability? If I attempt to rem= ove a readOnly, can I? What about "required" attributes?

 

Good point.

 

3.3.2.3 - What about mutability?

 

Agreed.

 

 

--

Ian Glazer

Senior Director, Identity

+1 202 255 3166

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

 

--_000_33cc8bfea8454705b6788e5c7eedcd2fBN1PR04MB392namprd04pro_-- From nobody Mon Jul 21 14:39:05 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBC51A0A87 for ; Mon, 21 Jul 2014 14:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iz5c-jzGgrTh for ; Mon, 21 Jul 2014 14:38:49 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DC671A0A74 for ; Mon, 21 Jul 2014 14:38:49 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB391.namprd04.prod.outlook.com (10.141.60.150) with Microsoft SMTP Server (TLS) id 15.0.990.7; Mon, 21 Jul 2014 21:38:48 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.122]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.122]) with mapi id 15.00.0990.007; Mon, 21 Jul 2014 21:38:48 +0000 From: Kelly Grizzle To: Ian Glazer , Phil Hunt Thread-Topic: [scim] Comments so sections 1 through 3.3 Thread-Index: AQHPn42FUyoMTdZmXkS/lketPGZbfZuk86QAgALLzACAAjEu0A== Date: Mon, 21 Jul 2014 21:38:47 +0000 Message-ID: <40dbce70636e45dc89d7edf4507a9aba@BN1PR04MB392.namprd04.prod.outlook.com> References: <3ADF1D27-C771-4645-814E-324D51353674@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 0765B418007AF20765B565 x-originating-ip: [97.79.140.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0279B3DD0D x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(24454002)(51704005)(52604005)(377454003)(51914003)(46102001)(105586002)(54356999)(95666004)(77982001)(87936001)(85852003)(76176999)(83072002)(21056001)(101416001)(81342001)(92566001)(76482001)(106116001)(85306003)(20776003)(64706001)(77096002)(106356001)(19617315012)(74662001)(74502001)(80022001)(66066001)(81542001)(31966008)(99396002)(33646002)(74316001)(86362001)(4396001)(16236675004)(19609705001)(15202345003)(79102001)(107046002)(15975445006)(16601075003)(19300405004)(19580395003)(76576001)(83322001)(19580405001)(19625215002)(2656002)(50986999)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB391; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_40dbce70636e45dc89d7edf4507a9abaBN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Ylp2c3yREpd-ilQ486BJVAsPDqY Cc: "scim@ietf.org WG" Subject: Re: [scim] Comments so sections 1 through 3.3 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 21:38:53 -0000 --_000_40dbce70636e45dc89d7edf4507a9abaBN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiAzLjEgLSAiU3VjY2Vzc2Z1bCByZXNvdXJjZSBjcmVhdGlvbi4uLiIgLSBJdCBpcyB1bmNsZWFy IGZyb20gdGhlIHNlY29uZCBzZW50ZW5jZSB3aGV0aGVyIHRoZSBlbnRpcmUgb2JqZWN0IE1VU1QN Cj4gYmUgcmV0dXJuZWQgb3IgY2FuIHRoZSBzZXJ2ZXIgc2ltcGx5IHJldHVybiBiYWNrIGEgcG9p bnRlciB0byB0aGUgbmV3bHkgY3JlYXRlZCBvYmplY3Q/DQo+IEFzc3VtZSB5b3UgYXJlIHJlZmVy cmluZyB0bzoNCg0KPiBVcG9uIHN1Y2Nlc3NmdWwgY3JlYXRpb24sIHRoZSByZXNwb25zZSBib2R5 IE1VU1QNCg0KPiAgIGNvbnRhaW4gdGhlIG5ld2x5IGNyZWF0ZWQgcmVzb3VyY2UuDQo+DQo+IE1h eWJlIGl0IHNob3VsZCBzYXkg4oCcdGhlIG5ld2x5IGNyZWF0ZWQgc2VydmljZSBwcm92aWRlciBy ZXByZXNlbnRhdGlvbiBvZiB0aGUgZnVsbCByZXNvdXJjZeKAnT8NCj4NCj4gVGhhdCBkb2Vzbid0 IGFkZHJlc3MgbXkgcG9vcmx5IG1hZGUgcG9pbnQuLi4gV2hhdCBJIGFtIHRyeWluZyB0byBhc2sg aXM6IGRvZXMgaXQgbWFrZSBzZW5zZSB0byBhbHdheXMgaGFuZCBiYWNrDQo+IHRoZSBuZXcgY29t cGxldGUgb2JqZWN0PyBXb3VsZCBpdCBiZSBtb3JlIGVmZmljaWVudCB0byBzaW1wbHkgaGFuZCBi YWNrIGEgcG9pbnQgdG8gdGhlIHJlc291cmNlIGluc3RlYWQ/DQoNCkkgc2VlIHlvdXIgcG9pbnQs IGJ1dCBkb27igJl0IHRoaW5rIHRoaXMgd2lsbCBiZSBhIGJpZyBjb25jZXJuIGZyb20gYW4gZWZm aWNpZW5jeSBwZXJzcGVjdGl2ZSAobWF5YmUgb24gbW9iaWxlIHdoZXJlIGJhbmR3aWR0aCByZWFs bHkgY291bnRzPykuICBJTU8gdGhlIGZ1bGwgcmVwcmVzZW50YXRpb24gaXMgcHJldHR5IHVzZWZ1 bC4gIEkgd291bGQgYmUgaW5jbGluZWQgdG8ga2VlcCB0aGUgTVVTVCBmb3Igbm93IHVubGVzcyB3 ZSBnZXQgY29tcGxhaW50cy4NCg0KDQoNCkZyb206IHNjaW0gW21haWx0bzpzY2ltLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBJYW4gR2xhemVyDQpTZW50OiBTYXR1cmRheSwgSnVseSAx OSwgMjAxNCAxMToyOSBBTQ0KVG86IFBoaWwgSHVudA0KQ2M6IHNjaW1AaWV0Zi5vcmcgV0cNClN1 YmplY3Q6IFJlOiBbc2NpbV0gQ29tbWVudHMgc28gc2VjdGlvbnMgMSB0aHJvdWdoIDMuMw0KDQpU aGFua3MgZm9yIGdvaW5nIHRocm91Z2ggdGhlc2UgUGhpbC4gQ29tbWVudHMgYmVsb3cNCg0KT24g VGh1LCBKdWwgMTcsIDIwMTQgYXQgNDo0NiBQTSwgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xl LmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCklhbiwNCg0KVGhhbmtz IGZvciB0aGUgdGhvcm91Z2ggd2FsayB0aHJvdWdoLg0KDQpDb21tZW50cyBpbiBsaW5lIGJlbG93 Lg0KDQpUaGFua3MgZm9yIHRoZSBmZWVkYmFjay4gTWFueSBvZiB0aGVzZSBhcmUgb2J2aW91cyBh bmQgd2lsbCBwbGFuIHRvIHB1dCB0aGVtIGluIHRoZSBkb2N1bWVudCBmb2xsb3dpbmcgVG9yb250 byAodW5sZXNzIEkgaGVhciBvYmplY3Rpb25zKS4gT3RoZXJzIEkgd2lsbCBhZGQgdG8gdGhlIGxp c3Qgb2YgZGlzY3Vzc2lvbiBpdGVtcyBmb3IgVG9yb250by4NCg0KUGhpbA0KDQpAaW5kZXBlbmRl bnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20+ DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCg0K DQpPbiBKdWwgMTQsIDIwMTQsIGF0IDExOjAwIEFNLCBJYW4gR2xhemVyIDxpZ2xhemVyQHNhbGVz Zm9yY2UuY29tPG1haWx0bzppZ2xhemVyQHNhbGVzZm9yY2UuY29tPj4gd3JvdGU6DQoNCg0KSGVy ZSBhcmUgbXkgZWFybHkgY29tbWVudHMgb24gdGhlIGFib3ZlIHNlY3Rpb25zLiBJJ2xsIGdyaW5k IHRocm91Z2ggbW9yZSBvZiB0aGlzIGEgYml0IGxhdGVyLg0KDQoxLjEgLSAiaWRlbnRpdHkgc2Vy dmljZSBwcm92aWRlcnMgYW5kIGNsaWVudCIgLSBUaGlzIGlzIGEgbGl0dGxlIGNvbmZ1c2luZy4g RG8gd2UgbWVhbiBpZGVudGl0eSBwcm92aWRlcnMgYW5kIGNvbnN1bWVycz8gcHJvdmlkZXJzIG9m IGlkZW50aXR5IHNlcnZpY2VzIGFuZCBvcmdhbml6YXRpb25zIHRoYXQgY29uc3VtZSB0aG9zZSBz ZXJ2aWNlcz8NCg0KSG93IGFib3V0IGp1c3Qg4oCcd2ViIHNlcnZpY2UgcHJvdmlkZXJzIGFuZCBj bGllbnRz4oCdLiAgVGhlIGZhY3QgdGhhdCBpdCBpcyBhIHByb3RvY29sIGFyb3VuZCBpZGVudGl0 eSBpc27igJl0IG5lYXIgYXMgaW1wb3J0YW50IGFzIHRoYXQgaXQgaXMgYW4gSFRUUCBwcm90b2Nv bC4NCg0KV29ya3MgZm9yIG1lDQoNCjEuMyAtIFVSTCB2ZXJzdXMgVVJJIC0gVGhlcmUgbWlnaHQg YmUgYSBiaXQgb2YgYSBpbmNvbnNpc3RlbmN5IGhlcmUuDQoNCldpbGwgRml4LiBJIHRoaW5rIHRo ZSBpc3N1ZSBoZXJlIGlzIHRoYXQgaXQgbXVzdCBiZSBhIFVSTCAoYWNjZXNzaWJsZSB2aWEgSFRU UCkgYnV0IElFVEYgc2VlbXMgdG8gYWx3YXlzIHdhbnQgVVJJcyByZWdhcmRsZXNzLg0KDQoNCg0K Mi4gLSBUaGUgc2VjdGlvbiBpcyB0aXRsZWQgIkF1dGhlbnRpY2F0aW9uIGFuZCBBdXRob3JpemF0 aW9uIiBidXQgYXV0aG9yaXphdGlvbiBpc24ndCBkaXJlY3RseSBhZGRyZXNzZWQuIFRoZSBzZW50 ZW5jZSAiQXBwcm9wcmlhdGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgb2YgdGhlIHNlbGVjdGVk IGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHNjaGVtZXMgU0hPVUxEIGJlIHRha2Vu IiBpc24ndCBhY3Rpb25hYmxlIC0gaXQgaXMgYSBtb3RoZXJob29kIGFuZCBhcHBsZSBwaWUgc3Rh dGVtZW50LiBEbyB3ZSB3YW50IHRvIHNwZWNpZmljYWxseSBtZW50aW9uIHNjb3BlcyBhcyBhbiBh dXRob3JpemF0aW9uIG1lY2hhbmlzbT8gRG8gd2UganVzdCB3YW50IHRvIGN1dCAiQXV0aG9yaXph dGlvbiIgZnJvbSB0aGUgc2VjdGlvbiBoZWFkZXI/DQoNCkkgaGF2ZSBhbHJlYWR5IGF0dGVtcHRl ZCB0byBjcmVhdGUgYSBiZXR0ZXIgd2F5IG9mIGRlc2NyaWJpbmcgdGhpczoNCg0KICAgQmVjYXVz ZSBTQ0lNIHVzZXMgSFRUUCBwcm90b2NvbCwgaXQgZG9lcyBub3QgZGVmaW5lIGEgc2NoZW1lIGZv cg0KDQogICBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbi4gIEl0IGRlcGVuZHMgb24g c3RhbmRhcmQgSFRUUA0KDQogICBhdXRoZW50aWNhdGlvbiBzY2hlbWVzLiAgSXQgaXMgUkVDT01N RU5ERUQgdGhhdCBjbGllbnRzIGJlDQoNCiAgIGltcGxlbWVudGVkIGluIHN1Y2ggYSB3YXkgdGhh dCBuZXcgYXV0aGVudGljYXRpb24gc2NoZW1lcyBjYW4gYmUNCg0KICAgZGVwbG95ZWQuICBJbXBs ZW1lbnRlcnMgU0hPVUxEIHN1cHBvcnQgZXhpc3RpbmcgYXV0aGVudGljYXRpb24vDQoNCiAgIGF1 dGhvcml6YXRpb24gc2NoZW1lcy4gIEluIHBhcnRpY3VsYXIsIE9BdXRoMiBbUkZDNjc1MF0gaXMN Cg0KICAgUkVDT01NRU5ERUQuICBBcHByb3ByaWF0ZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBv ZiB0aGUgc2VsZWN0ZWQNCg0KICAgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gc2No ZW1lcyBTSE9VTEQgYmUgdGFrZW4uICBCZWNhdXNlDQoNCiAgIHRoaXMgcHJvdG9jb2wgdXNlcyBI VFRQIHJlc3BvbnNlIHN0YXR1cyBjb2RlcyBhcyB0aGUgcHJpbWFyeSBtZWFucyBvZg0KDQogICBy ZXBvcnRpbmcgdGhlIHJlc3VsdCBvZiBhIHJlcXVlc3QsIHNlcnZlcnMgYXJlIGFkdmlzZWQgdG8g cmVzcG9uZCB0bw0KDQogICB1bmF1dGhvcml6ZWQgb3IgdW5hdXRoZW50aWNhdGVkIHJlcXVlc3Rz IHVzaW5nIHRoZSA0MDEgcmVzcG9uc2UgY29kZQ0KDQogICBpbiBhY2NvcmRhbmNlIHdpdGggU2Vj dGlvbiAzLjEgb2YgW1JGQzcyMzVdLg0KDQoNCg0KICAgQWxsIGV4YW1wbGVzIHNob3cgYW4gT0F1 dGgyIGJlYXJlciB0b2tlbiBbUkZDNjc1MF0gKHRob3VnaHQgaXQgaXMgbm90DQoNCiAgIHJlcXVp cmVkKSA7IGUuZy4sDQoNCg0KDQogICBHRVQgL1VzZXJzLzI4MTljMjIzLTdmNzYtNDUzYS05MTlk LTQxMzg2MTkwNDY0NiBIVFRQLzEuMQ0KDQogICBIb3N0OiBleGFtcGxlLmNvbTxodHRwOi8vZXhh bXBsZS5jb20+DQoNCiAgIEF1dGhvcml6YXRpb246IEJlYXJlciBoNDgwZGpzOTNoZDgNCg0KDQoN CiAgIFRoZSBjb250ZXh0IG9mIHRoZSByZXF1ZXN0IChpLmUuIHRoZSB1c2VyIGZvciB3aG9tIGRh dGEgaXMgYmVpbmcNCg0KICAgcmVxdWVzdGVkKSBNVVNUIGJlIGluZmVycmVkIGJ5IHNlcnZpY2Ug cHJvdmlkZXJzLg0KVGhhdCBzYWlkLCBkbyB3ZSB3YW50IHRvIGdldCBpbnRvIGEgc3RhbmRhcmRp emVkIGF1dGhvcml6YXRpb24gbW9kZWw/ICBNYXliZSB0aGlzIGlzIHNvbWV0aGluZyBhcyBhIGZ1 dHVyZSBkcmFmdCBzcGVjaWZpY2F0aW9uLiBQYXJ0aWN1bGFybHkgaWYgd2Ugd2FudCB0byB0YWxr IGFib3V0IGEgZnV0dXJlIFNDSU0gRGlyZWN0b3J5IHNwZWNpZmljYXRpb24uDQoNCk5vdCBhIGh1 Z2UgZmFuIG9mIG9mIHN0YW5kYXJkaXppbmcgdGhlIGF1dGhaIG1vZGVsIHJpZ2h0IG5vdy4gSSB0 aGluayB0aGVyZSBhcmUgbW9yZSB3b3JtcyBpbiB0aGF0IGNhbiB0aGFuIHdlIHdhbnQgdG8gZGVh bCB3aXRoIHJpZ2h0IG5vdy4NCg0KMy4gQVBJIC0gRGlkIHdlIGRlY2lkZWQgd2hldGhlciBTQ0lN IGlzIGFuIEFQSSBvciBhIHByb3RvY29sPyBGb3IgY29uc2lzdGVuY3ktc2FrZSwgdGhlIHRpdGxl IG9mIHRoaXMgc2VjdGlvbiBhbmQgdGhlIGZpcnN0IHNlbnRlbmNlIG1heSBuZWVkIHRvIGNoYW5n ZSBhY2NvcmRpbmdseS4NCg0KUGVyIG15IHByZXZpb3VzIGVtYWlsLiBJ4oCZdmUgaGFkIHNvbWUg cmVjb21tZW5kYXRpb24gdGhhdCBBUEkgYWx3YXlzIHJlZmVycyB0byBhIHByb2dyYW1taW5nIGxp YnJhcnkgaW50ZXJmYWNlIHJhdGhlciB0aGFuIG92ZXIgdGhlIHdpcmUgc2VtYW50aWNzLiBUaHVz IEkgaGF2ZSBiZWd1biBjaGFuZ2luZyB0byB0aGUgU0NJTSBwcm90b2NvbCBvciBTQ0lNIEhUVFAg cHJvdG9jb2wgd2hlcmUgYXBwcm9wcmlhdGUuDQoNCk5vdGUgd2UgbmVlZCB0byBkaXNjdXNzIHRo ZSBpc3N1ZSBvZiByZW5hbWluZyB0aGUgU0NJTSBBUEkgZHJhZnQgdG8gU0NJTSBQcm90b2NvbCBk cmFmdC4NCg0KDQoNCjMuIFBPU1QgLSAib3IgYnVsayBtb2RpZnkgcmVzb3VyY2VzIiAtIEJ1bGs/ IEkgdGhvdWdodCB0aGF0IGJ1bGsgd2FzIG9mZiB0aGUgdGFibGUgZm9yIHRoaXMgZHJhZnQ/DQoN ClRoZXJlIHdhcyBzb21lIGRpc2N1c3Npb24gb24gb25lIG9mIHRoZSBjYWxscyAoSSBjYW7igJl0 IHJlbWVtYmVyIGlmIHdlIGZvbGxvd2VkIHVwIG9uIHRoZSBsaXN0KS4gVGhlIGZlZWxpbmcgd2Fz IHRoYXQgbWFueSBhcmUgYmVnaW5uaW5nIHRvIGltcGxlbWVudCBub3cuIFdl4oCZZCBsaWtlIHRv IGtlZXAgaXQgaW4gcGxhY2UgZm9yIG5vdyBidXQgd2UgYWdyZWVkIGl0IG1heSBub3QgbWFrZSB0 aGUgZmluYWwgY3V0LiAgVGhpcyBzaG91bGQgYmUgYSBkaXNjdXNzaW9uIGl0ZW0gZm9yIFRvcm9u dG8uDQoNCkknZCBwdXNoIHRvIHJlbW92ZSBpdCBidXQgaXQgaXNuJ3QgYSBkZWFsIGJyZWFrZXIg Zm9yIHVzLg0KDQozLiBQVVQgLSBUaGUgZHJhZnQgcmVhZHMgIlBVVCBTSE9VTEQgTk9UIGJlIHVz ZWQgdG8gY3JlYXRlIG5ldyByZXNvdXJjZXMuIiBTaG91bGQgdGhhdCBTSE9VTEQgYWN0dWFsbHkg YmUgYSBNVVNUPw0KDQpJ4oCZbSBvcGVuIHRvIHNvbWUgZGlzY3Vzc2lvbiBoZXJlLiBJ4oCZbSBu b3Qgc3VyZSBpZiB0aGVyZSBhcmUgbGltaXRlZCBzY2VuYXJpb3Mgd2hlcmVieSB0aGUgaW1wbGVt ZW50YXRpb24gaGFzIHRvIGFsbG93IHRoaXMuDQoNCg0KDQozLiBBUEkgVGFibGUgLSBtaW5vciBu aXQgLSBvbmx5IHNvbWUgb2YgdGhlIHNlY3Rpb25zIGFyZSBwcm9wZXJseSBsaW5rZWQgaW4gdGhl IFBERg0KDQpPay4gV2VpcmQuIFdpbGwgdGFrZSBhIGxvb2suIFNlZW1zIGxpa2UgYW4geG1sMnJm YyBpc3N1ZSAodGhlIHhtbCByZWZlcmVuY2VzIHRoZSBzYW1lIHdheSBmb3IgZWFjaCBpdGVtKS4N Cg0KDQoNCjMuIEFQSSBUYWJsZSAtIC9CdWxrIC0gSSB0aG91Z2h0IHdlIHdlcmVuJ3QgZGVhbGlu ZyB3aXRoIEJ1bGsgZm9yIHYyIGFuZCB3ZXJlIGdvaW5nIHRvIGhhbmRsZSBpdCB2aWEgcHJvZmls ZSBsYXRlcg0KU2VlIGFib3ZlDQoNCg0KDQozLjEgLSAiU3VjY2Vzc2Z1bCByZXNvdXJjZSBjcmVh dGlvbi4uLiIgLSBJdCBpcyB1bmNsZWFyIGZyb20gdGhlIHNlY29uZCBzZW50ZW5jZSB3aGV0aGVy IHRoZSBlbnRpcmUgb2JqZWN0IE1VU1QgYmUgcmV0dXJuZWQgb3IgY2FuIHRoZSBzZXJ2ZXIgc2lt cGx5IHJldHVybiBiYWNrIGEgcG9pbnRlciB0byB0aGUgbmV3bHkgY3JlYXRlZCBvYmplY3Q/DQpB c3N1bWUgeW91IGFyZSByZWZlcnJpbmcgdG86DQoNClVwb24gc3VjY2Vzc2Z1bCBjcmVhdGlvbiwg dGhlIHJlc3BvbnNlIGJvZHkgTVVTVA0KDQogICBjb250YWluIHRoZSBuZXdseSBjcmVhdGVkIHJl c291cmNlLg0KDQpNYXliZSBpdCBzaG91bGQgc2F5IOKAnHRoZSBuZXdseSBjcmVhdGVkIHNlcnZp Y2UgcHJvdmlkZXIgcmVwcmVzZW50YXRpb24gb2YgdGhlIGZ1bGwgcmVzb3VyY2XigJ0/DQoNClRo YXQgZG9lc24ndCBhZGRyZXNzIG15IHBvb3JseSBtYWRlIHBvaW50Li4uIFdoYXQgSSBhbSB0cnlp bmcgdG8gYXNrIGlzOiBkb2VzIGl0IG1ha2Ugc2Vuc2UgdG8gYWx3YXlzIGhhbmQgYmFjayB0aGUg bmV3IGNvbXBsZXRlIG9iamVjdD8gV291bGQgaXQgYmUgbW9yZSBlZmZpY2llbnQgdG8gc2ltcGx5 IGhhbmQgYmFjayBhIHBvaW50IHRvIHRoZSByZXNvdXJjZSBpbnN0ZWFkPw0KMy4xIC0gSXMgdGhl IHNlcnZlciByZXF1aXJlZCB0byByZXR1cm4gYSBMb2NhdGlvbiBoZWFkZXIgd2hlbiBhIHJlc291 cmNlIGlzIHN1Y2Nlc3NmdWxseSBjcmVhdGVkPyBUZXh0IGRvZXMgbm90IG1ha2UgdGhhdCBjbGVh ci4NCg0KQWdyZWVkIGl0IHNob3VsZCBzYXkgdGhpcy4NCg0KDQoNCjMuMS4xLiAtIEp1c3QgYSBj bGFyaWZpY2F0aW9uIC0gIlNIQUxMIGJlIHNldCBieSB0aGUgc2VydmljZSBwcm92aWRlciIgLSBp biB0aGlzIGNhc2Ugc2VydmljZSBwcm92aWRlciBtZWFucyBTQ0lNIHNlcnZlciBhbmQgbm90IHRo ZSBjbGllbnQsIGlzIHRoYXQgY29ycmVjdD8NCg0KSW4gYWxsIGNhc2VzIOKAnHNlcnZpY2UgcHJv dmlkZXLigJ0gbWVhbnMgdGhlIEhUVFAgc2VydmljZSwgbm90IHRoZSBwcm92aWRlciBvZiBpZGVu dGl0eSBkYXRhICh0aGUgY2xpZW50KS4gTWF5YmUgd2UgbmVlZCBtb3JlIHRlcm1pbm9sb2d5IHRl eHQgaW4gdGhlIGludHJvIG9uIHRoaXMgcG9pbnQuDQoNCg0KDQozLjIgQ29uc2lzdGVuY3kgcXVl c3Rpb24gLSBRdWVyeSBvciBTZWFyY2g/DQoNCkFncmVlZC4gQW55IHByZWZlcmVuY2VzPw0KDQpO by4NCg0KMy4yLjIgQ29uc2lzdGVuY3kgcXVlc3Rpb24gLSBpdCBhcHBlYXJzIHRoYXQgdGhpcyBk cmFmdCByZWZlcnMgdG8gInNlcnZpY2UgcHJvdmlkZXJzLCIgIlByb3ZpZGVycywiIGFuZCAic2Vy dmVycyIgLSBkb2VzIHRoaXMgbmVlZCB0byBiZSBjbGVhbmVkIHVwIGFuZCBtYWRlIGNvbnNpc3Rl bnQ/DQoNCkFncmVlZCBzZWUgYWJvdmUuDQoNCg0KDQozLjIuMi4xIC0gRG8gd2UgcmVhbGx5IHdh bnQgdG8gYWxsb3cgYSBzZWFyY2ggYWdhaW5zdCB0aGUgc2VydmVyIHJvb3QgdGhhdCB3b3VsZCBy ZXN1bHQgaXMgYWxsIG9iamVjdHMgYmVpbmcgcmV0dXJuZWQ/IFNlZW1zIGxpa2Ugd2Ugb3VnaHQg dG8gZW5kb3JzZSBhIHBhdHRlcm4gb2YgcXVlcnlpbmcgcmVzb3VyY2VUeXBlcyBhbmQgdGhlbiBh IHNwZWNpZmljIHJlc291cmNlVHlwZSBpcyBhIGJldHRlciB3YXkgdG8gZ28uDQoNClRoaXMgaXMg cmVndWxhdGVkIGJ5IHRoZSBtYXggcmVzdWx0cyBsaW1pdHMuIFRoZXJlIHdhcyBhIHNwZWNpZmlj IGV4YW1wbGUgb2YgYmVpbmcgYWJsZSB0byBzZWFyY2ggd2l0aG91dCByZWdhcmQgdG8gcmVzb3Vy Y2UgdHlwZSwgb3IgYSBzcGVjaWZpYyBzZXQgb2YgcmVzb3VyY2UgdHlwZXMuIFRoZSB1c2UgY2Fz ZSB3YXMgYSBzZWFyY2gtYXMtdXNlci10eXBlcyBzY2VuYXJpbyB3aGVyZSB0aGUgcmVzdWx0IHdh cyBub3Qga25vd24gdG8gYmUgYSB1c2VyIG9yIGEgZ3JvdXAuDQoNCg0KDQozLjIuMi4yIC0gV2hh dCBoYXBwZW5zIGlmIHNvbWVvbmUgaW5jbHVkZXMgYSAiZ2UiIHNlYXJjaCBhZ2FpbnN0IGEgbm9u LW51bWVyaWMgb3Igbm9uLWRhdGUgdHlwZSBmaWVsZD8gVGhlIG5leHQgaXNuJ3QgY2xlYXIgYWJv dXQgYSBmYWlsdXJlIGNvbmRpdGlvbi4NCk1heWJlIHlvdSBtaXMtcmVhZC4gSWYgYW55dGhpbmcs IEkgc2VlIGl0IGRvZXNu4oCZdCBzYXkgaG93IG51bWVyaWMgY29tcGFyaXNvbnMgYXJlIG1hZGUu IEZvciBzdHJpbmdzIGl0IGlzIHRoZSBub3JtYWwgbGV4aWNvZ3JhcGhpY2FsIGNvbXBhcmlzb24u DQoNCg0KDQozLjIuMi4zIC0gUHJpbWFyeSBhdHRyaWJ1dGVkIC0gaXQgaXNuJ3QgY2xlYXIgZnJv bSB0aGUgdGV4dCB3aGF0IGEgcHJpbWFyeSBhdHRyaWJ1dGUgaXMuDQoNCldpbGwgYWRkIGEgcmVm ZXJlbmNlIHRvIHRoZSBtdWx0aS12YWx1ZWQgYXR0cmlidXRlIGRlZmluaXRpb24gd2hlcmUgcHJp bWFyeSBpcyBkZWZpbmVkLg0KDQoNCg0KMy4yLjIuNSAtIE1ldGEtcXVlc3Rpb24gLSBob3cgZG9l cyBhIFNDSU0gc2VydmVyIGluZGljYXRlIHdoZXRoZXIgaXQgc3VwcG9ydHMgYXR0cmlidXRlcyBh bmQgZXhjbHVkZWRBdHRyaWJ1dGVzIHRvIGJlIHJldHVybmVkIChvciBub3QpIGZvciBhIFF1ZXJ5 Pw0KDQpOb3Qgc3VyZSB3aGF0IHlvdSBtZWFuLiBUaGVyZeKAmXMgbm8gb3B0aW9uYWxpdHkgaGVy ZS4NCg0KT2ssIHRoYXQgd2Fzbid0IG9idmlvdXMgZnJvbSB0aGUgdGV4dC4NCg0KMy4yLjMgLSBG aWd1cmUgMiAtIHRoZSBleGFtcGxlIGRvZXNuJ3QgdXNlIGEgbWV0YS5yZXNvdXJjZVR5cGUgYXR0 cmlidXRlIHdoaWNoIEkgdGhpbmsgaXQgc2hvdWxkIHRvIGluZGljYXRlIGEgYmVzdCBwcmFjdGlj ZS4NCg0KU3VyZS4gV2h5IG5vdC4gIE1pZ2h0IGJlIGEgZ29vZCB3YXkgdG8gc2F5IGhvdyB0byBz ZWFyY2ggYm90aCB1c2VycyBhbmQgZ3JvdXBzLg0KDQoNCg0KMy4zLjEgLSBIVFRQIFBVVCAiU0hP VUxEIE5PVCIgb3IgIk1VU1QgTk9UIiBiZSB1c2VkIHRvIGNyZWF0ZSBuZXcgcmVzb3VyY2VzPw0K DQpTZWUgYWJvdmUuDQoNCg0KDQozLjMuMSAtICJJZiBhbiBhdHRyaWJ1dGUgaXMgcmVxdWlyZWQu Li4iIC0gV2hhdCBpZiB0aGUgYXR0cmlidXRlJ3MgdmFsdWUgaXNuJ3QgZ29pbmcgdG8gY2hhbmdl PyBEb2VzIGl0IHN0aWxsIG5lZWQgdG8gYmUgc2VudCBhbG9uZz8NCg0KWWVzLiBTaW5jZSBpdCBp cyBhIHJlcGxhY2UsIGJ1dCB2YWx1ZSBtdXN0IGFsd2F5cyBiZSBzdXBwbGllZCAtIGV2ZW4gd2hl biBubyBjaGFuZ2UuIE90aGVyd2lzZSBpdCBtYWtlcyBtaXNzaW5nIHZhbHVlIGxvZ2ljIGV2ZW4g bW9yZSBjb21wbGV4LiA6LSkNCg0KDQoNCjMuMy4xIC0gIkF0dHJpYnV0ZXMgd2hvc2UgbXV0YWJp bGl0eSBpcyAncmVhZFdyaXRlLicgVGhpcyBwYXJhZ3JhcGggc2VlbSB2ZXJ5IHNxdWlzaHkuIFRo ZSBzZXJ2ZXIgaXMgYWZmb3JkZWQgYSBsb3Qgb2YgbGF0aXR1ZGUgd2hpY2ggdGhlIGNsaWVudCBt YXkgbm90IGJlIGF3YXJlIG9mLiBTaG91bGQgYmUgbW9yZSBwcmVzY3JpcHRpdmU/IEF0dHJpYnV0 ZXMgdGhhdCBhcmUgb21pdHRlZCBhcmUgbm90IGNoYW5nZWQ/DQoNClRoZSBwcm9ibGVtIGhlcmUg d2FzIHRoZSBpc3N1ZSBJIHJhaXNlZCBlYXJsaWVyIGFib3V0IHVuZGVyc3RhbmRpbmcgdGhlIGlt cGxpZWQgbWVhbmluZyBvZiBhIG1pc3NpbmcgdmFsdWU6DQoqIG9taXR0ZWQgYmVjYXVzZSBjbGll bnQgaXNu4oCZdCBhd2FyZSBvZiBpdA0KKiBvbWl0dGVkIGJlY2F1c2UgdGhlIGNsaWVudCBkb2Vz IG5vdCBpbnRlbmQgdG8gY2hhbmdlIGl0DQoqIG9taXR0ZWQgYmVjYXVzZSB0aGUgY2xpZW50IHdh bnRzIHRvIGRlZmF1bHQgaXQNCiogb21pdHRlZCBiZWNhdXNlIHRoZSBjbGllbnQgd2FudHMgdG8g ZGVsZXRlIGl0DQoqIG9taXR0ZWQgYmVjYXVzZSB0aGUgY2xpZW50IGRvZXNu4oCZdCBjYXJlDQoN ClRoZSBzcXVpc2hpbmVzcyB3YXMgYSByZXN1bHQgb2YgdHJ5aW5nIHRvIGdpdmUgdGhlIHNlcnZl ciBzb21lIHJvb20gdG8gaW50ZXJwcmV0Lg0KDQpUaGlzIHByb2JhYmx5IHN0aWxsIG5lZWRzIG1v cmUgZGlzY3Vzc2lvbi4NCg0KDQoNCjMuMy4yLjEgLSBJJ2QgbW92ZSB0aGUgcGFyYWdyYXBoIGJl Zm9yZSB0aGUgZXhhbXBsZSB1cCBiZWZvcmUgdGhlIGxpc3Qgb2YgcG9zc2libGUgb3V0Y29tZXMu DQpvaw0KDQoNCg0KMy4zLjIuMiAtIEkgZ2V0IHdoYXQgaGFwcGVucyBoZXJlIGJ1dCB0aGVyZSBj b3VsZCBiZSBjb25mdXNpb24gYXMgdG8gd2hldGhlciBSZW1vdmUgc2V0cyBhIHZhbHVlIHRvICJu dWxsIiBvciBub3QuIElzIHJlbW92aW5nIGFuIGF0dHJpYnV0ZSBlcXVpdmFsZW50IHRvIG51bGxp bmcgaXQ/DQoNCkkgdGhpbmsgd2XigJl2ZSBpbmZvcm1hbGx5IGRpc2N1c3NlZCB0aGF0IGZvciBz Y2ltLCBudWxsID09IHJlbW92ZWQuIFdlIHNob3VsZCBkaXNjdXNzIHRoaXMgaW4gVG9yb250byBh bmQgZm9ybWFsaXplIHRoaXMgaW4gdGhlIHNwZWMuICBIYXZpbmcgbnVsbCBlcXVhbCB0byByZW1v dmVkIG1ha2VzIHRoZSBtaXNzaW5nL29taXR0ZWQgYXR0cmlidXRlIGxvZ2ljIG9uIFBVVCBldGMg ZWFzaWVyIHRvIGRlZmluZS4NCg0KMy4zLjIuMiAtIFdoYXQgYWJvdXQgbXV0YWJpbGl0eT8gSWYg SSBhdHRlbXB0IHRvIHJlbW92ZSBhIHJlYWRPbmx5LCBjYW4gST8gV2hhdCBhYm91dCAicmVxdWly ZWQiIGF0dHJpYnV0ZXM/DQoNCkdvb2QgcG9pbnQuDQoNCg0KDQozLjMuMi4zIC0gV2hhdCBhYm91 dCBtdXRhYmlsaXR5Pw0KDQpBZ3JlZWQuDQoNCg0KDQotLQ0KSWFuIEdsYXplcg0KU2VuaW9yIERp cmVjdG9yLCBJZGVudGl0eQ0KKzEgMjAyIDI1NSAzMTY2PHRlbDolMkIxJTIwMjAyJTIwMjU1JTIw MzE2Nj4NCkBpZ2xhemVyPGh0dHBzOi8vdHdpdHRlci5jb20vaWdsYXplcj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzY2ltIG1haWxpbmcgbGlzdA0K c2NpbUBpZXRmLm9yZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2NpbQ0KDQoNCg0KDQotLQ0KSWFuIEdsYXplcg0KU2VuaW9yIERp cmVjdG9yLCBJZGVudGl0eQ0KKzEgMjAyIDI1NSAzMTY2DQpAaWdsYXplcjxodHRwczovL3R3aXR0 ZXIuY29tL2lnbGF6ZXI+DQo= --_000_40dbce70636e45dc89d7edf4507a9abaBN1PR04MB392namprd04pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6R3VsaW07DQoJcGFub3NlLTE6MiAxMSA2IDAgMCAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAR3VsaW0iOw0KCXBhbm9zZS0xOjIgMTEgNiAw IDAgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGku TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl ZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9y bWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl ZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 IDMuMSAtICZxdW90O1N1Y2Nlc3NmdWwgcmVzb3VyY2UgY3JlYXRpb24uLi4mcXVvdDsgLSBJdCBp cyB1bmNsZWFyIGZyb20gdGhlIHNlY29uZCBzZW50ZW5jZSB3aGV0aGVyIHRoZSBlbnRpcmUgb2Jq ZWN0IE1VU1Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgYmUgcmV0 dXJuZWQgb3IgY2FuIHRoZSBzZXJ2ZXIgc2ltcGx5IHJldHVybiBiYWNrIGEgcG9pbnRlciB0byB0 aGUgbmV3bHkgY3JlYXRlZCBvYmplY3Q/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mZ3Q7IEFzc3VtZSB5b3UgYXJlIHJlZmVycmluZyB0bzo8bzpwPjwvbzpwPjwvcD4NCjxw cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZndDsgVXBvbiBzdWNjZXNzZnVsIGNy ZWF0aW9uLCB0aGUgcmVzcG9uc2UgYm9keSBNVVNUPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7IGNvbnRh aW4gdGhlIG5ld2x5IGNyZWF0ZWQgcmVzb3VyY2UuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mZ3Q7IE1heWJlIGl0IHNob3VsZCBzYXkg4oCcdGhlIG5ld2x5IGNyZWF0ZWQg c2VydmljZSBwcm92aWRlciByZXByZXNlbnRhdGlvbiBvZiB0aGUgZnVsbCByZXNvdXJjZeKAnT88 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgVGhhdCBkb2Vzbid0IGFkZHJlc3MgbXkg cG9vcmx5IG1hZGUgcG9pbnQuLi4gV2hhdCBJIGFtIHRyeWluZyB0byBhc2sgaXM6IGRvZXMgaXQg bWFrZSBzZW5zZSB0byBhbHdheXMgaGFuZCBiYWNrPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mZ3Q7IHRoZSBuZXcgY29tcGxldGUgb2JqZWN0PyBXb3VsZCBpdCBiZSBtb3Jl IGVmZmljaWVudCB0byBzaW1wbHkgaGFuZCBiYWNrIGEgcG9pbnQgdG8gdGhlIHJlc291cmNlIGlu c3RlYWQ/Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkkgc2VlIHlvdXIgcG9pbnQsIGJ1dCBkb27igJl0IHRoaW5rIHRoaXMg d2lsbCBiZSBhIGJpZyBjb25jZXJuIGZyb20gYW4gZWZmaWNpZW5jeSBwZXJzcGVjdGl2ZSAobWF5 YmUgb24gbW9iaWxlIHdoZXJlIGJhbmR3aWR0aCByZWFsbHkgY291bnRzPykuJm5ic3A7IElNTyB0 aGUgZnVsbA0KIHJlcHJlc2VudGF0aW9uIGlzIHByZXR0eSB1c2VmdWwuJm5ic3A7IEkgd291bGQg YmUgaW5jbGluZWQgdG8ga2VlcCB0aGUgTVVTVCBmb3Igbm93IHVubGVzcyB3ZSBnZXQgY29tcGxh aW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7R3VsaW0mcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IHNjaW0gW21haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPklhbiBHbGF6ZXI8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIEp1bHkgMTksIDIw MTQgMTE6MjkgQU08YnI+DQo8Yj5Ubzo8L2I+IFBoaWwgSHVudDxicj4NCjxiPkNjOjwvYj4gc2Np bUBpZXRmLm9yZyBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NjaW1dIENvbW1lbnRzIHNv IHNlY3Rpb25zIDEgdGhyb3VnaCAzLjM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGFua3MgZm9yIGdvaW5nIHRocm91Z2ggdGhlc2UgUGhpbC4gQ29tbWVudHMgYmVsb3c8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIFRodSwgSnVsIDE3LCAyMDE0IGF0IDQ6NDYgUE0sIFBoaWwgSHVudCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhp bC5odW50QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWFuLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHRoZSB0aG9yb3VnaCB3YWxr IHRocm91Z2guPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Q29tbWVudHMgaW4gbGluZSBiZWxvdy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrLiBNYW55IG9mIHRoZXNlIGFyZSBv YnZpb3VzIGFuZCB3aWxsIHBsYW4gdG8gcHV0IHRoZW0gaW4gdGhlIGRvY3VtZW50IGZvbGxvd2lu ZyBUb3JvbnRvICh1bmxlc3MgSSBoZWFyIG9iamVjdGlvbnMpLiBPdGhlcnMgSSB3aWxsIGFkZCB0 byB0aGUgbGlzdCBvZiBkaXNjdXNzaW9uIGl0ZW1zIGZvciBUb3JvbnRvLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QaGlsPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QGluZGVwZW5kZW50aWQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8vd3d3Lmlu ZGVwZW5kZW50aWQuY29tIiB0YXJnZXQ9Il9ibGFuayI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRA b3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBKdWwgMTQsIDIwMTQsIGF0IDExOjAwIEFNLCBJYW4gR2xh emVyICZsdDs8YSBocmVmPSJtYWlsdG86aWdsYXplckBzYWxlc2ZvcmNlLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmlnbGF6ZXJAc2FsZXNmb3JjZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVyZSBhcmUgbXkgZWFybHkgY29tbWVu dHMgb24gdGhlIGFib3ZlIHNlY3Rpb25zLiBJJ2xsIGdyaW5kIHRocm91Z2ggbW9yZSBvZiB0aGlz IGEgYml0IGxhdGVyLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjEuMSAtICZxdW90O2lkZW50aXR5IHNlcnZpY2UgcHJvdmlkZXJzIGFuZCBjbGll bnQmcXVvdDsgLSBUaGlzIGlzIGEgbGl0dGxlIGNvbmZ1c2luZy4gRG8gd2UgbWVhbiBpZGVudGl0 eSBwcm92aWRlcnMgYW5kIGNvbnN1bWVycz8gcHJvdmlkZXJzIG9mIGlkZW50aXR5IHNlcnZpY2Vz IGFuZCBvcmdhbml6YXRpb25zIHRoYXQgY29uc3VtZSB0aG9zZSBzZXJ2aWNlcz88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Ib3cgYWJvdXQganVzdCDigJx3ZWIgc2VydmljZSBwcm92aWRlcnMgYW5kIGNsaWVudHPi gJ0uICZuYnNwO1RoZSBmYWN0IHRoYXQgaXQgaXMgYSBwcm90b2NvbCBhcm91bmQgaWRlbnRpdHkg aXNu4oCZdCBuZWFyIGFzIGltcG9ydGFudCBhcyB0aGF0IGl0IGlzIGFuIEhUVFAgcHJvdG9jb2wu PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Xb3JrcyBmb3IgbWUmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4zIC0gVVJMIHZlcnN1cyBVUkkgLSBUaGVy ZSBtaWdodCBiZSBhIGJpdCBvZiBhIGluY29uc2lzdGVuY3kgaGVyZS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5XaWxsIEZpeC4gSSB0aGluayB0aGUgaXNzdWUgaGVyZSBpcyB0aGF0IGl0 IG11c3QgYmUgYSBVUkwgKGFjY2Vzc2libGUgdmlhIEhUVFApIGJ1dCBJRVRGIHNlZW1zIHRvIGFs d2F5cyB3YW50IFVSSXMgcmVnYXJkbGVzcy4gJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuIC0gVGhlIHNlY3Rpb24gaXMg dGl0bGVkICZxdW90O0F1dGhlbnRpY2F0aW9uIGFuZCBBdXRob3JpemF0aW9uJnF1b3Q7IGJ1dCBh dXRob3JpemF0aW9uIGlzbid0IGRpcmVjdGx5IGFkZHJlc3NlZC4gVGhlIHNlbnRlbmNlICZxdW90 O0FwcHJvcHJpYXRlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIG9mIHRoZSBzZWxlY3RlZCBhdXRo ZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBzY2hlbWVzIFNIT1VMRCBiZSB0YWtlbiZxdW90 OyBpc24ndA0KIGFjdGlvbmFibGUgLSBpdCBpcyBhIG1vdGhlcmhvb2QgYW5kIGFwcGxlIHBpZSBz dGF0ZW1lbnQuIERvIHdlIHdhbnQgdG8gc3BlY2lmaWNhbGx5IG1lbnRpb24gc2NvcGVzIGFzIGFu IGF1dGhvcml6YXRpb24gbWVjaGFuaXNtPyBEbyB3ZSBqdXN0IHdhbnQgdG8gY3V0ICZxdW90O0F1 dGhvcml6YXRpb24mcXVvdDsgZnJvbSB0aGUgc2VjdGlvbiBoZWFkZXI/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSBoYXZlIGFscmVhZHkgYXR0ZW1wdGVkIHRvIGNyZWF0ZSBhIGJldHRlciB3YXkgb2YgZGVzY3Jp YmluZyB0aGlzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0id29y ZC13cmFwOmJyZWFrLXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPiZuYnNwOyZuYnNwOyBCZWNh dXNlIFNDSU0gdXNlcyBIVFRQIHByb3RvY29sLCBpdCBkb2VzIG5vdCBkZWZpbmUgYSBzY2hlbWUg Zm9yPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGF1dGhlbnRpY2F0aW9uIGFu ZCBhdXRob3JpemF0aW9uLiZuYnNwOyBJdCBkZXBlbmRzIG9uIHN0YW5kYXJkIEhUVFA8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgYXV0aGVudGljYXRpb24gc2NoZW1lcy4mbmJz cDsgSXQgaXMgUkVDT01NRU5ERUQgdGhhdCBjbGllbnRzIGJlPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7IGltcGxlbWVudGVkIGluIHN1Y2ggYSB3YXkgdGhhdCBuZXcgYXV0aGVu dGljYXRpb24gc2NoZW1lcyBjYW4gYmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsgZGVwbG95ZWQuJm5ic3A7IEltcGxlbWVudGVycyBTSE9VTEQgc3VwcG9ydCBleGlzdGluZyBh dXRoZW50aWNhdGlvbi88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgYXV0aG9y aXphdGlvbiBzY2hlbWVzLiZuYnNwOyBJbiBwYXJ0aWN1bGFyLCBPQXV0aDIgW1JGQzY3NTBdIGlz PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFJFQ09NTUVOREVELiZuYnNwOyBB cHByb3ByaWF0ZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBvZiB0aGUgc2VsZWN0ZWQ8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6 YXRpb24gc2NoZW1lcyBTSE9VTEQgYmUgdGFrZW4uJm5ic3A7IEJlY2F1c2U8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgdGhpcyBwcm90b2NvbCB1c2VzIEhUVFAgcmVzcG9uc2Ug c3RhdHVzIGNvZGVzIGFzIHRoZSBwcmltYXJ5IG1lYW5zIG9mPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7IHJlcG9ydGluZyB0aGUgcmVzdWx0IG9mIGEgcmVxdWVzdCwgc2VydmVy cyBhcmUgYWR2aXNlZCB0byByZXNwb25kIHRvPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7IHVuYXV0aG9yaXplZCBvciB1bmF1dGhlbnRpY2F0ZWQgcmVxdWVzdHMgdXNpbmcgdGhl IDQwMSByZXNwb25zZSBjb2RlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGlu IGFjY29yZGFuY2Ugd2l0aCBTZWN0aW9uIDMuMSBvZiBbUkZDNzIzNV0uPG86cD48L286cD48L3By ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IEFsbCBl eGFtcGxlcyBzaG93IGFuIE9BdXRoMiBiZWFyZXIgdG9rZW4gW1JGQzY3NTBdICh0aG91Z2h0IGl0 IGlzIG5vdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyByZXF1aXJlZCkgOyBl LmcuLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyBHRVQgL1VzZXJzLzI4MTljMjIzLTdmNzYtNDUzYS05MTlkLTQxMzg2MTkw NDY0NiBIVFRQLzEuMTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBIb3N0OiA8 YSBocmVmPSJodHRwOi8vZXhhbXBsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5leGFtcGxlLmNvbTwv YT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgQXV0aG9yaXphdGlvbjogQmVh cmVyIGg0ODBkanM5M2hkODxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBUaGUgY29udGV4dCBvZiB0aGUgcmVxdWVzdCAoaS5l LiB0aGUgdXNlciBmb3Igd2hvbSBkYXRhIGlzIGJlaW5nPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7IHJlcXVlc3RlZCkgTVVTVCBiZSBpbmZlcnJlZCBieSBzZXJ2aWNlIHByb3Zp ZGVycy48bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQg c2FpZCwgZG8gd2Ugd2FudCB0byBnZXQgaW50byBhIHN0YW5kYXJkaXplZCBhdXRob3JpemF0aW9u IG1vZGVsPyAmbmJzcDtNYXliZSB0aGlzIGlzIHNvbWV0aGluZyBhcyBhIGZ1dHVyZSBkcmFmdCBz cGVjaWZpY2F0aW9uLiBQYXJ0aWN1bGFybHkgaWYgd2Ugd2FudCB0byB0YWxrIGFib3V0IGEgZnV0 dXJlIFNDSU0gRGlyZWN0b3J5IHNwZWNpZmljYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdCBhIGh1Z2UgZmFuIG9mIG9mIHN0YW5kYXJk aXppbmcgdGhlIGF1dGhaIG1vZGVsIHJpZ2h0IG5vdy4gSSB0aGluayB0aGVyZSBhcmUgbW9yZSB3 b3JtcyBpbiB0aGF0IGNhbiB0aGFuIHdlIHdhbnQgdG8gZGVhbCB3aXRoIHJpZ2h0IG5vdy4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ My4gQVBJIC0gRGlkIHdlIGRlY2lkZWQgd2hldGhlciBTQ0lNIGlzIGFuIEFQSSBvciBhIHByb3Rv Y29sPyBGb3IgY29uc2lzdGVuY3ktc2FrZSwgdGhlIHRpdGxlIG9mIHRoaXMgc2VjdGlvbiBhbmQg dGhlIGZpcnN0IHNlbnRlbmNlIG1heSBuZWVkIHRvIGNoYW5nZSBhY2NvcmRpbmdseS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QZXIgbXkgcHJldmlvdXMgZW1haWwuIEnigJl2ZSBoYWQg c29tZSByZWNvbW1lbmRhdGlvbiB0aGF0IEFQSSBhbHdheXMgcmVmZXJzIHRvIGEgcHJvZ3JhbW1p bmcgbGlicmFyeSBpbnRlcmZhY2UgcmF0aGVyIHRoYW4gb3ZlciB0aGUgd2lyZSBzZW1hbnRpY3Mu IFRodXMgSSBoYXZlIGJlZ3VuIGNoYW5naW5nIHRvIHRoZSBTQ0lNIHByb3RvY29sIG9yIFNDSU0g SFRUUCBwcm90b2NvbCB3aGVyZSBhcHByb3ByaWF0ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90ZSB3ZSBuZWVkIHRvIGRpc2N1c3MgdGhl IGlzc3VlIG9mIHJlbmFtaW5nIHRoZSBTQ0lNIEFQSSBkcmFmdCB0byBTQ0lNIFByb3RvY29sIGRy YWZ0LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4zLiBQT1NUIC0gJnF1b3Q7b3IgYnVsayBtb2RpZnkgcmVzb3VyY2VzJnF1b3Q7IC0g QnVsaz8gSSB0aG91Z2h0IHRoYXQgYnVsayB3YXMgb2ZmIHRoZSB0YWJsZSBmb3IgdGhpcyBkcmFm dD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGVyZSB3YXMgc29tZSBkaXNjdXNzaW9uIG9uIG9uZSBvZiB0aGUg Y2FsbHMgKEkgY2Fu4oCZdCByZW1lbWJlciBpZiB3ZSBmb2xsb3dlZCB1cCBvbiB0aGUgbGlzdCku IFRoZSBmZWVsaW5nIHdhcyB0aGF0IG1hbnkgYXJlIGJlZ2lubmluZyB0byBpbXBsZW1lbnQgbm93 LiBXZeKAmWQgbGlrZSB0byBrZWVwIGl0IGluIHBsYWNlIGZvciBub3cgYnV0IHdlIGFncmVlZCBp dCBtYXkgbm90IG1ha2UgdGhlIGZpbmFsIGN1dC4NCiAmbmJzcDtUaGlzIHNob3VsZCBiZSBhIGRp c2N1c3Npb24gaXRlbSBmb3IgVG9yb250by48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkn ZCBwdXNoIHRvIHJlbW92ZSBpdCBidXQgaXQgaXNuJ3QgYSBkZWFsIGJyZWFrZXIgZm9yIHVzLiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4zLiBQVVQgLSBUaGUgZHJhZnQgcmVhZHMgJnF1b3Q7UFVUIFNIT1VMRCBOT1QgYmUgdXNlZCB0 byBjcmVhdGUgbmV3IHJlc291cmNlcy4mcXVvdDsgU2hvdWxkIHRoYXQgU0hPVUxEIGFjdHVhbGx5 IGJlIGEgTVVTVD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZbSBvcGVuIHRvIHNv bWUgZGlzY3Vzc2lvbiBoZXJlLiBJ4oCZbSBub3Qgc3VyZSBpZiB0aGVyZSBhcmUgbGltaXRlZCBz Y2VuYXJpb3Mgd2hlcmVieSB0aGUgaW1wbGVtZW50YXRpb24gaGFzIHRvIGFsbG93IHRoaXMuPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjMuIEFQSSBUYWJsZSAtIG1pbm9yIG5pdCAtIG9ubHkgc29tZSBvZiB0aGUgc2VjdGlvbnMgYXJl IHByb3Blcmx5IGxpbmtlZCBpbiB0aGUgUERGPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T2suIFdlaXJkLiBXaWxs IHRha2UgYSBsb29rLiBTZWVtcyBsaWtlIGFuIHhtbDJyZmMgaXNzdWUgKHRoZSB4bWwgcmVmZXJl bmNlcyB0aGUgc2FtZSB3YXkgZm9yIGVhY2ggaXRlbSkuPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMuIEFQSSBUYWJsZSAtIC9CdWxr IC0gSSB0aG91Z2h0IHdlIHdlcmVuJ3QgZGVhbGluZyB3aXRoIEJ1bGsgZm9yIHYyIGFuZCB3ZXJl IGdvaW5nIHRvIGhhbmRsZSBpdCB2aWEgcHJvZmlsZSBsYXRlcjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWUgYWJv dmU8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+My4xIC0gJnF1b3Q7U3VjY2Vzc2Z1bCByZXNvdXJjZSBjcmVhdGlvbi4uLiZxdW90OyAt IEl0IGlzIHVuY2xlYXIgZnJvbSB0aGUgc2Vjb25kIHNlbnRlbmNlIHdoZXRoZXIgdGhlIGVudGly ZSBvYmplY3QgTVVTVCBiZSByZXR1cm5lZCBvciBjYW4gdGhlIHNlcnZlciBzaW1wbHkgcmV0dXJu IGJhY2sgYSBwb2ludGVyIHRvIHRoZSBuZXdseSBjcmVhdGVkIG9iamVjdD88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QXNzdW1lIHlvdSBhcmUgcmVmZXJyaW5nIHRvOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+VXBvbiBzdWNjZXNzZnVsIGNy ZWF0aW9uLCB0aGUgcmVzcG9uc2UgYm9keSBNVVNUPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsgY29udGFpbiB0 aGUgbmV3bHkgY3JlYXRlZCByZXNvdXJjZS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1heWJlIGl0IHNob3VsZCBzYXkg4oCcdGhlIG5ld2x5 IGNyZWF0ZWQgc2VydmljZSBwcm92aWRlciByZXByZXNlbnRhdGlvbiBvZiB0aGUgZnVsbCByZXNv dXJjZeKAnT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IGRv ZXNuJ3QgYWRkcmVzcyBteSBwb29ybHkgbWFkZSBwb2ludC4uLiBXaGF0IEkgYW0gdHJ5aW5nIHRv IGFzayBpczogZG9lcyBpdCBtYWtlIHNlbnNlIHRvIGFsd2F5cyBoYW5kIGJhY2sgdGhlIG5ldyBj b21wbGV0ZSBvYmplY3Q/IFdvdWxkIGl0IGJlIG1vcmUgZWZmaWNpZW50IHRvIHNpbXBseSBoYW5k IGJhY2sgYSBwb2ludCB0byB0aGUgcmVzb3VyY2UgaW5zdGVhZD8mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMuMSAtIElzIHRoZSBzZXJ2 ZXIgcmVxdWlyZWQgdG8gcmV0dXJuIGEgTG9jYXRpb24gaGVhZGVyIHdoZW4gYSByZXNvdXJjZSBp cyBzdWNjZXNzZnVsbHkgY3JlYXRlZD8gVGV4dCBkb2VzIG5vdCBtYWtlIHRoYXQgY2xlYXIuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWdyZWVkIGl0IHNob3VsZCBzYXkgdGhpcy48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ My4xLjEuIC0gSnVzdCBhIGNsYXJpZmljYXRpb24gLSAmcXVvdDtTSEFMTCBiZSBzZXQgYnkgdGhl IHNlcnZpY2UgcHJvdmlkZXImcXVvdDsgLSBpbiB0aGlzIGNhc2Ugc2VydmljZSBwcm92aWRlciBt ZWFucyBTQ0lNIHNlcnZlciBhbmQgbm90IHRoZSBjbGllbnQsIGlzIHRoYXQgY29ycmVjdD88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JbiBhbGwgY2FzZXMg4oCcc2VydmljZSBwcm92aWRlcuKAnSBtZWFucyB0aGUg SFRUUCBzZXJ2aWNlLCBub3QgdGhlIHByb3ZpZGVyIG9mIGlkZW50aXR5IGRhdGEgKHRoZSBjbGll bnQpLiBNYXliZSB3ZSBuZWVkIG1vcmUgdGVybWlub2xvZ3kgdGV4dCBpbiB0aGUgaW50cm8gb24g dGhpcyBwb2ludC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+My4yIENvbnNpc3RlbmN5IHF1ZXN0aW9uIC0gUXVlcnkgb3IgU2VhcmNo PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFncmVlZC4gQW55IHByZWZlcmVuY2VzPzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Tm8uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjMuMi4yIENvbnNpc3RlbmN5IHF1ZXN0aW9uIC0gaXQgYXBwZWFy cyB0aGF0IHRoaXMgZHJhZnQgcmVmZXJzIHRvICZxdW90O3NlcnZpY2UgcHJvdmlkZXJzLCZxdW90 OyAmcXVvdDtQcm92aWRlcnMsJnF1b3Q7IGFuZCAmcXVvdDtzZXJ2ZXJzJnF1b3Q7IC0gZG9lcyB0 aGlzIG5lZWQgdG8gYmUgY2xlYW5lZCB1cCBhbmQgbWFkZSBjb25zaXN0ZW50PzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFncmVlZCBzZWUgYWJvdmUuPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMuMi4yLjEgLSBEbyB3ZSBy ZWFsbHkgd2FudCB0byBhbGxvdyBhIHNlYXJjaCBhZ2FpbnN0IHRoZSBzZXJ2ZXIgcm9vdCB0aGF0 IHdvdWxkIHJlc3VsdCBpcyBhbGwgb2JqZWN0cyBiZWluZyByZXR1cm5lZD8gU2VlbXMgbGlrZSB3 ZSBvdWdodCB0byBlbmRvcnNlIGEgcGF0dGVybiBvZiBxdWVyeWluZyByZXNvdXJjZVR5cGVzIGFu ZCB0aGVuIGEgc3BlY2lmaWMgcmVzb3VyY2VUeXBlIGlzIGEgYmV0dGVyIHdheSB0bw0KIGdvLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoaXMgaXMgcmVndWxhdGVkIGJ5IHRoZSBtYXggcmVzdWx0cyBsaW1pdHMu IFRoZXJlIHdhcyBhIHNwZWNpZmljIGV4YW1wbGUgb2YgYmVpbmcgYWJsZSB0byBzZWFyY2ggd2l0 aG91dCByZWdhcmQgdG8gcmVzb3VyY2UgdHlwZSwgb3IgYSBzcGVjaWZpYyBzZXQgb2YgcmVzb3Vy Y2UgdHlwZXMuIFRoZSB1c2UgY2FzZSB3YXMgYSBzZWFyY2gtYXMtdXNlci10eXBlcyBzY2VuYXJp byB3aGVyZSB0aGUgcmVzdWx0IHdhcw0KIG5vdCBrbm93biB0byBiZSBhIHVzZXIgb3IgYSBncm91 cC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+My4yLjIuMiAtIFdoYXQgaGFwcGVucyBpZiBzb21lb25lIGluY2x1ZGVzIGEgJnF1b3Q7 Z2UmcXVvdDsgc2VhcmNoIGFnYWluc3QgYSBub24tbnVtZXJpYyBvciBub24tZGF0ZSB0eXBlIGZp ZWxkPyBUaGUgbmV4dCBpc24ndCBjbGVhciBhYm91dCBhIGZhaWx1cmUgY29uZGl0aW9uLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5NYXliZSB5b3UgbWlzLXJlYWQuIElmIGFueXRoaW5nLCBJIHNlZSBpdCBkb2VzbuKA mXQgc2F5IGhvdyBudW1lcmljIGNvbXBhcmlzb25zIGFyZSBtYWRlLiBGb3Igc3RyaW5ncyBpdCBp cyB0aGUgbm9ybWFsIGxleGljb2dyYXBoaWNhbCBjb21wYXJpc29uLjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLjIuMi4zIC0gUHJp bWFyeSBhdHRyaWJ1dGVkIC0gaXQgaXNuJ3QgY2xlYXIgZnJvbSB0aGUgdGV4dCB3aGF0IGEgcHJp bWFyeSBhdHRyaWJ1dGUgaXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2lsbCBhZGQgYSByZWZlcmVuY2UgdG8g dGhlIG11bHRpLXZhbHVlZCBhdHRyaWJ1dGUgZGVmaW5pdGlvbiB3aGVyZSBwcmltYXJ5IGlzIGRl ZmluZWQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K PGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjMuMi4yLjUgLSBNZXRhLXF1ZXN0aW9uIC0gaG93IGRvZXMgYSBTQ0lNIHNlcnZl ciBpbmRpY2F0ZSB3aGV0aGVyIGl0IHN1cHBvcnRzIGF0dHJpYnV0ZXMgYW5kIGV4Y2x1ZGVkQXR0 cmlidXRlcyB0byBiZSByZXR1cm5lZCAob3Igbm90KSBmb3IgYSBRdWVyeT88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5Ob3Qgc3VyZSB3aGF0IHlvdSBtZWFuLiBUaGVyZeKAmXMgbm8gb3B0aW9uYWxpdHkgaGVyZS48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9rLCB0aGF0IHdhc24ndCBvYnZpb3VzIGZyb20g dGhlIHRleHQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjMuMi4zIC0gRmlndXJlIDIgLSB0aGUgZXhhbXBsZSBkb2Vzbid0IHVzZSBh IG1ldGEucmVzb3VyY2VUeXBlIGF0dHJpYnV0ZSB3aGljaCBJIHRoaW5rIGl0IHNob3VsZCB0byBp bmRpY2F0ZSBhIGJlc3QgcHJhY3RpY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3Vy ZS4gV2h5IG5vdC4gJm5ic3A7TWlnaHQgYmUgYSBnb29kIHdheSB0byBzYXkgaG93IHRvIHNlYXJj aCBib3RoIHVzZXJzIGFuZCBncm91cHMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMuMy4xIC0gSFRUUCBQVVQgJnF1b3Q7U0hPVUxE IE5PVCZxdW90OyBvciAmcXVvdDtNVVNUIE5PVCZxdW90OyBiZSB1c2VkIHRvIGNyZWF0ZSBuZXcg cmVzb3VyY2VzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlZSBhYm92ZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My4zLjEgLSAmcXVvdDtJZiBh biBhdHRyaWJ1dGUgaXMgcmVxdWlyZWQuLi4mcXVvdDsgLSBXaGF0IGlmIHRoZSBhdHRyaWJ1dGUn cyB2YWx1ZSBpc24ndCBnb2luZyB0byBjaGFuZ2U/IERvZXMgaXQgc3RpbGwgbmVlZCB0byBiZSBz ZW50IGFsb25nPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcy4gU2luY2UgaXQgaXMgYSByZXBsYWNlLCBidXQg dmFsdWUgbXVzdCBhbHdheXMgYmUgc3VwcGxpZWQgLSBldmVuIHdoZW4gbm8gY2hhbmdlLiBPdGhl cndpc2UgaXQgbWFrZXMgbWlzc2luZyB2YWx1ZSBsb2dpYyBldmVuIG1vcmUgY29tcGxleC4gOi0p PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjMuMy4xIC0gJnF1b3Q7QXR0cmlidXRlcyB3aG9zZSBtdXRhYmls aXR5IGlzICdyZWFkV3JpdGUuJyBUaGlzIHBhcmFncmFwaCBzZWVtIHZlcnkgc3F1aXNoeS4gVGhl IHNlcnZlciBpcyBhZmZvcmRlZCBhIGxvdCBvZiBsYXRpdHVkZSB3aGljaCB0aGUgY2xpZW50IG1h eSBub3QgYmUgYXdhcmUgb2YuIFNob3VsZCBiZSBtb3JlIHByZXNjcmlwdGl2ZT8gQXR0cmlidXRl cyB0aGF0IGFyZSBvbWl0dGVkIGFyZSBub3QgY2hhbmdlZD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcHJv YmxlbSBoZXJlIHdhcyB0aGUgaXNzdWUgSSByYWlzZWQgZWFybGllciBhYm91dCB1bmRlcnN0YW5k aW5nIHRoZSBpbXBsaWVkIG1lYW5pbmcgb2YgYSBtaXNzaW5nIHZhbHVlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBvbWl0dGVkIGJlY2F1c2Ug Y2xpZW50IGlzbuKAmXQgYXdhcmUgb2YgaXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiogb21pdHRlZCBiZWNhdXNlIHRoZSBjbGllbnQgZG9lcyBu b3QgaW50ZW5kIHRvIGNoYW5nZSBpdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+KiBvbWl0dGVkIGJlY2F1c2UgdGhlIGNsaWVudCB3YW50cyB0byBk ZWZhdWx0IGl0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4qIG9taXR0ZWQgYmVjYXVzZSB0aGUgY2xpZW50IHdhbnRzIHRvIGRlbGV0ZSBpdDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBvbWl0dGVk IGJlY2F1c2UgdGhlIGNsaWVudCBkb2VzbuKAmXQgY2FyZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgc3F1aXNoaW5lc3Mgd2FzIGEgcmVz dWx0IG9mIHRyeWluZyB0byBnaXZlIHRoZSBzZXJ2ZXIgc29tZSByb29tIHRvIGludGVycHJldC48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhp cyBwcm9iYWJseSBzdGlsbCBuZWVkcyBtb3JlIGRpc2N1c3Npb24uPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMuMy4yLjEgLSBJJ2Qg bW92ZSB0aGUgcGFyYWdyYXBoIGJlZm9yZSB0aGUgZXhhbXBsZSB1cCBiZWZvcmUgdGhlIGxpc3Qg b2YgcG9zc2libGUgb3V0Y29tZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm9rPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMuMy4yLjIgLSBJIGdldCB3 aGF0IGhhcHBlbnMgaGVyZSBidXQgdGhlcmUgY291bGQgYmUgY29uZnVzaW9uIGFzIHRvIHdoZXRo ZXIgUmVtb3ZlIHNldHMgYSB2YWx1ZSB0byAmcXVvdDtudWxsJnF1b3Q7IG9yIG5vdC4gSXMgcmVt b3ZpbmcgYW4gYXR0cmlidXRlIGVxdWl2YWxlbnQgdG8gbnVsbGluZyBpdD88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSB0aGluayB3ZeKAmXZlIGluZm9ybWFsbHkgZGlzY3Vzc2VkIHRoYXQgZm9yIHNj aW0sIG51bGwgPT0gcmVtb3ZlZC4gV2Ugc2hvdWxkIGRpc2N1c3MgdGhpcyBpbiBUb3JvbnRvIGFu ZCBmb3JtYWxpemUgdGhpcyBpbiB0aGUgc3BlYy4gJm5ic3A7SGF2aW5nIG51bGwgZXF1YWwgdG8g cmVtb3ZlZCBtYWtlcyB0aGUgbWlzc2luZy9vbWl0dGVkIGF0dHJpYnV0ZSBsb2dpYyBvbiBQVVQg ZXRjIGVhc2llciB0byBkZWZpbmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My4zLjIuMiAtIFdoYXQg YWJvdXQgbXV0YWJpbGl0eT8gSWYgSSBhdHRlbXB0IHRvIHJlbW92ZSBhIHJlYWRPbmx5LCBjYW4g ST8gV2hhdCBhYm91dCAmcXVvdDtyZXF1aXJlZCZxdW90OyBhdHRyaWJ1dGVzPzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkdvb2QgcG9pbnQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMuMy4yLjMgLSBXaGF0IGFib3V0IG11 dGFiaWxpdHk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWdyZWVkLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JYW4gR2xhemVy PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZW5p b3IgRGlyZWN0b3IsIElkZW50aXR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJ0ZWw6JTJCMSUyMDIwMiUyMDI1NSUyMDMxNjYiIHRh cmdldD0iX2JsYW5rIj4mIzQzOzEgMjAyIDI1NSAzMTY2PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly90d2l0dGVy LmNvbS9pZ2xhemVyIiB0YXJnZXQ9Il9ibGFuayI+QGlnbGF6ZXI8L2E+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0Kc2NpbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2NpbUBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNjaW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JYW4gR2xhemVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZW5pb3IgRGlyZWN0b3IsIElkZW50aXR5PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzEgMjAyIDI1 NSAzMTY2PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YSBocmVmPSJodHRwczovL3R3aXR0ZXIuY29tL2lnbGF6ZXIiIHRhcmdldD0iX2JsYW5rIj5A aWdsYXplcjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_40dbce70636e45dc89d7edf4507a9abaBN1PR04MB392namprd04pro_-- From nobody Mon Jul 21 14:57:03 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21DF1A00E4 for ; Mon, 21 Jul 2014 14:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaBV9qQBZyNr for ; Mon, 21 Jul 2014 14:57:01 -0700 (PDT) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 364F91A0076 for ; Mon, 21 Jul 2014 14:57:00 -0700 (PDT) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 21 Jul 2014 23:56:36 +0200 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0847.030; Mon, 21 Jul 2014 23:56:36 +0200 From: =?Windows-1252?Q?Erik_Wahlstr=F6m?= To: Phil Hunt Thread-Topic: [scim] Bulk request has a non-deterministic condition Thread-Index: AQHPpPEMFVmfcj1VekWZuyk4Z9ltJZuqfJGAgAAJ/QCAABiOgIAAAfCAgABQrQA= Date: Mon, 21 Jul 2014 21:56:35 +0000 Message-ID: <333AA0C2-E421-4167-B48B-66D4FA0FEF3E@nexusgroup.com> References: <36A7B56D-EBF4-4208-AA3A-2DA7D118F8C2@oracle.com> <1405954605.9443.YahooMailNeo@web142804.mail.bf1.yahoo.com> <1405962023.65562.YahooMailNeo@web142804.mail.bf1.yahoo.com> In-Reply-To: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [94.234.170.213] Content-Type: multipart/alternative; boundary="_000_333AA0C2E4214167B48B66D4FA0FEF3Enexusgroupcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/2xt0RwSwmCSnb21idrnu1ZDz4lo Cc: SCIM WG , William Mills Subject: Re: [scim] Bulk request has a non-deterministic condition X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 21:57:03 -0000 --_000_333AA0C2E4214167B48B66D4FA0FEF3Enexusgroupcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Ordering is not critical, but more way more efficient. The following exampl= e bulk implementation iterates through the document 3 times, then cancels. = That means that, using your example below, it first tries to resolve any bu= lkIds in a PATCH request on a Group, if the bulkId not yet resolved (user i= s not created yet), it just continues to go through the bulk job and then a= dding the new user. In a second iteration the bulkId can be resolved and th= e user is added to the group. It=92s possible for the service provider to s= pecify a limitation of the numbers of jobs in a request if it does not want= to iterate to big requests to many times. It=92s also possible for the cli= ent to add them in the correct order in the array, it=92s maintains it=92s = order in the JSON document according to RFC4627 ("An array is an ordered se= quence of zero or more values.=94). https://code.google.com/p/scimproxy/source/browse/trunk/scimproxy/src/main/= java/info/simplecloud/scimproxy/ScimBulkServlet.java I don=92t really see any reason why we should split if off? / Erik On 21 Jul 2014, at 19:07, Phil Hunt > wrote: Bill, Erik clarified that he believed the lack of ordering is a mistake. Orderin= g is critical if you are using bulkIds (e.g. add a user then add that user = to a series of groups). One of our developers commented that Bulk is also potentially useful if you= want to take a series of operations like add a user and place them all int= o a group and treat the whole thing as pass/fail. I=92ll do some more reading on SPDY. Curious to understand how that would f= it. It=92s seeming like there are a lot who still want it. Maybe splitting it = off so we can explore things like SPDY is something to consider? It also g= ives a chance for implementations to catch up on it. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 21, 2014, at 1:00 PM, Bill Mills > wrote: Implying that there is an ordering in bulk transactions is interesting, and= I think not supported by the draft text. I also doubt there is any great = efficiency to be gained by having 1k transactions in a single bulk operatio= n in the end, other than a single authn check instead of 1k. SPDY would get you equivalent throughput and you lose the complexity of the= bulk error message handling. On Monday, July 21, 2014 8:33 AM, Phil Hunt > wrote: Not sure I understand the use of spdy. Seems useful if you want to maintain a high rate update stream. But in thi= s case Bulk would simply be passing 1000s of changes at once which may be b= etter than 1000s of separate req/responses which may get out of sequence if= you aren't careful to account for connection pooling. Phil On Jul 21, 2014, at 10:56, Bill Mills > wrote: I think Bulk should be dropped in favor of something like supporting SPDY f= or high volume. On Monday, July 21, 2014 7:41 AM, Phil Hunt > wrote: The following paragraph in Bulk was brought to my attention as problematic: There can be more then one operation per resource in each bulk job. The Service client MUST take notice of the unordered structure of JSON and the service provider can process operations in any order. For example, if the Service client sends two PUT operations in one request, the outcome is non-deterministic. >From our perspective this makes Bulk un-implementable, since other paragrap= hs seem to depend on serial processing (eg bulkId). Anybody have any backgr= ound for this? It seems to come from SCIM 1. If we were to proceed with bulk, I would recommend striking this paragraph. 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_333AA0C2E4214167B48B66D4FA0FEF3Enexusgroupcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0F17CC93F7D88F4BB00DD69CFF32D33F@nexusgroup.com> Content-Transfer-Encoding: quoted-printable
Ordering is not critical, but more way more efficient. The following e= xample bulk implementation iterates through the document 3 times, then canc= els. That means that, using your example below, it first tries to resolve a= ny bulkIds in a PATCH request on a Group, if the bulkId not yet resolved (user is not created yet), it just= continues to go through the bulk job and then adding the new user. In a se= cond iteration the bulkId can be resolved and the user is added to the grou= p. It=92s possible for the service provider to specify a limitation of the numbers of jobs in a request if it= does not want to iterate to big requests to many times. It=92s also possib= le for the client to add them in the correct order in the array, it=92s mai= ntains it=92s order in the JSON document according to RFC4627 ("An= array is an ordered sequence of zero or more values.=94).


I don=92t really see any reason why we should split if off?

/ Erik

On 21 Jul 2014, at 19:07, Phil Hunt <phil.hunt@oracle.com> wrote:

Bill,

Erik clarified that he believed the lack of ordering is a mistake. &nb= sp;Ordering is critical if you are using bulkIds (e.g. add a user then add = that user to a series of groups).

One of our developers commented that Bulk is also potentially useful i= f you want to take a series of operations like add a user and place them al= l into a group and treat the whole thing as pass/fail.

I=92ll do some more reading on SPDY. Curious to understand how that wo= uld fit.

It=92s seeming like there are a lot who still want it.  Maybe spl= itting it off so we can explore things like SPDY is something to consider? =  It also gives a chance for implementations to catch up on it.


On Jul 21, 2014, at 1:00 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

Implying that there is an ordering in bulk transactions is inter= esting, and I think not supported by the draft text.  I also doubt the= re is any great efficiency to be gained by having 1k transactions in a sing= le bulk operation in the end, other than a single authn check instead of 1k.

SPDY would get you equivalent throughput and you lose the complexity = of the bulk error message handling.


On Monday, July 21, 2014 8= :33 AM, Phil Hunt <phil.hunt@ora= cle.com> wrote:


Not sure I understand the use of spdy. 

Seems useful if you want to maintain a high rate update stream.  = But in this case Bulk would simply be passing 1000s of changes at once whic= h may be better than 1000s of separate req/responses which may get out of s= equence if you aren't careful to account for connection pooling. 

Phil

On Jul 21, 2014, at 10:56, Bill Mills <wmills_92105@yahoo.com> wrote:

I think Bulk should be dropped in favor of something like suppor= ting SPDY for high volume.


On Monday, July 21, 2014 7= :41 AM, Phil Hunt <phil.hunt@oracle.com> wrote:


The following paragraph in Bulk was brought to my= attention as problematic: 
   There can be more then one operation per resource in =
each bulk job.
   The Service client MUST take notice of the unordered structure of
   JSON and the service provider can process operations in any order.
   For example, if the Service client sends two PUT operations in one
   request, the outcome is non-deterministic.

From our perspective this makes Bulk un-implementable, since other par= agraphs seem to depend on serial processing (eg bulkId). Anybody have any b= ackground for this? It seems to come from SCIM 1.

If we were to proceed with bulk, I would recommend striking this parag= raph.

Phil

@independentid
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

--_000_333AA0C2E4214167B48B66D4FA0FEF3Enexusgroupcom_-- From nobody Mon Jul 21 15:28:59 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905ED1A0453 for ; Mon, 21 Jul 2014 15:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZ4IUzmx9fzu for ; Mon, 21 Jul 2014 15:28:54 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 471671A0418 for ; Mon, 21 Jul 2014 15:28:54 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) with Microsoft SMTP Server (TLS) id 15.0.990.7; Mon, 21 Jul 2014 22:28:53 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.122]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.122]) with mapi id 15.00.0990.007; Mon, 21 Jul 2014 22:28:53 +0000 From: Kelly Grizzle To: "scim@ietf.org" Thread-Topic: API comments: start to 3.2.2.2 Thread-Index: Ac+lMr9kRK/8F1TzSniuiPQKvSFmCw== Date: Mon, 21 Jul 2014 22:28:53 +0000 Message-ID: <5090514cb5e34810a3d46ef686e3d7b1@BN1PR04MB392.namprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 07946D5A007AF407946EA7 x-originating-ip: [97.79.140.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0279B3DD0D x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(19580395003)(76576001)(105586002)(19300405004)(19625215002)(21056001)(46102001)(229853001)(85852003)(83072002)(66066001)(87936001)(4396001)(2656002)(31966008)(99396002)(33646002)(16236675004)(50986999)(54356999)(2351001)(15202345003)(79102001)(101416001)(83322001)(107886001)(81542001)(110136001)(107046002)(77096002)(76482001)(74502001)(80022001)(106356001)(81342001)(99286002)(95666004)(64706001)(19609705001)(74662001)(86362001)(92566001)(20776003)(77982001)(15975445006)(74316001)(85306003)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_5090514cb5e34810a3d46ef686e3d7b1BN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/OxBtm0uiZ4CYc2SEj6q4QUaWsdg Subject: [scim] API comments: start to 3.2.2.2 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 22:28:56 -0000 --_000_5090514cb5e34810a3d46ef686e3d7b1BN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm going through the docs with a fine-toothed comb. Here are my comments = so far ... more to come later. > 3. POST Create new resources, create a search request, or bulk modify > resources. The other HTTP method descriptions use "retrieves", "modifies", "deletes". = Should this use "creates"? > 3. | Schema | /Schemas | GET (Section | Retrieve a | > | | | 3.2.1) | resource's | > | | | | schema | I recommend changing the description to "Retrieve the supported schemas". > 3. Response and error codes SHOULD be transmitted via the HTTP status > code of the response (if possible), and SHOULD also be specified in > the body of the response. Currently response codes are only included in the body of the response for = errors. Also, is there any case where transmitting an HTTP status code is = not possible? I recommend changing to the following: Response and error codes MUST be transmitted via the HTTP status code of the response. Errors MUST be included in the body of the response (see section 3.10). > 3.1 Clients that would like to override a > server defaults, MAY specify "null" for a single-valued attribute or > an empty array "[]" for a multi-valued attribute to clear all values= . Should "defaults" be "default" here? > 3.1.1 the meta attribute > "resourceType" SHALL be set by the service provider to the > corresponding resource Type for the endpoint. "resource Type" should be "resource type" (lowercase) > 3.2 Service providers MAY choose to respond with a sub-set of > resource attributes, though MUST minimally return the resource id a= nd > meta attributes. Now that we specify "returned" in the schema (always/never/default/request)= , the first part of this sentence doesn't make as much sense. Perhaps this= should be changed to mention the "returned" attribute. > 3.2.2.1 A server MAY support searches against the server root (e.g. "/"= ). Didn't we talk about adding something to ServiceProviderConfigs that indica= tes whether this is supported or not? > 3.2.2.2 Clients may request a subset of resources by > specifying the 'filter' URL query parameter containing a filter It seems like most of the spec uses double-quotes rather than single quotes= . Should this made consistent? --_000_5090514cb5e34810a3d46ef686e3d7b1BN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m going through the docs with a fine-toothed= comb.  Here are my comments so far … more to come later.

 

 

> 3.    POST  Create new reso= urces, create a search request, or bulk modify

>       resources.<= o:p>

 

The other HTTP method descriptions use "retriev= es", "modifies", "deletes".  Should this use = "creates"?

 

 

> 3.  | Schema     | /Sc= hemas           | GET (Se= ction  | Retrieve a      |

>     |   &nbs= p;        |     = ;            &n= bsp;  | 3.2.1)        | resource's&= nbsp;     |

>     |   &nbs= p;        |     = ;            &n= bsp;  |          &nb= sp;    | schema       &nb= sp;  |

 

I recommend changing the description to "Retrie= ve the supported schemas".

 

 

> 3.   Response and error codes SHOULD = be transmitted via the HTTP status

>      code of the respo= nse (if possible), and SHOULD also be specified in

>      the body of the r= esponse.

 

Currently response codes are only included in the bo= dy of the response for errors.  Also, is there any case where transmit= ting an HTTP status code is not possible?  I recommend changing to the= following:

 

       Response and er= ror codes MUST be transmitted via the HTTP status

       code of the res= ponse.  Errors MUST be included in the body of the

       response (see s= ection 3.10).

 

> 3.1  Clients that would like to override a=

>      server defaults, = MAY specify "null" for a single-valued attribute or

>      an empty array &q= uot;[]" for a multi-valued attribute to clear all values.

 

Should "defaults" be "default" h= ere?

 

 

> 3.1.1  the meta attribute

>        "= ;resourceType" SHALL be set by the service provider to the<= /p>

>        corre= sponding resource Type for the endpoint.

 

"resource Type" should be "resource t= ype" (lowercase)

 

 

> 3.2   Service providers MAY choose to= respond with a sub-set of

>       resource at= tributes, though MUST minimally return the resource id and

>       meta attrib= utes.

 

Now that we specify "returned" in the sche= ma (always/never/default/request), the first part of this sentence doesn't = make as much sense.  Perhaps this should be changed to mention the &qu= ot;returned" attribute.

 

 

> 3.2.2.1  A server MAY support searches aga= inst the server root (e.g.  "/").

 

Didn't we talk about adding something to ServiceProv= iderConfigs that indicates whether this is supported or not?

 

 

> 3.2.2.2  Clients may request a subset of r= esources by

>        =   specifying the 'filter' URL query parameter containing a filter=

 

It seems like most of the spec uses double-quotes ra= ther than single quotes.  Should this made consistent?

 

 

--_000_5090514cb5e34810a3d46ef686e3d7b1BN1PR04MB392namprd04pro_-- From nobody Mon Jul 21 16:14:07 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E4B1A0031 for ; Mon, 21 Jul 2014 16:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06GeLVeqFktU for ; Mon, 21 Jul 2014 16:14:05 -0700 (PDT) Received: from nm45-vm4.bullet.mail.bf1.yahoo.com (nm45-vm4.bullet.mail.bf1.yahoo.com [216.109.115.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7850D1A00FD for ; Mon, 21 Jul 2014 16:14:04 -0700 (PDT) Received: from [98.139.214.32] by nm45.bullet.mail.bf1.yahoo.com with NNFMP; 21 Jul 2014 23:14:03 -0000 Received: from [98.139.212.210] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 21 Jul 2014 23:14:03 -0000 Received: from [127.0.0.1] by omp1019.mail.bf1.yahoo.com with NNFMP; 21 Jul 2014 23:14:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 548138.79843.bm@omp1019.mail.bf1.yahoo.com Received: (qmail 36742 invoked by uid 60001); 21 Jul 2014 23:14:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1405984443; bh=/rbfE9Dv6Cbkj3JLD3SWQkwNaVr0PCLH5jQsQLrA9m8=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=2okQmLrsRzLFVoPyehfJw3G/siHXzWeAT2lEjSPycsUjXCgM24GcUxPK304G+oglxRDwz4jLP7BU5qd2vahIpeRDpMd+4Fx0jq04NjGFTFJwTD/RPdXnkGBaUpf9T0bYzkMDfeTA2eF95OZl5Mqdpbqq0QHGD0DcSkxjiLbcN1U= X-YMail-OSG: SrU.r2gVM1mxRs8B3HJ7IAPZSBvYMpLcb2iX5AFKVkir_Hw axcdeuj1WF46d..DlgNYymkZ0V6nZH9.JoSiKdZU3UCkyDmygIvd33V6csDF 8n0MPWgDUTlDab3ubg_V5vhvcIZqVZuGONBFKLAF9UlC9d7cIq_PEo3bl5e2 2zQXSfg2HL3pzImyt_LPauES8r0b7WMBuEyXmVPaftGkoezsRxnviGmB66d8 lCn6CNxDPb4Gcrp2m9oWdwX54fscTJ43RjLkuP55swTJz8QRjkgOOh0aJHrY n9HUSNoe1XhRKFONP.xRu5_haAhy1TlYgCzmd9g.Osw_JsSjvAxd0x1zCqsR jkjCKcqZOPiW_xPiiVUWvnJY.B8fRC2B6RLPVRsfAgI.Eg_WuFQd779Mbj.h 7v20U_OnxaeqMx4aPlfg1jOhh3R4aQ7MDGDSsclcBXjaLiiBtK6fVPsqbHJQ VzTboTJc3bo_RyLyhyqoj4Rt8XWnZNxgMYqZnkDjo55UP69I0JvKrZ30zUOK n2JqgkLn0_WGaqHpT9lC4wXkcqO5rC2KCpQ795arI2nKmxTAJL8UarwquISg Qh1jKL8V3a9VUviGFNByzpojZUid9DJFfXI_6kFHjBCgjjjzizlze9egZqeM xFa0Y9DVp5O8UXoBtqlwMqqBcBmvmeWIXmSqhFg.8PRD3lXR.9X3G Received: from [167.220.24.190] by web142802.mail.bf1.yahoo.com via HTTP; Mon, 21 Jul 2014 16:14:03 PDT X-Rocket-MIMEInfo: 002.001, V2UncmUgZ29pbmcgZG93biBhIHZlcnkgY29tcGxpY2F0ZWQgcGF0aCBoZXJlLiDCoElmIHlvdSBoYXZlIGEgc2VxdWVuY2Ugb2Ygb3BlcmF0aW9ucyB0aGF0IG5lZWQgdG8gaGFwcGVuLCBkbyB0aGV5IG5lZWQgdG8gYmUgYXRvbWljPyDCoFNob3VsZCB5b3Ugcm9sbCBiYWNrIHRoZSB1c2VyIGFkZCBpZiB0aGUgdXNlciBjYW4ndCBiZSBhZGRlZCB0byB0aGUgcmlnaHQgZ3JvdXBzPyDCoFRoZSBlcnJvciBoYW5kbGluZy9yZWNvdmVyeSBmcm9tICJzb21lIHN0dWZmIGZhaWxlZCIgZ2V0cyBwcmV0dHkgaGFpcnkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.195.683 References: <36A7B56D-EBF4-4208-AA3A-2DA7D118F8C2@oracle.com> Message-ID: <1405984443.86545.YahooMailNeo@web142802.mail.bf1.yahoo.com> Date: Mon, 21 Jul 2014 16:14:03 -0700 From: Bill Mills To: Phil Hunt , SCIM WG In-Reply-To: <36A7B56D-EBF4-4208-AA3A-2DA7D118F8C2@oracle.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1397251415-732788134-1405984443=:86545" Archived-At: http://mailarchive.ietf.org/arch/msg/scim/tjmTQTMTy-367hRfEel1xYhKQHk Subject: Re: [scim] Bulk request has a non-deterministic condition X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 23:14:06 -0000 --1397251415-732788134-1405984443=:86545 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable We're going down a very complicated path here. =A0If you have a sequence of= operations that need to happen, do they need to be atomic? =A0Should you r= oll back the user add if the user can't be added to the right groups? =A0Th= e error handling/recovery from "some stuff failed" gets pretty hairy. =A0It= 's SQL transactions with implicit commit and no rollback or transaction gro= uping. =A0If we need this kind of thing we should re-use an existing model.= =0A=0A=0AOn Monday, July 21, 2014 7:41 AM, Phil Hunt = wrote:=0A =0A=0A=0AThe following paragraph in Bulk was brought to my atten= tion as problematic:=0AThere can be more then one operation per resource in= each bulk job. The Service client MUST take notice of the unordered struct= ure of JSON and the service provider can process operations in any order. F= or example, if the Service client sends two PUT operations in one request, = the outcome is non-deterministic. =0A=0AFrom our perspective this makes Bul= k un-implementable, since other paragraphs seem to depend on serial process= ing (eg bulkId). Anybody have any background for this? It seems to come fro= m SCIM 1.=0A=0AIf we were to proceed with bulk, I would recommend striking = this paragraph.=0A=0APhil=0A=0A@independentid=0Awww.independentid.comphil.h= unt@oracle.com=0A=0A=0A=0A_______________________________________________= =0Ascim mailing list=0Ascim@ietf.org=0Ahttps://www.ietf.org/mailman/listinf= o/scim --1397251415-732788134-1405984443=:86545 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
We're going down a very complicated path here. &nb= sp;If you have a sequence of operations that need to happen, do they need t= o be atomic?  Should you roll back the user add if the user can't be a= dded to the right groups?  The error handling/recovery from "some stuf= f failed" gets pretty hairy.  It's SQL transactions with implicit comm= it and no rollback or transaction grouping.  If we need this kind of t= hing we should re-use an existing model.


On Monday, July 21, 2014 7:41 AM, Phil Hunt <phil.hunt@oracle.co= m> wrote:


The following paragraph in Bulk was brought to= my attention as problematic:
   There can be more t=
hen one operation per resource in each bulk job.=0A   The Service client MU=
ST take notice of the unordered structure of=0A   JSON and the service prov=
ider can process operations in any order.=0A   For example, if the Service =
client sends two PUT operations in one=0A   request, the outcome is non-det=
erministic.=0A

=0A
<= span class=3D"yiv6583115170Apple-style-span" style=3D"border-collapse: sepa= rate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font= -variant: normal; font-weight: normal; letter-spacing: normal; line-height:= normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: n= ormal; widows: 2; word-spacing: 0px; border-spacing: 0px;">
From our perspective this makes Bulk un-implementable, since other paragr= aphs seem to depend on serial processing (eg bulkId). Anybody have any back= ground for this? It seems to come from SCIM 1.

If = we were to proceed with bulk, I would recommend striking this paragraph.

Phil

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

<= /div>
=0A
=0A
<= /div>

_______________________________________________
sci= m mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim<= br>

--1397251415-732788134-1405984443=:86545-- From nobody Mon Jul 21 16:39:22 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EAF1A0299 for ; Mon, 21 Jul 2014 16:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGJHEIxpFIE0 for ; Mon, 21 Jul 2014 16:39:19 -0700 (PDT) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2231A0282 for ; Mon, 21 Jul 2014 16:39:18 -0700 (PDT) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 22 Jul 2014 01:39:07 +0200 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0847.030; Tue, 22 Jul 2014 01:39:01 +0200 From: =?Windows-1252?Q?Erik_Wahlstr=F6m?= To: Bill Mills Thread-Topic: [scim] Bulk request has a non-deterministic condition Thread-Index: AQHPpPEMFVmfcj1VekWZuyk4Z9ltJZurB4OAgAAG8wA= Date: Mon, 21 Jul 2014 23:39:01 +0000 Message-ID: References: <36A7B56D-EBF4-4208-AA3A-2DA7D118F8C2@oracle.com> <1405984443.86545.YahooMailNeo@web142802.mail.bf1.yahoo.com> In-Reply-To: <1405984443.86545.YahooMailNeo@web142802.mail.bf1.yahoo.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [94.234.170.213] Content-Type: multipart/alternative; boundary="_000_B0CE7ADC65A94DD0BD12406D7A590815nexusgroupcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/y6vVcfznYB1hXs8BRtM5MtpiYqk Cc: SCIM WG , Phil Hunt Subject: Re: [scim] Bulk request has a non-deterministic condition X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 23:39:21 -0000 --_000_B0CE7ADC65A94DD0BD12406D7A590815nexusgroupcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The solution for it is to keep the error handling very stupid/efficient. Fi= rst of it=92s not an atomic operation by the service provider. Secondly the= client can decide if the service provider should go on and keep on trying = to add resources or not using the failOnErrors attribute. The service provider MUST continue performing as many changes as possible and disregard partial failures. The client MAY override this behavior by specifying a value for failOnErrors attribute The important part of it all is the error codes returned for each job. It= =92s up to the client to see if all went well. If it did, the client can ca= ll it an =93atomic=94 operation, if it=92s not the client can rollback. It= =92s the exact same thing as the client has to do if bulk is not supported = and it had to do a bunch of request right? By the way, thanks for kicking the tires on it Bill. The more eyes, the bet= ter. Cheers Erik On 22 Jul 2014, at 01:14, Bill Mills > wrote: We're going down a very complicated path here. If you have a sequence of o= perations that need to happen, do they need to be atomic? Should you roll = back the user add if the user can't be added to the right groups? The erro= r handling/recovery from "some stuff failed" gets pretty hairy. It's SQL t= ransactions with implicit commit and no rollback or transaction grouping. = If we need this kind of thing we should re-use an existing model. --_000_B0CE7ADC65A94DD0BD12406D7A590815nexusgroupcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0F679BB94C3DD149B147B8FB388782BC@nexusgroup.com> Content-Transfer-Encoding: quoted-printable The solution for it is to keep the error handling very stupid/efficient. Fi= rst of it=92s not an atomic operation by the service provider. Secondly the= client can decide if the service provider should go on and keep on trying = to add resources or not using the failOnErrors attribute. 

   The service provider MUST continue=
 performing as many changes as
   possible and disregard partial failures.  The client MAY override
   this behavior by specifying a value for failOnErrors attribute

The important part of it all is the error codes returned for each job.= It=92s up to the client to see if all went well. If it did, the client can= call it an =93atomic=94 operation, if it=92s not the client can rollback. = It=92s the exact same thing as the client has to do if bulk is not supported and it had to do a bunch of request rig= ht?

By the way, thanks for kicking the tires on it Bill. The more eyes, th= e better.

Cheers
Erik


On 22 Jul 2014, at 01:14, Bill Mills <wmills_92105@yahoo.com> wrote:

We're going down a very complicated path here.  If you have= a sequence of operations that need to happen, do they need to be atomic? &= nbsp;Should you roll back the user add if the user can't be added to the ri= ght groups?  The error handling/recovery from "some stuff failed" gets pretty hairy.  It's SQL transactio= ns with implicit commit and no rollback or transaction grouping.  If w= e need this kind of thing we should re-use an existing model.


--_000_B0CE7ADC65A94DD0BD12406D7A590815nexusgroupcom_-- From nobody Mon Jul 21 21:16:28 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C7A1A03AD for ; Mon, 21 Jul 2014 21:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBVJ4ivF7NFA for ; Mon, 21 Jul 2014 21:16:22 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54B681A03CA for ; Mon, 21 Jul 2014 21:16:22 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6M4GKio002072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Jul 2014 04:16:21 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6M4GJFS012793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 22 Jul 2014 04:16:20 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6M4GJE0012785; Tue, 22 Jul 2014 04:16:19 GMT Received: from [172.16.54.146] (/206.47.221.210) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 21 Jul 2014 21:16:19 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_7296BD98-31DD-46D1-BCB3-DD9D47D8771D" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <5090514cb5e34810a3d46ef686e3d7b1@BN1PR04MB392.namprd04.prod.outlook.com> Date: Tue, 22 Jul 2014 00:16:11 -0400 Message-Id: References: <5090514cb5e34810a3d46ef686e3d7b1@BN1PR04MB392.namprd04.prod.outlook.com> To: Kelly Grizzle X-Mailer: Apple Mail (2.1878.6) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/7WoyFsC4B5DQukzFxVMY3GcIClA Cc: "scim@ietf.org" Subject: Re: [scim] API comments: start to 3.2.2.2 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 04:16:24 -0000 --Apple-Mail=_7296BD98-31DD-46D1-BCB3-DD9D47D8771D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Agree on all your points. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 21, 2014, at 6:28 PM, Kelly Grizzle = wrote: > I=92m going through the docs with a fine-toothed comb. Here are my = comments so far =85 more to come later. > =20 > =20 > > 3. POST Create new resources, create a search request, or bulk = modify > > resources. > =20 > The other HTTP method descriptions use "retrieves", "modifies", = "deletes". Should this use "creates"? > =20 > =20 > > 3. | Schema | /Schemas | GET (Section | Retrieve a = | > > | | | 3.2.1) | resource's = | > > | | | | schema = | > =20 > I recommend changing the description to "Retrieve the supported = schemas". > =20 > =20 > > 3. Response and error codes SHOULD be transmitted via the HTTP = status > > code of the response (if possible), and SHOULD also be = specified in > > the body of the response. > =20 > Currently response codes are only included in the body of the response = for errors. Also, is there any case where transmitting an HTTP status = code is not possible? I recommend changing to the following: > =20 > Response and error codes MUST be transmitted via the HTTP = status > code of the response. Errors MUST be included in the body of = the > response (see section 3.10). > =20 > > 3.1 Clients that would like to override a > > server defaults, MAY specify "null" for a single-valued = attribute or > > an empty array "[]" for a multi-valued attribute to clear all = values. > =20 > Should "defaults" be "default" here? > =20 > =20 > > 3.1.1 the meta attribute > > "resourceType" SHALL be set by the service provider to the > > corresponding resource Type for the endpoint. > =20 > "resource Type" should be "resource type" (lowercase) > =20 > =20 > > 3.2 Service providers MAY choose to respond with a sub-set of > > resource attributes, though MUST minimally return the resource = id and > > meta attributes. > =20 > Now that we specify "returned" in the schema = (always/never/default/request), the first part of this sentence doesn't = make as much sense. Perhaps this should be changed to mention the = "returned" attribute. > =20 > =20 > > 3.2.2.1 A server MAY support searches against the server root (e.g. = "/"). > =20 > Didn't we talk about adding something to ServiceProviderConfigs that = indicates whether this is supported or not? > =20 > =20 > > 3.2.2.2 Clients may request a subset of resources by > > specifying the 'filter' URL query parameter containing a = filter > =20 > It seems like most of the spec uses double-quotes rather than single = quotes. Should this made consistent? > =20 > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_7296BD98-31DD-46D1-BCB3-DD9D47D8771D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Agree = on all your points.


On Jul 21, 2014, at 6:28 PM, Kelly Grizzle = <kelly.grizzle@sailpoint.com> wrote:

I=92m going through = the docs with a fine-toothed comb.  Here are my comments so far =85 = more to come later.

 

 

> = 3.    POST  Create new resources, create a search = request, or bulk modify

>       = resources.

 

The other HTTP method descriptions use "retrieves", = "modifies", "deletes".  Should this use "creates"?

 

 

> = 3.  | Schema     | = /Schemas           | = GET (Section  | Retrieve a      = |

>     = |            = |            &= nbsp;       | = 3.2.1)        | = resource's      |

>     = |            = |            &= nbsp;       = |            &= nbsp;  | = schema          = |

 

I recommend changing the description to "Retrieve = the supported schemas".

 

 

> = 3.   Response and error codes SHOULD be transmitted via the = HTTP status

>      code of the = response (if possible), and SHOULD also be specified in

>      the body of the = response.

 

Currently response codes are only included in the = body of the response for errors.  Also, is there any case where = transmitting an HTTP status code is not possible?  I recommend = changing to the following:

 

       Response and = error codes MUST be transmitted via the HTTP status

       code of the = response.  Errors MUST be included in the body of = the

       response (see = section 3.10).

 

> = 3.1  Clients that would like to override a

>      server defaults, = MAY specify "null" for a single-valued attribute or

>      an empty array = "[]" for a multi-valued attribute to clear all values.

 

Should = "defaults" be "default" here?

 

 

> = 3.1.1  the meta attribute

>        = "resourceType" SHALL be set by the service provider to = the

>        = corresponding resource Type for the endpoint.

 

"resource = Type" should be "resource type" (lowercase)

 

 

> = 3.2   Service providers MAY choose to respond with a sub-set = of

>       resource = attributes, though MUST minimally return the resource id = and

>       meta = attributes.

 

Now that we specify "returned" in the schema = (always/never/default/request), the first part of this sentence doesn't = make as much sense.  Perhaps this should be changed to mention the = "returned" attribute.

 

 

> = 3.2.2.1  A server MAY support searches against the server root = (e.g.  "/").

 

Didn't = we talk about adding something to ServiceProviderConfigs that indicates = whether this is supported or not?

 

 

> = 3.2.2.2  Clients may request a subset of resources = by

>        &n= bsp; specifying the 'filter' URL query parameter containing a = filter

 

It seems like most of the spec uses double-quotes = rather than single quotes.  Should this made = consistent?

 

 

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

= --Apple-Mail=_7296BD98-31DD-46D1-BCB3-DD9D47D8771D-- From nobody Mon Jul 21 21:26:47 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0431A03D7 for ; Mon, 21 Jul 2014 21:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2Zpj8eXA-cC for ; Mon, 21 Jul 2014 21:26:44 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CF201A03E4 for ; Mon, 21 Jul 2014 21:26:44 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6M4QgTW025108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Jul 2014 04:26:43 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6M4QdYk028215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2014 04:26:40 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6M4QdTn005886; Tue, 22 Jul 2014 04:26:39 GMT Received: from dhcp-8ab1.meeting.ietf.org (/31.133.138.177) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 21 Jul 2014 21:26:39 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_D1C4B01F-7478-4352-BBFD-4FBE0D9AE75E" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: Date: Tue, 22 Jul 2014 00:19:28 -0400 Message-Id: <3259E082-B35A-4BC1-9011-21FB773CA205@oracle.com> References: <36A7B56D-EBF4-4208-AA3A-2DA7D118F8C2@oracle.com> <1405984443.86545.YahooMailNeo@web142802.mail.bf1.yahoo.com> To: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/uuakSbSjzLSYReIU12uzF-S7jm0 Cc: SCIM WG , William Mills Subject: Re: [scim] Bulk request has a non-deterministic condition X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 04:26:45 -0000 --Apple-Mail=_D1C4B01F-7478-4352-BBFD-4FBE0D9AE75E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Except for the erroneous point that JSON order can=92t be guaranteed = (which it can), I think the signalling and sequencing is very well = thought out. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 21, 2014, at 7:39 PM, Erik Wahlstr=F6m = wrote: > The solution for it is to keep the error handling very = stupid/efficient. First of it=92s not an atomic operation by the service = provider. Secondly the client can decide if the service provider should = go on and keep on trying to add resources or not using the failOnErrors = attribute. >=20 > The service provider MUST continue performing as many changes as > possible and disregard partial failures. The client MAY override > this behavior by specifying a value for failOnErrors attribute >=20 > The important part of it all is the error codes returned for each job. = It=92s up to the client to see if all went well. If it did, the client = can call it an =93atomic=94 operation, if it=92s not the client can = rollback. It=92s the exact same thing as the client has to do if bulk is = not supported and it had to do a bunch of request right? >=20 > By the way, thanks for kicking the tires on it Bill. The more eyes, = the better. >=20 > Cheers > Erik >=20 >=20 > On 22 Jul 2014, at 01:14, Bill Mills wrote: >=20 >> We're going down a very complicated path here. If you have a = sequence of operations that need to happen, do they need to be atomic? = Should you roll back the user add if the user can't be added to the = right groups? The error handling/recovery from "some stuff failed" gets = pretty hairy. It's SQL transactions with implicit commit and no = rollback or transaction grouping. If we need this kind of thing we = should re-use an existing model. >>=20 >=20 --Apple-Mail=_D1C4B01F-7478-4352-BBFD-4FBE0D9AE75E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Except = for the erroneous point that JSON order can=92t be guaranteed (which it = can), I think the signalling and sequencing is very well thought = out.

Phil

On Jul 21, 2014, at 7:39 PM, Erik Wahlstr=F6m <erik.wahlstrom@nexusgroup.co= m> wrote:

The solution for it is to keep the error handling very stupid/efficient. = First of it=92s not an atomic operation by the service provider. = Secondly the client can decide if the service provider should go on and = keep on trying to add resources or not using the failOnErrors attribute. 

   The service provider =
MUST continue performing as many changes as
   possible and disregard partial failures.  The client MAY override
   this behavior by specifying a value for failOnErrors attribute

The important part of it all is the error codes returned for each = job. It=92s up to the client to see if all went well. If it did, the = client can call it an =93atomic=94 operation, if it=92s not the client = can rollback. It=92s the exact same thing as the client has to do if bulk is not supported and it had to do a bunch of request = right?

By the way, thanks for kicking the tires on it Bill. The more eyes, = the better.

Cheers
Erik


On 22 Jul 2014, at 01:14, Bill Mills <wmills_92105@yahoo.com> = wrote:

We're going down a very complicated path here.  If you = have a sequence of operations that need to happen, do they need to be = atomic?  Should you roll back the user add if the user can't be = added to the right groups?  The error handling/recovery from "some stuff failed" gets pretty hairy.  It's SQL transactions with = implicit commit and no rollback or transaction grouping.  If we = need this kind of thing we should re-use an existing model.



= --Apple-Mail=_D1C4B01F-7478-4352-BBFD-4FBE0D9AE75E-- From nobody Tue Jul 22 10:35:35 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D45D1B2B09 for ; Tue, 22 Jul 2014 10:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSPbZmFdLabI for ; Tue, 22 Jul 2014 10:35:24 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 591E31B2B00 for ; Tue, 22 Jul 2014 10:35:22 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) with Microsoft SMTP Server (TLS) id 15.0.990.7; Tue, 22 Jul 2014 17:35:20 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.122]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.122]) with mapi id 15.00.0990.007; Tue, 22 Jul 2014 17:35:20 +0000 From: Kelly Grizzle To: "scim@ietf.org" Thread-Topic: API comments 3.2 to 3.5 Thread-Index: Ac+l0kclksEkRzUIQ9q/3QU75yblCg== Date: Tue, 22 Jul 2014 17:35:19 +0000 Message-ID: <196bcef840c7409fbdb33f5e05938403@BN1PR04MB392.namprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 0BADFD5E007AF40BADFEAB x-originating-ip: [208.54.40.200] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02801ACE41 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(229853001)(105586002)(76576001)(16236675004)(83322001)(15202345003)(46102001)(87936001)(19300405004)(19625215002)(21056001)(33646002)(19580395003)(2656002)(31966008)(99396002)(50986999)(2351001)(54356999)(66066001)(79102001)(83072002)(101416001)(81542001)(107886001)(77096002)(107046002)(110136001)(76482001)(74502001)(80022001)(81342001)(106356001)(99286002)(95666004)(64706001)(20776003)(85852003)(77982001)(19609705001)(74662001)(4396001)(92566001)(74316001)(15975445006)(85306003)(86362001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_196bcef840c7409fbdb33f5e05938403BN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/0PXaf7imRvZKC6kAdIWQRXrlRlA Subject: [scim] API comments 3.2 to 3.5 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 17:35:30 -0000 --_000_196bcef840c7409fbdb33f5e05938403BN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable More comments... still cranking through the API doc. > 3.2.2 "Resources":[ > { > "userName":"bjensen" > }, This example should include "id" and "meta" since they are always returned = (actually ... the example Schema in the schema doc doesn't say whether meta= is always returned ... is it?) > 3.2.2.2 filter=3Daddresses[state eq "CA" and rooms[type eq "bedroom" a= nd > number gt 2]] Should rooms be fully-qualified since it is in an extension (eg - urn:examp= le:schemas:hotel:User)? > 3.2.2.3 attribute type; i.e., for caee insensitive attributes, sort the Typo on "caee". > 3.2.2.3 The following table describes the query response pagination > attributes specified by the service provider. Should "specified" be "returned" here? > 3.2.2.3 | itemsPerPage | Non-negative Integer. Specifies the number of = | > | | search results returned in a query response pa= ge; | > | | e.g., 10. = | Can the server choose to return an itemsPerPage that differs from the "coun= t" that the client requested. For example, if the client requests 1000 res= ults, but the server only supports returning 100 at a time, could the serve= r return "itemsPerPage": 100? We should probably explicitly call out wheth= er this is allowed or not. > 3.2.2.5 The following attributes control which attributes SHALL be retur= ned > with a returned resource. Recommend changing this to: The following URL parameters control which attributes SHALL be returne= d with a returned resource. > 3.2.3 "Resources":[ ... This example should include the "id" attribute in the response since it is = always returned. > 3.3.1 Clients that would like to override a > server defaults, MAY specify "null" for a single-valued attribute = or > an empty array "[]" for a multi-valued attribute to clear all valu= es. Should "defaults" be "default" here? > 3.3.2.1 o If the target location does not exist, the attribute and valu= e is > added. > ... > o If the target location specifies an attribute that does not e= xist > (has no value), the attribute is added with the new value. It's not clear to me what the difference is between these two. > 3.3.2.1 The value MAY be a quoted value OR it may be > a JSON object containing the sub-attributes of the complex attrib= ute > specified in the operation's "path". This seems like it would just accept strings for simple attributes. Instea= d of "quoted value", maybe this should just say "simple value". > 3.2.2.2 If the target location is a complex-multi-valued attribute and = a Change this to "complex multi-valued" to be consistent with the rest of the= spec. The same term is used multiple times in this section. > 3.2.2.2 o If the target location is a complex-multi-valued attribute = and a > complex filter is specified based on the attribute's sub- > attributes, the matching records are removed. Is "matching records" referring to the "matching complex element"? I don't= know if "matching complex element" is the right term, but we might want to= tighten up the language here. In the examples below this is referred to a= s "Removal of a value from a complex-multi-valued attribute". Same comment= for section 3.3.2.3. > 3.2.2.2 Remove all members of a group: > ... > { "schemas": ["urn:scim:api:messages:2.0:PatchOp"], > "op":"remove","path":"members"} Formatting. Add newlines to format the JSON: { "schemas": ["urn:scim:api:messages:2.0:PatchOp"], "op":"remove", "path":"members" } Another question on the patch syntax. Some examples just have a single Pat= chOp in curly braces and some have an array of PatchOps. Are both syntaxes= supported? Also, should the "schemas" attribute on a PatchOp be on the to= p-level object, rather than inside each PatchOp element? For example: { "schemas": ["urn:scim:api:messages:2.0:PatchRequest"], "Operations": [ { "op": "remove", "path": "members" } ] } This example would be closer to the syntax for bulk requests. This would b= e my preference to keep single patches and multi-patches consistent. > 3.2.2.2 The following example shows how to replace all the members of = a group > with a different members list. > [ > { "schemas": ["urn:scim:api:messages:2.0:PatchOp"], > "op":"remove","path":"members"}, Formatting. > 3.3.2.3 o If the target location is a complex-multi-valued attribute w= ith a > complex filter and a specific sub-attribute (e.g. "addresse= s[type > eq "work"].streetAddress" ), the matching sub-attribute of t= he > matching record is replaced. Should "record" be "records" (or whatever terminology we land on) since the= path could match multiple values of the multi-valued attribute? > 3.3.2.3 The following example shows how to change a User's address. S= ince > address does not have a value Sub-Attribute, the existing addr= ess > must be removed and the modified address added. > ... > { > "schemas": ["urn:scim:api:messages:2.0:PatchOp"], > "op":"replace", > "path":"addresses[type eq \"work\"].streetAddress", > "value":"911 Universal City Plaza" > } Should the description be since we're not removing/adding: The following example shows how to change a User's street address. > 3.4 "code":"404" Many of the example error responses still use "code" instead of "status". = This should be changed to "status": 404. > 3.5 The following Complex Multi-valued Attribute is defined in additio= n > to the common attributes defined in core schema. Should just be "The following Complex Multi-valued Attribute is defined" si= nce there are no common multi-valued attributes in the core schema. --_000_196bcef840c7409fbdb33f5e05938403BN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

More comments… still cranking through the API = doc.

 

 

> 3.2.2     "Resources":[=

>         =   {

>         =      "userName":"bjensen"

>         =   },

 

This example should include "id" and "= ;meta" since they are always returned (actually ... the example Schema= in the schema doc doesn't say whether meta is always returned ... is it?)<= o:p>

 

 

> 3.2.2.2    filter=3Daddresses[state eq= "CA" and rooms[type eq "bedroom" and=

>         =    number gt 2]]

 

Should rooms be fully-qualified since it is in an ex= tension (eg - urn:example:schemas:hotel:User)?

 

 

> 3.2.2.3   attribute type; i.e., for caee in= sensitive attributes, sort the

 

Typo on "caee".

 

 

> 3.2.2.3   The following table describes the= query response pagination

>         =   attributes specified by the service provider.

 

Should "specified" be "returned"= here?

 

 

> 3.2.2.3   | itemsPerPage | Non-negative Int= eger. Specifies the number of      |

>         =   |           &= nbsp;  | search results returned in a query response page;  |

>         =   |           &= nbsp;  | e.g., 10.        &nbs= p;            &= nbsp;           &nbs= p;        |

 

Can the server choose to return an itemsPerPage that= differs from the "count" that the client requested.  For ex= ample, if the client requests 1000 results, but the server only supports re= turning 100 at a time, could the server return "itemsPerPage": 100?  We should probably explicitly call out whether this is allowed = or not.

 

 

> 3.2.2.5  The following attributes control which = attributes SHALL be returned

>         = with a returned resource.

 

Recommend changing this to:

 

     The following URL parameter= s control which attributes SHALL be returned

     with a returned resource.

 

> 3.2.3   "Resources":[ ...

 

This example should include the "id" attri= bute in the response since it is always returned.

 

 

> 3.3.1  Clients that would like to override a

>        server defa= ults, MAY specify "null" for a single-valued attribute or

>        an empty ar= ray "[]" for a multi-valued attribute to clear all values.

 

Should "defaults" be "default" h= ere?

 

 

> 3.3.2.1  o  If the target location does not= exist, the attribute and value is

>         =     added.

>         = ...

>         = o  If the target location specifies an attribute that does not exist<= o:p>

>         =     (has no value), the attribute is added with the new valu= e.

 

It's not clear to me what the difference is between = these two.

 

 

> 3.3.2.1 The value MAY be a quoted value OR it may be<= o:p>

>         a JSO= N object containing the sub-attributes of the complex attribute<= /span>

>         speci= fied in the operation's "path".

 

This seems like it would just accept strings for sim= ple attributes.  Instead of "quoted value", maybe this shoul= d just say "simple value".

 

 

> 3.2.2.2   If the target location is a compl= ex-multi-valued attribute and a

 

Change this to "complex multi-valued" to b= e consistent with the rest of the spec.  The same term is used multipl= e times in this section.

 

 

> 3.2.2.2    o  If the target locat= ion is a complex-multi-valued attribute and a

>         =       complex filter is specified based on the att= ribute's sub-

>         =       attributes, the matching records are removed= .

 

Is "matching records" referring to the &qu= ot;matching complex element"?  I don't know if "matching com= plex element" is the right term, but we might want to tighten up the l= anguage here.  In the examples below this is referred to as "Remo= val of a value from a complex-multi-valued attribute".  Same comment= for section 3.3.2.3.

 

 

> 3.2.2.2    Remove all members of a gro= up:

>         =    ...

>         =    { "schemas": ["urn:scim:api:messages:2.0:PatchO= p"],

>         =      "op":"remove","path"= :"members"}

 

Formatting.  Add newlines to format the JSON:

 

    {

      "schemas": = ["urn:scim:api:messages:2.0:PatchOp"],

      "op":"= remove",

      "path":&quo= t;members"

    }

 

 

Another question on the patch syntax.  Some exa= mples just have a single PatchOp in curly braces and some have an array of = PatchOps.  Are both syntaxes supported?  Also, should the "s= chemas" attribute on a PatchOp be on the top-level object, rather than inside each PatchOp element?  For example:

 

 {

    "schemas": ["urn:s= cim:api:messages:2.0:PatchRequest"],

    "Operations": [

      {

        "op&= quot;: "remove",

        "pat= h": "members"

      }

    ]

  }

 

This example would be closer to the syntax for bulk = requests.  This would be my preference to keep single patches and mult= i-patches consistent.

 

 

> 3.2.2.2    The following example shows= how to replace all the members of a group

>         =    with a different members list.

>         =    [

>         =      { "schemas": ["urn:scim:api:message= s:2.0:PatchOp"],

>         =        "op":"remove",&quo= t;path":"members"},

 

Formatting.

 

 

> 3.3.2.3   o  If the target location is= a complex-multi-valued attribute with a

>         =      complex filter and a specific sub-attribute (e.g.&= nbsp; "addresses[type

>         =      eq "work"].streetAddress" ), the ma= tching sub-attribute of the

>         =      matching record is replaced.

 

Should "record" be "records" (or= whatever terminology we land on) since the path could match multiple value= s of the multi-valued attribute?

 

 

> 3.3.2.3    The following example shows= how to change a User's address.  Since

>         =    address does not have a value Sub-Attribute, the existing addr= ess

>         =    must be removed and the modified address added.

>         =    ...

>         =    {

>         =      "schemas": ["urn:scim:api:messages:= 2.0:PatchOp"],

>         =      "op":"replace",

>         =      "path":"addresses[type eq \"wo= rk\"].streetAddress",

>         =      "value":"911 Universal City Plaza&q= uot;

>         =    }

 

Should the description be since we’re not remo= ving/adding:

 

    The following example shows how t= o change a User's street address.

 

> 3.4 "code":"404"

 

Many of the example error responses still use "= code" instead of "status".  This should be changed to &= quot;status": 404.

 

 

> 3.5    The following Complex Multi-val= ued Attribute is defined in addition

>        to the comm= on attributes defined in core schema.

 

Should just be "The following Complex Multi-val= ued Attribute is defined" since there are no common multi-valued attri= butes in the core schema.

--_000_196bcef840c7409fbdb33f5e05938403BN1PR04MB392namprd04pro_-- From nobody Thu Jul 31 15:47:21 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9966C1A02CF for ; Thu, 31 Jul 2014 15:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aU2NQ7jHeHDl for ; Thu, 31 Jul 2014 15:47:15 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDE5C1A02D0 for ; Thu, 31 Jul 2014 15:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3902; q=dns/txt; s=iport; t=1406846833; x=1408056433; h=from:to:subject:date:message-id:mime-version; bh=CLuRFP7Xg0hhSzn333pFe710ldXFNDMvmWx2rOoXjKI=; b=lf7gPazBWQA+M+ZNtDxsE7yLubNPsnMXHFPKxEETbw7D+a6FfwnHJzWs 0l7bHuzFuhNlAD6AwF/yFFmnTDY1EJ8Janq/DOb8cVcyn1tpAethsNj/b hobJ/uTAxeAud8rSTNuqOaJBrt8EpME8Bz5c60mQ6n7o5TMSYWCO9tbpH 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FADbH2lOtJA2H/2dsb2JhbABbgkdGgS3VcBZ3hAqBCwEMdCcEiFWkE6cMF5QeBZt0lFaDSYIx X-IronPort-AV: E=Sophos;i="5.01,775,1400025600"; d="scan'208,217";a="344229963" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-7.cisco.com with ESMTP; 31 Jul 2014 22:46:49 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6VMknVd015447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 31 Jul 2014 22:46:49 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.152]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Thu, 31 Jul 2014 17:46:49 -0500 From: "Morteza Ansari (moransar)" To: "scim@ietf.org" Thread-Topic: entitlements & roles attributes Thread-Index: AQHPrRFQ2HXe/o2TLEauzfwVHqmTXg== Date: Thu, 31 Jul 2014 22:46:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.155.85.11] Content-Type: multipart/alternative; boundary="_000_D0001567F35A2moransarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/34kluwBo9t8SssyygF9-le50rsU Subject: [scim] entitlements & roles attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 22:47:18 -0000 --_000_D0001567F35A2moransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Speaking as an implementer: In our implementation, we have a new use case where we need the entitlement= and roles attributes to be complex. This is for cases where a user has an = entitlement to a service with further qualifier. Similarly for the roles a= ttribute there are cases where a simple string is not sufficient and role m= ay require additional parameters and a complex object would nicely solve th= e problem. The spec is very vague on these two attributes intentionally because the au= thorization model at various vendors are so different that it seemed imposs= ible to come up with a single model to cover them all. As such the attribu= tes were left in the spec but they are essentially implementation specific. As this use case came up I was thinking about this and to be honest I am no= t sure why we have these in the core spec to begin with. If we don=92t def= ine the semantics of the attributes we are not helping with interoperabilit= y and if anything we make it more difficult for clients and vendors to do w= hat they need for these attributes. I would like to propose we drop these t= wo attributes from the core spec and implementors either add these as their= specific extensions. This also has a very nice benefit that if at some po= int we come up with a common model to handle entitlements, we could define = an extension to the core user object with its semantics well defined for in= teroperability. Thoughts? Cheers, Morteza --_000_D0001567F35A2moransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Speaking as an implementer:

In our implementation, we have a new use case where we need the entitl= ement and roles attributes to be complex. This is for cases where a user ha= s an entitlement to a service with further qualifier.  Similarly for t= he roles attribute there are cases where a simple string is not sufficient and role may require additional paramete= rs and a complex object would nicely solve the problem.

The spec is very vague on these two attributes intentionally because t= he authorization model at various vendors are so different that it seemed i= mpossible to come up with a single model to cover them all.  As such t= he attributes were left in the spec but they are essentially implementation specific.

As this use case came up I was thinking about this and to be honest I = am not sure why we have these in the core spec to begin with.  If we d= on=92t define the semantics of the attributes we are not helping with inter= operability and if anything we make it more difficult for clients and vendors to do what they need for these attr= ibutes. I would like to propose we drop these two attributes from the core = spec and implementors either add these as their specific extensions.  = This also has a very nice benefit that if at some point we come up with a common model to handle entitlements, we= could define an extension to the core user object with its semantics well = defined for interoperability.

Thoughts?


Cheers,
Morteza 
--_000_D0001567F35A2moransarciscocom_-- From nobody Thu Jul 31 15:59:59 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BD21A02BA for ; Thu, 31 Jul 2014 15:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tI_1ibgUymLR for ; Thu, 31 Jul 2014 15:59:51 -0700 (PDT) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3814A1A01D6 for ; Thu, 31 Jul 2014 15:59:50 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id q58so3460033wes.32 for ; Thu, 31 Jul 2014 15:59:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=XHOwWmjKJItn0xgMzRKlnRWHEVcP0oxU4xbSsKcg/L0=; b=FmsiGCwBRpu+pRpw22rGdXM+Xbxv6EL3uGmBufaKY0oo5/BENI6frOypQweTV7eupV NIoH7Vh+F764jx8W6lWgMxY85B4OBoDtmZEu2VJFpZYCjeMp3dIkzhQ0D+4PZ9lO0KsY MABSfYKQoez6rG/D8xSfPYfvMs8JSwnORPSlW16ScYRW7o411ZiqyThD4evcpI5Q4vYa XC6utn2b7hmoFCIn/TUR39vzYHu5Hbb77/8RMM18B3lU60vp+TLmYKZpZfE6cuLq+XOe 6HSfY1NK7ONCt6FXUlVk4CaOY51YDWgf7EK99Zg7u0RGsxQZZ99jJW9mRFLA5TVyopW+ bepA== X-Gm-Message-State: ALoCoQnIwvsB77Eai4zXIAkTNVSo/ZQRiN6x71JgQL02O2TkqZZ/oet2VvwsMEi0ZrvyjZ335UCB X-Received: by 10.180.12.76 with SMTP id w12mr1290298wib.4.1406847589653; Thu, 31 Jul 2014 15:59:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.27.71 with HTTP; Thu, 31 Jul 2014 15:59:29 -0700 (PDT) In-Reply-To: References: From: Ian Glazer Date: Thu, 31 Jul 2014 18:59:29 -0400 Message-ID: To: "Morteza Ansari (moransar)" Content-Type: multipart/alternative; boundary=001a11c23ef0d5d88c04ff853a5c Archived-At: http://mailarchive.ietf.org/arch/msg/scim/o2pfEdBwlVbQ9zgpKLAfb5RXl6Y Cc: "scim@ietf.org" Subject: Re: [scim] entitlements & roles attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 22:59:55 -0000 --001a11c23ef0d5d88c04ff853a5c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A fine can of worms you've cracked into ;-) I totally understand the need for complex attributes for roles. But I am little worried about the implications of dropping them from the core spec. Any thoughts on what the impact would be? On Thu, Jul 31, 2014 at 6:46 PM, Morteza Ansari (moransar) < moransar@cisco.com> wrote: > Speaking as an implementer: > > In our implementation, we have a new use case where we need the > entitlement and roles attributes to be complex. This is for cases where a > user has an entitlement to a service with further qualifier. Similarly f= or > the roles attribute there are cases where a simple string is not sufficie= nt > and role may require additional parameters and a complex object would > nicely solve the problem. > > The spec is very vague on these two attributes intentionally because the > authorization model at various vendors are so different that it seemed > impossible to come up with a single model to cover them all. As such the > attributes were left in the spec but they are essentially implementation > specific. > > As this use case came up I was thinking about this and to be honest I am > not sure why we have these in the core spec to begin with. If we don=E2= =80=99t > define the semantics of the attributes we are not helping with > interoperability and if anything we make it more difficult for clients an= d > vendors to do what they need for these attributes. I would like to propos= e > we drop these two attributes from the core spec and implementors either a= dd > these as their specific extensions. This also has a very nice benefit th= at > if at some point we come up with a common model to handle entitlements, w= e > could define an extension to the core user object with its semantics well > defined for interoperability. > > Thoughts? > > > Cheers, > Morteza > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --=20 Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --001a11c23ef0d5d88c04ff853a5c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A fine can of worms you've cracked into ;-)

I totally understand the need for complex attributes for roles. Bu= t I am little worried about the implications of dropping them from the core= spec. Any thoughts on what the impact would be?


On Thu,= Jul 31, 2014 at 6:46 PM, Morteza Ansari (moransar) <<= a href=3D"mailto:moransar@cisco.com" target=3D"_blank">moransar@cisco.com> wrote:
Speaking as an implementer:

In our implementation, we have a new use case where we need the entitl= ement and roles attributes to be complex. This is for cases where a user ha= s an entitlement to a service with further qualifier. =C2=A0Similarly for t= he roles attribute there are cases where a simple string is not sufficient and role may require additional paramete= rs and a complex object would nicely solve the problem.

The spec is very vague on these two attributes intentionally because t= he authorization model at various vendors are so different that it seemed i= mpossible to come up with a single model to cover them all. =C2=A0As such t= he attributes were left in the spec but they are essentially implementation specific.

As this use case came up I was thinking about this and to be honest I = am not sure why we have these in the core spec to begin with. =C2=A0If we d= on=E2=80=99t define the semantics of the attributes we are not helping with= interoperability and if anything we make it more difficult for clients and vendors to do what they need for these attr= ibutes. I would like to propose we drop these two attributes from the core = spec and implementors either add these as their specific extensions. =C2=A0= This also has a very nice benefit that if at some point we come up with a common model to handle entitlements, we= could define an extension to the core user object with its semantics well = defined for interoperability.

Thoughts?


Cheers,
Morteza=C2=A0

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




--
Ian Glazer
Senior Director, Identity
= +1 202 255 3166
--001a11c23ef0d5d88c04ff853a5c-- From nobody Thu Jul 31 16:03:57 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B5A1A0252 for ; Thu, 31 Jul 2014 16:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXUc5X2la0kN for ; Thu, 31 Jul 2014 16:03:44 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EC5C1A01FF for ; Thu, 31 Jul 2014 16:03:44 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6VN3g2j027788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 31 Jul 2014 23:03:43 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6VN3fND012168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jul 2014 23:03:42 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6VN3fTN026231; Thu, 31 Jul 2014 23:03:41 GMT Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 31 Jul 2014 16:03:41 -0700 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-E22045B6-CA79-4E83-852A-723CEF24689D Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D257) From: Phil Hunt Date: Thu, 31 Jul 2014 16:03:35 -0700 To: Ian Glazer X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/4YcxzeQ81oZOHCijwts90uf0PN0 Cc: "scim@ietf.org" , "Morteza Ansari \(moransar\)" Subject: Re: [scim] entitlements & roles attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 23:03:51 -0000 --Apple-Mail-E22045B6-CA79-4E83-852A-723CEF24689D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable One issue is that technically they are multi-valued attrs which means type i= s a valid sub attr that can be used.=20 This might catch some by surprise.=20 Phil > On Jul 31, 2014, at 15:59, Ian Glazer wrote: >=20 > A fine can of worms you've cracked into ;-) >=20 > I totally understand the need for complex attributes for roles. But I am l= ittle worried about the implications of dropping them from the core spec. An= y thoughts on what the impact would be? >=20 >=20 >> On Thu, Jul 31, 2014 at 6:46 PM, Morteza Ansari (moransar) wrote: >> Speaking as an implementer: >>=20 >> In our implementation, we have a new use case where we need the entitleme= nt and roles attributes to be complex. This is for cases where a user has an= entitlement to a service with further qualifier. Similarly for the roles a= ttribute there are cases where a simple string is not sufficient and role ma= y require additional parameters and a complex object would nicely solve the p= roblem. >>=20 >> The spec is very vague on these two attributes intentionally because the a= uthorization model at various vendors are so different that it seemed imposs= ible to come up with a single model to cover them all. As such the attribut= es were left in the spec but they are essentially implementation specific. >>=20 >> As this use case came up I was thinking about this and to be honest I am n= ot sure why we have these in the core spec to begin with. If we don=E2=80=99= t define the semantics of the attributes we are not helping with interoperab= ility and if anything we make it more difficult for clients and vendors to d= o what they need for these attributes. I would like to propose we drop these= two attributes from the core spec and implementors either add these as thei= r specific extensions. This also has a very nice benefit that if at some po= int we come up with a common model to handle entitlements, we could define a= n extension to the core user object with its semantics well defined for inte= roperability. >>=20 >> Thoughts? >>=20 >>=20 >> Cheers, >> Morteza=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 > --=20 > Ian Glazer > Senior Director, Identity > +1 202 255 3166 > @iglazer > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-E22045B6-CA79-4E83-852A-723CEF24689D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
One issue is that technically they are= multi-valued attrs which means type is a valid sub attr that can be used.&n= bsp;

This might catch some by surprise. 
Phil

On Jul 31, 2014, at 15:59, Ian Glazer <iglazer@salesforce.com> wrote:

A fine can of worms you'= ve cracked into ;-)

I totally understand the need for com= plex attributes for roles. But I am little worried about the implications of= dropping them from the core spec. Any thoughts on what the impact would be?=


On Thu, J= ul 31, 2014 at 6:46 PM, Morteza Ansari (moransar) <moransar@cisco.com&g= t; wrote:
Speaking as an implementer:

In our implementation, we have a new use case where we need the entitle= ment and roles attributes to be complex. This is for cases where a user has a= n entitlement to a service with further qualifier.  Similarly for the r= oles attribute there are cases where a simple string is not sufficient and role may require additional parameter= s and a complex object would nicely solve the problem.

The spec is very vague on these two attributes intentionally because th= e authorization model at various vendors are so different that it seemed imp= ossible to come up with a single model to cover them all.  As such the a= ttributes were left in the spec but they are essentially implementation specific.

As this use case came up I was thinking about this and to be honest I a= m not sure why we have these in the core spec to begin with.  If we don= =E2=80=99t define the semantics of the attributes we are not helping with in= teroperability and if anything we make it more difficult for clients and vendors to do what they need for these attri= butes. I would like to propose we drop these two attributes from the core sp= ec and implementors either add these as their specific extensions.  Thi= s also has a very nice benefit that if at some point we come up with a common model to handle entitlements, we c= ould define an extension to the core user object with its semantics well def= ined for interoperability.

Thoughts?


Cheers,
Morteza 

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




--
Ian Glazer
Senior Director, Identity
+1 2= 02 255 3166
____________________= ___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman= /listinfo/scim
= --Apple-Mail-E22045B6-CA79-4E83-852A-723CEF24689D-- From nobody Thu Jul 31 16:31:08 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66B31A02EF for ; Thu, 31 Jul 2014 16:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGRn38xRg669 for ; Thu, 31 Jul 2014 16:31:03 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F4971A02BA for ; Thu, 31 Jul 2014 16:31:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7916; q=dns/txt; s=iport; t=1406849464; x=1408059064; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Oy6kHAqvtPy56+xOG4ENMMl+TwbJl3FXhXZg3ZpsTLs=; b=OXA8GxlhX+aGaGz78eiEHY0erFZT/g8mt8QH8uFG1KXELBorPyFk38+7 pjzGn54Qyot4pztNCNRhQGMB4ViYLMG1bLG+I991Bpaoj3oohh4BBjnhH MEy0VT2lnK013JxNtQkvbi4kQzp32nKDUrpeUXanlr/RpYGVbyojbYsUo g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEFAEjR2lOtJV2R/2dsb2JhbABSBgOCR0ZSVwTNHAEJh0sBgQgWd4QDAQEBBAEBAWsLEAIBCA4DAwECKAcnCxQJCAIEDgWIQg3LIBMEjnFKAQwEBxGEOgWbdJRWg0lsgUU X-IronPort-AV: E=Sophos; i="5.01,775,1400025600"; d="scan'208,217"; a="65573409" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP; 31 Jul 2014 23:31:04 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6VNV2eK004159 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jul 2014 23:31:02 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.152]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Thu, 31 Jul 2014 18:31:02 -0500 From: "Morteza Ansari (moransar)" To: Ian Glazer Thread-Topic: [scim] entitlements & roles attributes Thread-Index: AQHPrRFQ2HXe/o2TLEauzfwVHqmTXpu7H9mA//+TcwA= Date: Thu, 31 Jul 2014 23:31:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.155.85.11] Content-Type: multipart/alternative; boundary="_000_D0001F7DF365Dmoransarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/QQM7-fD2jvCRblB1OBodXQaVzis Cc: "scim@ietf.org" Subject: Re: [scim] entitlements & roles attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 23:31:06 -0000 --_000_D0001F7DF365Dmoransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I don=92t think there is any impact as there is no interoperability possibl= e given the semantics of the attributes are undefined. How could a client p= rovision a value for this attribute if the definition of that value is diff= erent from SF to Cisco to the next vendor? Cheers, Morteza From: Ian Glazer > Date: Thursday, July 31, 2014 at 6:59 PM To: Morteza Ansari > Cc: "scim@ietf.org" > Subject: Re: [scim] entitlements & roles attributes A fine can of worms you've cracked into ;-) I totally understand the need for complex attributes for roles. But I am li= ttle worried about the implications of dropping them from the core spec. An= y thoughts on what the impact would be? On Thu, Jul 31, 2014 at 6:46 PM, Morteza Ansari (moransar) > wrote: Speaking as an implementer: In our implementation, we have a new use case where we need the entitlement= and roles attributes to be complex. This is for cases where a user has an = entitlement to a service with further qualifier. Similarly for the roles a= ttribute there are cases where a simple string is not sufficient and role m= ay require additional parameters and a complex object would nicely solve th= e problem. The spec is very vague on these two attributes intentionally because the au= thorization model at various vendors are so different that it seemed imposs= ible to come up with a single model to cover them all. As such the attribu= tes were left in the spec but they are essentially implementation specific. As this use case came up I was thinking about this and to be honest I am no= t sure why we have these in the core spec to begin with. If we don=92t def= ine the semantics of the attributes we are not helping with interoperabilit= y and if anything we make it more difficult for clients and vendors to do w= hat they need for these attributes. I would like to propose we drop these t= wo attributes from the core spec and implementors either add these as their= specific extensions. This also has a very nice benefit that if at some po= int we come up with a common model to handle entitlements, we could define = an extension to the core user object with its semantics well defined for in= teroperability. Thoughts? Cheers, Morteza _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --_000_D0001F7DF365Dmoransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7D9042949706384EA0AD1652F14A99E8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I don=92t think there is any impact as there is no interoperability po= ssible given the semantics of the attributes are undefined. How could a cli= ent provision a value for this attribute if the definition of that value is= different from SF to Cisco to the next vendor?


Cheers,
Morteza

From: Ian Glazer <iglazer@salesforce.com>
Date: Thursday, July 31, 2014 at 6:= 59 PM
To: Morteza Ansari <moransar@cisco.com>
Cc: "scim@ietf.org" <scim@i= etf.org>
Subject: Re: [scim] entitlements &a= mp; roles attributes

A fine can of worms you've cracked into ;-)

I totally understand the need for complex attributes for roles. But I = am little worried about the implications of dropping them from the core spe= c. Any thoughts on what the impact would be?


On Thu, Jul 31, 2014 at 6:46 PM, Morteza Ansari = (moransar) <moransar@cisco.com> wrote:
Speaking as an implementer:

In our implementation, we have a new use case where we need the entitl= ement and roles attributes to be complex. This is for cases where a user ha= s an entitlement to a service with further qualifier.  Similarly for t= he roles attribute there are cases where a simple string is not sufficient and role may require additional paramete= rs and a complex object would nicely solve the problem.

The spec is very vague on these two attributes intentionally because t= he authorization model at various vendors are so different that it seemed i= mpossible to come up with a single model to cover them all.  As such t= he attributes were left in the spec but they are essentially implementation specific.

As this use case came up I was thinking about this and to be honest I = am not sure why we have these in the core spec to begin with.  If we d= on=92t define the semantics of the attributes we are not helping with inter= operability and if anything we make it more difficult for clients and vendors to do what they need for these attr= ibutes. I would like to propose we drop these two attributes from the core = spec and implementors either add these as their specific extensions.  = This also has a very nice benefit that if at some point we come up with a common model to handle entitlements, we= could define an extension to the core user object with its semantics well = defined for interoperability.

Thoughts?


Cheers,
Morteza 

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




--
Ian Glazer
Senior Director, Identity
+1 202 255 3166
 --_000_D0001F7DF365Dmoransarciscocom_-- From nobody Thu Jul 31 16:33:13 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889691A02E6 for ; Thu, 31 Jul 2014 16:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_xxYUm3Gk-U for ; Thu, 31 Jul 2014 16:33:09 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24ED81A02BA for ; Thu, 31 Jul 2014 16:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9301; q=dns/txt; s=iport; t=1406849589; x=1408059189; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=d8SocMPEy360MeMvPUJOBOWUpNL7sap78Z5PP6nq1vw=; b=FL+55p1mB7GSq1qOrP2PfeFfsSx3lslK3ilqdswikNtmUkIFNVfhByJJ tMYu/Kne6iJ8buUpQOL96vlJO6PdvRXx3mWIymlViuDs1xgeDhls1ib+9 RmfzHkBP8b+Njwza5niAGi6B6oc6BxbYdftPibRvePYs5wtx8n2JujZ2/ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEFAEjR2lOtJA2K/2dsb2JhbABSBgOCR0ZSVwTNHAEJh0sBgQgWd4QDAQEBBAEBAWsLEAIBCBEDAQIoBycLFAkIAgQBDQWIQg3LIBMEjnFKAQwEBxGEOgWbdJRWg0lsgUU X-IronPort-AV: E=Sophos; i="5.01,775,1400025600"; d="scan'208,217"; a="65622195" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-3.cisco.com with ESMTP; 31 Jul 2014 23:33:08 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s6VNX8lY000760 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jul 2014 23:33:08 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.152]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Thu, 31 Jul 2014 18:33:08 -0500 From: "Morteza Ansari (moransar)" To: Phil Hunt , Ian Glazer Thread-Topic: [scim] entitlements & roles attributes Thread-Index: AQHPrRFQ2HXe/o2TLEauzfwVHqmTXpu7H9mAgAABJYD//5LnAA== Date: Thu, 31 Jul 2014 23:33:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.155.85.11] Content-Type: multipart/alternative; boundary="_000_D0001FE4F366Amoransarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/fkg_0U7gEAOUdMOP0ya9ILyQWQ0 Cc: "scim@ietf.org" Subject: Re: [scim] entitlements & roles attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 23:33:11 -0000 --_000_D0001FE4F366Amoransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes, given the vague nature of the definition in the spec one could impleme= nt this attribute as a complex but then the client is even in more of risk = as other than =93value=94 it knows nothing about the schema. And the schema= is not discoverable given it is not an extension. Cheers, Morteza From: Phil Hunt > Date: Thursday, July 31, 2014 at 7:03 PM To: Ian Glazer > Cc: Morteza Ansari >, "scim@i= etf.org" > Subject: Re: [scim] entitlements & roles attributes One issue is that technically they are multi-valued attrs which means type = is a valid sub attr that can be used. This might catch some by surprise. Phil On Jul 31, 2014, at 15:59, Ian Glazer > wrote: A fine can of worms you've cracked into ;-) I totally understand the need for complex attributes for roles. But I am li= ttle worried about the implications of dropping them from the core spec. An= y thoughts on what the impact would be? On Thu, Jul 31, 2014 at 6:46 PM, Morteza Ansari (moransar) > wrote: Speaking as an implementer: In our implementation, we have a new use case where we need the entitlement= and roles attributes to be complex. This is for cases where a user has an = entitlement to a service with further qualifier. Similarly for the roles a= ttribute there are cases where a simple string is not sufficient and role m= ay require additional parameters and a complex object would nicely solve th= e problem. The spec is very vague on these two attributes intentionally because the au= thorization model at various vendors are so different that it seemed imposs= ible to come up with a single model to cover them all. As such the attribu= tes were left in the spec but they are essentially implementation specific. As this use case came up I was thinking about this and to be honest I am no= t sure why we have these in the core spec to begin with. If we don=92t def= ine the semantics of the attributes we are not helping with interoperabilit= y and if anything we make it more difficult for clients and vendors to do w= hat they need for these attributes. I would like to propose we drop these t= wo attributes from the core spec and implementors either add these as their= specific extensions. This also has a very nice benefit that if at some po= int we come up with a common model to handle entitlements, we could define = an extension to the core user object with its semantics well defined for in= teroperability. Thoughts? Cheers, Morteza _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_D0001FE4F366Amoransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <436176E63A487A48B89ED7447BEA3F04@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Yes, given the vague nature of the definition in the spec one could im= plement this attribute as a complex but then the client is even in more of = risk as other than =93value=94 it knows nothing about the schema. And the s= chema is not discoverable given it is not an extension.


Cheers,
Morteza

From: Phil Hunt <phil.hunt@oracle.com>
Date: Thursday, July 31, 2014 at 7:= 03 PM
To: Ian Glazer <iglazer@salesforce.com>
Cc: Morteza Ansari <moransar@cisco.com>, "scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] entitlements &a= mp; roles attributes

One issue is that technically they are multi-valued attrs which means = type is a valid sub attr that can be used. 

This might catch some by surprise. 

Phil

On Jul 31, 2014, at 15:59, Ian Glazer <iglazer@salesforce.com> wrote:

A fine can of worms you've cracked into ;-)

I totally understand the need for complex attributes for roles. But I = am little worried about the implications of dropping them from the core spe= c. Any thoughts on what the impact would be?


On Thu, Jul 31, 2014 at 6:46 PM, Morteza Ansari = (moransar) <moransar@cisco.com> wrote:
Speaking as an implementer:

In our implementation, we have a new use case where we need the entitl= ement and roles attributes to be complex. This is for cases where a user ha= s an entitlement to a service with further qualifier.  Similarly for t= he roles attribute there are cases where a simple string is not sufficient and role may require additional paramete= rs and a complex object would nicely solve the problem.

The spec is very vague on these two attributes intentionally because t= he authorization model at various vendors are so different that it seemed i= mpossible to come up with a single model to cover them all.  As such t= he attributes were left in the spec but they are essentially implementation specific.

As this use case came up I was thinking about this and to be honest I = am not sure why we have these in the core spec to begin with.  If we d= on=92t define the semantics of the attributes we are not helping with inter= operability and if anything we make it more difficult for clients and vendors to do what they need for these attr= ibutes. I would like to propose we drop these two attributes from the core = spec and implementors either add these as their specific extensions.  = This also has a very nice benefit that if at some point we come up with a common model to handle entitlements, we= could define an extension to the core user object with its semantics well = defined for interoperability.

Thoughts?


Cheers,
Morteza 

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




--
Ian Glazer
Senior Director, Identity
+1 202 255 3166
_______________________________________________
scim mailing list
scim@ietf.org
https://www.ie= tf.org/mailman/listinfo/scim
 --_000_D0001FE4F366Amoransarciscocom_-- From nobody Thu Jul 31 19:31:50 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9711B1A03B1 for ; Thu, 31 Jul 2014 19:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAVkQ07a7vlx for ; Thu, 31 Jul 2014 19:31:44 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6469A1A038D for ; Thu, 31 Jul 2014 19:31:44 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) with Microsoft SMTP Server (TLS) id 15.0.995.14; Fri, 1 Aug 2014 02:31:43 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.41]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.41]) with mapi id 15.00.0995.014; Fri, 1 Aug 2014 02:31:43 +0000 From: Kelly Grizzle To: "Morteza Ansari (moransar)" , Ian Glazer Thread-Topic: [scim] entitlements & roles attributes Thread-Index: AQHPrRFQ2HXe/o2TLEauzfwVHqmTXpu6zAeAgAAI0ICAADDmcA== Date: Fri, 1 Aug 2014 02:31:42 +0000 Message-ID: <9aa56a2d1a8443e38705653f40a51997@BN1PR04MB392.namprd04.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 2E2AC341007C302E2AC48E x-originating-ip: [70.114.158.171] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 029097202E x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(24454002)(377454003)(21056001)(95666004)(92566001)(76576001)(19580405001)(83322001)(4396001)(83072002)(2656002)(19300405004)(87936001)(77982001)(85852003)(101416001)(19625215002)(64706001)(74662001)(66066001)(81542001)(20776003)(33646002)(76176999)(99396002)(54356999)(16236675004)(50986999)(79102001)(74316001)(86362001)(76482001)(19609705001)(46102001)(105586002)(80022001)(107046002)(15975445006)(99286002)(106116001)(19580395003)(74502001)(15202345003)(106356001)(31966008)(19617315012)(77096002)(81342001)(85306004)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB392; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_9aa56a2d1a8443e38705653f40a51997BN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/tUyFdrY5V5y4AKHKUZCWEZv77sE Cc: "scim@ietf.org" Subject: Re: [scim] entitlements & roles attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 02:31:48 -0000 --_000_9aa56a2d1a8443e38705653f40a51997BN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not sure that I would say that there is no interoperability. The clien= t just has to have some knowledge about what the server supports for values= here (maybe through /Entitlements and /Roles extended resource types?). O= f course, the same values probably wouldn't work on both SF and Cisco serve= rs. I agree with you, though, that complex attributes are warranted for some ca= ses of roles and entitlements. I'd be interested to hear from some of the = folks that have implemented SCIM servers if they make use of these or wheth= er they would have any opposition to dropping them. IIRC they were added because it was thought that most SPs would have some n= otion of roles, entitlements, groups, or some combination of them, and that= if they were left out of the schema that there would be more interop probl= ems because everyone would have custom extensions for these. What's the lesser of the evils? To have an underspecified standard attribu= te or a non-specified custom attribute that a bunch of folks will probably = want to use? From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (mora= nsar) Sent: Thursday, July 31, 2014 6:31 PM To: Ian Glazer Cc: scim@ietf.org Subject: Re: [scim] entitlements & roles attributes I don't think there is any impact as there is no interoperability possible = given the semantics of the attributes are undefined. How could a client pro= vision a value for this attribute if the definition of that value is differ= ent from SF to Cisco to the next vendor? Cheers, Morteza From: Ian Glazer > Date: Thursday, July 31, 2014 at 6:59 PM To: Morteza Ansari > Cc: "scim@ietf.org" > Subject: Re: [scim] entitlements & roles attributes A fine can of worms you've cracked into ;-) I totally understand the need for complex attributes for roles. But I am li= ttle worried about the implications of dropping them from the core spec. An= y thoughts on what the impact would be? On Thu, Jul 31, 2014 at 6:46 PM, Morteza Ansari (moransar) > wrote: Speaking as an implementer: In our implementation, we have a new use case where we need the entitlement= and roles attributes to be complex. This is for cases where a user has an = entitlement to a service with further qualifier. Similarly for the roles a= ttribute there are cases where a simple string is not sufficient and role m= ay require additional parameters and a complex object would nicely solve th= e problem. The spec is very vague on these two attributes intentionally because the au= thorization model at various vendors are so different that it seemed imposs= ible to come up with a single model to cover them all. As such the attribu= tes were left in the spec but they are essentially implementation specific. As this use case came up I was thinking about this and to be honest I am no= t sure why we have these in the core spec to begin with. If we don't defin= e the semantics of the attributes we are not helping with interoperability = and if anything we make it more difficult for clients and vendors to do wha= t they need for these attributes. I would like to propose we drop these two= attributes from the core spec and implementors either add these as their s= pecific extensions. This also has a very nice benefit that if at some poin= t we come up with a common model to handle entitlements, we could define an= extension to the core user object with its semantics well defined for inte= roperability. Thoughts? Cheers, Morteza _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --_000_9aa56a2d1a8443e38705653f40a51997BN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m not sure that I= would say that there is no interoperability.  The client just has to = have some knowledge about what the server supports for values here (maybe through /Entitlements and /Roles extended resource types?).  O= f course, the same values probably wouldn’t work on both SF and Cisco= servers.

 <= /p>

I agree with you, though,= that complex attributes are warranted for some cases of roles and entitlem= ents.  I’d be interested to hear from some of the folks that have implemented SCIM servers if they make use of these or whether th= ey would have any opposition to dropping them.

 <= /p>

IIRC they were added beca= use it was thought that most SPs would have some notion of roles, entitleme= nts, groups, or some combination of them, and that if they were left out of the schema that there would be more interop problems beca= use everyone would have custom extensions for these.


What’s the lesser of the evils?  To have an underspecified stand= ard attribute or a non-specified custom attribute that a bunch of folks wil= l probably want to use?

 <= /p>

From: scim [ma= ilto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (moransar)
Sent: Thursday, July 31, 2014 6:31 PM
To: Ian Glazer
Cc: scim@ietf.org
Subject: Re: [scim] entitlements & roles attributes

 

I don’t think there i= s any impact as there is no interoperability possible given the semantics o= f the attributes are undefined. How could a client provision a value for this attribute if the definition of that value is different from= SF to Cisco to the next vendor?

 

 

Cheers,

Morteza

 

From: Ian Glazer <iglazer@salesforce.com>
Date: Thursday, July 31, 2014 at 6:59 PM
To: Morteza Ansari <moransa= r@cisco.com>
Cc: "scim@ietf.org" &= lt;scim@ietf.org>
Subject: Re: [scim] entitlements & roles attributes

 

A fine can of worms you've = cracked into ;-)

 

I totally understand the ne= ed for complex attributes for roles. But I am little worried about the impl= ications of dropping them from the core spec. Any thoughts on what the impact would be?

 

On Thu, Jul 31, 2014 at 6:4= 6 PM, Morteza Ansari (moransar) <moransar@cisco.com> wrote:

Speaking as an implementer:=

 

In our implementation, we h= ave a new use case where we need the entitlement and roles attributes to be= complex. This is for cases where a user has an entitlement to a service with further qualifier.  Similarly for the roles attribu= te there are cases where a simple string is not sufficient and role may req= uire additional parameters and a complex object would nicely solve the prob= lem.

 

The spec is very vague on t= hese two attributes intentionally because the authorization model at variou= s vendors are so different that it seemed impossible to come up with a single model to cover them all.  As such the attribute= s were left in the spec but they are essentially implementation specific.

 

As this use case came up I = was thinking about this and to be honest I am not sure why we have these in= the core spec to begin with.  If we don’t define the semantics of the attributes we are not helping with interoperability and if anything= we make it more difficult for clients and vendors to do what they need for= these attributes. I would like to propose we drop these two attributes fro= m the core spec and implementors either add these as their specific extensions.  This also has a very = nice benefit that if at some point we come up with a common model to handle= entitlements, we could define an extension to the core user object with it= s semantics well defined for interoperability.

 

Thoughts?=

 

 

Cheers,

Morteza 


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



 

--

Ian Glazer

Senior Director, Identity

+1 202 255 3166

--_000_9aa56a2d1a8443e38705653f40a51997BN1PR04MB392namprd04pro_-- From nobody Thu Jul 31 20:13:19 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6663B1A03BB for ; Thu, 31 Jul 2014 20:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqVuHhlTp12r for ; Thu, 31 Jul 2014 20:13:07 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0E3B1A03AD for ; Thu, 31 Jul 2014 20:13:06 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) with Microsoft SMTP Server (TLS) id 15.0.995.14; Fri, 1 Aug 2014 03:13:04 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.41]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.41]) with mapi id 15.00.0995.014; Fri, 1 Aug 2014 03:13:05 +0000 From: Kelly Grizzle To: "scim@ietf.org" Thread-Topic: API comments section 3.5 to end Thread-Index: Ac+tNkYNgCkVDMQIQ5aEZFBnkTXrfw== Date: Fri, 1 Aug 2014 03:13:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 2E50A546007C302E50A693 x-originating-ip: [70.114.158.171] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 029097202E x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(51704005)(199002)(77096002)(20776003)(92566001)(19300405004)(101416001)(99396002)(74662001)(83322001)(19580395003)(64706001)(31966008)(83072002)(107046002)(2656002)(85852003)(15975445006)(46102001)(19609705001)(15202345003)(19625215002)(33646002)(95666004)(66066001)(16236675004)(87936001)(79102001)(229853001)(99286002)(77982001)(86362001)(4396001)(105586002)(81542001)(50986999)(110136001)(81342001)(76576001)(107886001)(2351001)(74502001)(54356999)(74316001)(76482001)(106356001)(80022001)(21056001)(85306004)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_d0dd7710557e49e4877c8e6d9c850a9fBN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/VhKfXElwUa3u7DAAoYWHNan13o0 Subject: [scim] API comments section 3.5 to end X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 03:13:15 -0000 --_000_d0dd7710557e49e4877c8e6d9c850a9fBN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Last set of comments for the API doc. > 3.5 status A complex type that contains information about the success > or failure of one operation within the bulk job. REQUIRED i= n a > response. > > code The HTTP response code that would have been returned i= f a > a single HTTP request would have been used. REQUIRED. > > description A human readable error message. REQUIRED when = an > error occurred. Should the bulk response status attribute be updated to be more in line wit= h the updated error response (status, scimType, and detail sub-attributes)? > 3.5 If a bulk job is processed successfully the HTTP response code 200= OK > MUST be returned, otherwise an appropriate HTTP error code MUST be > returned. A 200 is returned even if some of the operations failed, correct? Might be= worth clarifying. > 3.5 The client MAY override > this behavior by specifying a value for failOnErrors attribute. Change to "for the failOnErrors attribute". > 3.5 A location attribute that includes the > resource's end point MUST be returned for all operations excluding > failed POSTs. Typo. Change "end point" to "endpoint". > 3.5 The following example shows how to add, update, and remove a user. > ... > The service provider returns the following response. > ... > { > "location": "https://example.com/v2/Users/92b725cd-9465-4e7d-= 8c16-01f8e146b87a", > "method": "POST", > "bulkId": "qwerty", > "version": "W\/\"oY4m4wn58tkVjJxK\"", > "status": { > "code": "201" > } > }, The text above says the following regarding creating a new resource: the service provider MUST return the same bulkId together with the newly created resource. It seems like the example response should include the full resource. Would= this fit in the "data" sub-attribute? If so, the description of the "data= " sub-attribute should be changed to indicate this. Same comment for other= bulk examples that contain POSTs. > 3.5 The following example creates a User with the userName 'Alice' and a > Group with the displayName 'Tour Guides' with Alice as a member. > ... > "members": [ > { > "type": "user", > "value": "bulkId:qwerty" > } > ] The type should be "User" since the canonical values for type on member are= capitalized (see schema in section 11.7 of schemas draft). > 3.5 "members": [ > { > "type": "group", Same comment as above ... need to capitalize "Group". > 3.5 The following example the client sent a request exceeding the servic= e > provider's max payload size of 1 megabyte. > ... > HTTP/1.1 413 Request Entity Too Large > Content-Type: application/scim+json > Location: https://example.com/v2/Bulk/yfCrVJhFIJagAHj8 This response includes a Location header with a unique ID. Do bulk request= s have unique IDs and locations? If not, the location should be removed > 3.6 MAY specify the desired response data > format via an HTTP "Accept" header ( Section 5.3.2 [RFC7231] ); e.g., > "Accept: application/scim+json" or via URI suffix; e.g., > > GET /Users/2819c223-7f76-453a-919d-413861904646.scim It seems like we shouldn't need to support URI suffixes anymore since JSON = is the only supported format. > 3.7 The defaut attribute set are those attributes whose schema have Typo on "defaut". > 3.7 GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=3Duser= Name > ... > Accept: application/json > ... > HTTP/1.1 200 OK > Content-Type: application/json This example uses application/json for the Accept and Content-Type headers.= Should change this to application/scim+json. > 3.10 The following attributes are defined inclusion in a SCIM error resp= onse > using a JSON body: Not sure what the text is supposed to be here, but "defined inclusion" does= n't make sense to me. Maybe "The following attributes are included in a SC= IM error response using a JSON body"? > 3.10 status > The HTTP status value (e.g. 400). REQUIRED We should indicate that this is an integer. > 3.10 Implementers SHOULD handle the identified errors as described bel= ow 307 and 308 statuses are not really errors. Should they be included here? > 3.10 tooMany a filter such as "userName eq "*"" would return all entri= es with a "userName" The wildcard operator is not supported. This filter should be "userName pr= ". > 3.12 Content-Type: application/json Examples in this section are not using application/scim+json for Content-Ty= pe. > 6.2 A detialed error, > "confidential_restricted" may be returned indicating the request mus= t > be submitted using POST. Typo on "detialed". Also, should this error code be made into a scimType a= nd use the camelCase convention used for other scimTypes? The example in t= his section could be rewritten as: { "schemas": ["urn:scim:api:messages:2.0:Error"], "scimType":"confidentialRestricted" "detail":"Query filter involving 'name' is restricted or confidential"= , "status":403 } > 7.1 SCIM services may be offered by web applications wishin to offer Typo on "wishin". --_000_d0dd7710557e49e4877c8e6d9c850a9fBN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Last set of comments for the API doc.

 

> 3.5  status  A complex type that cont= ains information about the success

>        =       or failure of one operation within the bulk = job.  REQUIRED in a

>        =       response.

> 

>        =       code  The HTTP response code that would= have been returned if a

>        =          a single HTTP request woul= d have been used.  REQUIRED.

> 

>        =       description  A human readable error mes= sage.  REQUIRED when an

>        =          error occurred.=

 

Should the bulk response status attribute be updated= to be more in line with the updated error response (status, scimType, and = detail sub-attributes)?

 

 

> 3.5    If a bulk job is processe= d successfully the HTTP response code 200 OK

>        MUST = be returned, otherwise an appropriate HTTP error code MUST be

>        retur= ned.

 

A 200 is returned even if some of the operations fai= led, correct?  Might be worth clarifying.

 

 

> 3.5 The client MAY override

>     this behavior by specif= ying a value for failOnErrors attribute.

 

Change to "for the failOnErrors attribute"= .

 

 

> 3.5 A location attribute that includes the=

>     resource's end point MU= ST be returned for all operations excluding

>     failed POSTs.

 

Typo.  Change "end point" to "en= dpoint".

 

 

> 3.5  The following example shows how to ad= d, update, and remove a user.

>      ...

>      The service provi= der returns the following response.

>      ...

>        = {

>        =      "location": "https://example.com/v2= /Users/92b725cd-9465-4e7d-8c16-01f8e146b87a",

>        =      "method": "POST",

>        =      "bulkId": "qwerty",=

>        =      "version": "W\/\"oY4m4wn58tkVj= JxK\"",

>        =      "status": {

>        =          "code": "20= 1"

>        =      }

>        = },

 

The text above says the following regarding creating= a new resource:

 

  the service provider MUST return the same bul= kId together with the newly

  created resource.

 

It seems like the example response should include th= e full resource.  Would this fit in the "data" sub-attribute= ?  If so, the description of the "data" sub-attribute should= be changed to indicate this.  Same comment for other bulk examples that contain POSTs.

 

 

> 3.5  The following example creates a User = with the userName 'Alice' and a

>      Group with the di= splayName 'Tour Guides' with Alice as a member.

>      ...

>        =     "members": [

>        =      {

>        =        "type": "user",

>        =        "value": "bulkId:qwerty= "

>        =      }

>        =    ]

 

The type should be "User" since the canoni= cal values for type on member are capitalized (see schema in section 11.7 o= f schemas draft).

 

 

> 3.5       &n= bsp;    "members": [

>        =        {

>        =          "type": "gr= oup",

 

Same comment as above ... need to capitalize "G= roup".

 

 

> 3.5  The following example the client sent= a request exceeding the service

>      provider's max pa= yload size of 1 megabyte.

>      ...

>      HTTP/1.1 413 Requ= est Entity Too Large

>      Content-Type: app= lication/scim+json

>      Location: https:/= /example.com/v2/Bulk/yfCrVJhFIJagAHj8

 

This response includes a Location header with a uniq= ue ID.  Do bulk requests have unique IDs and locations?  If not, = the location should be removed

 

 

> 3.6 MAY specify the desired response data<= /o:p>

>     format via an HTTP &quo= t;Accept" header ( Section 5.3.2 [RFC7231] ); e.g.,

>     "Accept: applicati= on/scim+json" or via URI suffix; e.g.,

> 

>      GET /Users/2819c2= 23-7f76-453a-919d-413861904646.scim

 

It seems like we shouldn't need to support URI suffi= xes anymore since JSON is the only supported format.

 

 

> 3.7   The defaut attribute set are th= ose attributes whose schema have

 

Typo on "defaut".

 

 

> 3.7     GET /Users/2819c223= -7f76-453a-919d-413861904646?attributes=3DuserName

>        = ...

>        = Accept: application/json

>        = ...

>        = HTTP/1.1 200 OK

>        = Content-Type: application/json

 

This example uses application/json for the Accept an= d Content-Type headers.  Should change this to application/scim+js= on.

 

 

> 3.10  The following attributes are defined= inclusion in a SCIM error response

>       using a JSO= N body:

 

Not sure what the text is supposed to be here, but &= quot;defined inclusion" doesn't make sense to me.  Maybe “T= he following attributes are included in a SCIM error response using a JSON = body”?

 

 

> 3.10  status

>        = The HTTP status value (e.g. 400).  REQUIRED

 

We should indicate that this is an integer.

 

 

> 3.10    Implementers SHOULD hand= le the identified errors as described below

 

307 and 308 statuses are not really errors.  Sh= ould they be included here?

 

 

> 3.10  tooMany   a filter such as= "userName eq "*"" would return all entries with a &quo= t;userName"

 

The wildcard operator is not supported.  This f= ilter should be "userName pr".

 

 

> 3.12    Content-Type:  appl= ication/json

 

Examples in this section are not using application/s= cim+json for Content-Type.

 

 

> 6.2  A detialed error,

>      "confidentia= l_restricted" may be returned indicating the request must

>      be submitted usin= g POST.

 

Typo on "detialed".  Also, should thi= s error code be made into a scimType and use the camelCase convention used = for other scimTypes?  The example in this section could be rewritten a= s:

 

   {

     "schemas": ["= ;urn:scim:api:messages:2.0:Error"],

     "scimType":"= confidentialRestricted"

     "detail":"Qu= ery filter involving 'name' is restricted or confidential",=

     "status":403=

   }

 

 

> 7.1 SCIM services may be offered by web applica= tions wishin to offer

 

Typo on "wishin".

 

--_000_d0dd7710557e49e4877c8e6d9c850a9fBN1PR04MB392namprd04pro_--