From nobody Wed Oct 3 08:37:19 2018 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983AA1312D3 for ; Wed, 3 Oct 2018 08:37:17 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=curity-io.20150623.gappssmtp.com 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 T9irFSDxnxOZ for ; Wed, 3 Oct 2018 08:37:16 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E212D1312E7 for ; Wed, 3 Oct 2018 08:37:15 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id n1-v6so6656402wrt.10 for ; Wed, 03 Oct 2018 08:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=curity-io.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=kuDb4BwHXBXm8vY7CDDPsCwtmoFbZ4o5h88PI3+/N4E=; b=qC9A8RbGaLwZgDrX/vS5W3dbFCgVX0/R2TJsySPTLpJ6OyKW2bwp1B1cHXF+seeUWq rCHUzTS4IpeZMpuDxD12CvHTSHmBjaw794F8l0Xxxi7LSX3QBCiY2ITJsqSrQyrw9g8l CfV086z6cNAbuvap1Z2Qp5s2WYCb0NFLGJgmgMxf0U70AzQOdySWpYxsEzMnlycTNdV5 vyytqki52prLXag6tFaEohjNi00aLRigva1q7N+4ftMhxox02cXIT4EdLgC3VD0s3kmM jWtWv12M3Hy3WWmPRyaH0iO4l0mhlPdSRxtJy05KtSPcyfqZLGpfyqUeV/Yj+jUkP9Hn PIUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=kuDb4BwHXBXm8vY7CDDPsCwtmoFbZ4o5h88PI3+/N4E=; b=IYWjX67YET9poFVcPaTs3q42hejpqB9evjjOr09i3oDrRDXdZTQVp6DjQ3hhDYNaI5 P92X06Bu18inrtWdeBs/huf+0kM3Vx7ApZ9qo/dBkPs9nnPJKhyq/57SMFcLwjPTQJx4 ars3KlEQxQ76KnZR6yEHEXncVw5hCrPJnXDnRDotTMTNnh7SyziTF5JeejKN58OO+oOQ AxNlri0EwCN3OOprBiFOSTOxwBxpBaC2q6/ThzSKAZOzZkKdZdp2jrOaX1ZXbAdKdnfU cm8Gu5neu6cW8tNiH/DkcVH60viwXCyef6BLEGQgoZcqPOFbzU3vE4hkIF68nHgA6dd8 1dlg== X-Gm-Message-State: ABuFfogAz5fWnYeAMnGtBdnF5xKAAVk+hiRX4iaEbaNsFeM5WymUD5VQ topr0kRhRDH3FVXDOhg9uKjsOIKQK78= X-Google-Smtp-Source: ACcGV63wyuVJFqwl3OgLgtIueMu7tpyBjfT0BrxA0b37WbLnmDFaHx4XtalI8LEBnomKYFXepxF0Ww== X-Received: by 2002:adf:b211:: with SMTP id u17-v6mr1683502wra.180.1538581033973; Wed, 03 Oct 2018 08:37:13 -0700 (PDT) Received: from speedyM.local ([2a02:a446:bd2c:1:c9c8:cee8:a506:4c64]) by smtp.gmail.com with ESMTPSA id t2-v6sm2426541wrr.7.2018.10.03.08.37.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Oct 2018 08:37:13 -0700 (PDT) To: scim@ietf.org From: Mark Dobrinic Message-ID: <370d231f-1041-5d28-f097-38882481a256@curity.io> Date: Wed, 3 Oct 2018 17:37:07 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [scim] Escape search filter values X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 15:37:18 -0000 Hi scim, I've got a question on how to escape values that are part of the search filter query in scim 2. For example, when sending out a search request for a user with a password, we're posting a JSON-message like this to our SCIM server: {     "schemas": [         "urn:ietf:params:scim:api:messages:2.0:SearchRequest"     ],     "filter": "userName eq \"teddie\" and password eq "\secret\"" } But when the password contains control characters, like a double-quote (") or backslash (\), what should we send to the other end? For now, we've been following the JSON approach, and are JSON-escaping the values inside the filter, such that when the password would be 'sec"ret', the JSON-message as it would be sent over becomes: {     "schemas": [         "urn:ietf:params:scim:api:messages:2.0:SearchRequest"     ],     "filter": "userName eq \"teddie\" and password eq "\sec\\\"ret\"" } ... but I could not find out how to deal with this in the spec. What do you think is the right thing to do here? -- Regards, Mark Dobrinic Software Engineer and Identity Specialist Curity AB mark.dobrinic@curity.io www.curity.io From nobody Thu Oct 4 11:40:00 2018 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF8512426A for ; Thu, 4 Oct 2018 11:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.767 X-Spam-Level: X-Spam-Status: No, score=-2.767 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 Q6u6xJdbMIgA for ; Thu, 4 Oct 2018 11:39:54 -0700 (PDT) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 7086E128D0C for ; Thu, 4 Oct 2018 11:39:54 -0700 (PDT) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w94IdPBI118984; Thu, 4 Oct 2018 18:39:51 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2018-07-02; bh=W0USugvUYZX2imhWxAjwpMJsuN6e0NTxkUoSjoVFg/E=; b=rhcTqqXD8RmfPKwWWhZVI7Jbx1+DWk2DAKoP0zmAq4zMOE4fiRGoxpldFfEhPtUrdSHZ G/hTIuaQywGKjKf3WvFohUmtfuDf27xU7LqWIv5seq9XOf6A43qk+cSMnMDvCMpLnUUc KfucRA9AvTRpcl1hYYj8AKXy1SNDEj8qNr1uU0q5dC5n1hGmIBLFFiPQgOltq5+Z11IL bUAiFefn0uKYXqSl4nnROLmRebORNRPVCIjX2HoLUfnt+SFzhpbyRbzqRLJll3u+6k8W UoC8G00rqzDG1TRZkV0huewlQ88U2G7HDLYtn/3Ns4fq/16NCl2CR3Wac3OiGvoGMSnD Xw== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2mt0tu658h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 04 Oct 2018 18:39:51 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w94Idk6k032664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 4 Oct 2018 18:39:46 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w94IdjeI023789; Thu, 4 Oct 2018 18:39:45 GMT Received: from [10.0.1.37] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Oct 2018 18:39:44 +0000 From: Phil Hunt Message-Id: <0F6B2C97-E9F8-46B0-A905-52BA919626AA@oracle.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D9FCFAB7-A441-407B-94D0-8A48B4EE7DAD" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 4 Oct 2018 11:39:43 -0700 In-Reply-To: Cc: "Morteza Ansari (moransar)" , Chuck Mortimore , "scim@ietf.org" To: "Jena, Jayadeba" References: X-Mailer: Apple Mail (2.3445.9.1) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9036 signatures=668706 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810040168 Archived-At: Subject: Re: [scim] SCIM financial user profile X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 18:39:59 -0000 --Apple-Mail=_D9FCFAB7-A441-407B-94D0-8A48B4EE7DAD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jena, It=E2=80=99s really up to you how you want to go. Within IETF, you can post a draft RFC and then see if there is interest = in chartering a WG. For info on process check out RFC2026. Also = https://www.ietf.org/standards/process/ You are also free to register new schema in IANA as an independent or = through some other industry SDO. If you are looking to get broader agreement and adoption, a WG (from = IETF or other) is the best route. Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Oct 3, 2018, at 3:00 PM, Jena, Jayadeba wrote: >=20 > Hello,=20 > =20 > In PayPal, we have use-cases that cover a broad set of = users/geographies for account onboarding (i.e. to create PayPal = accounts). While we were trying to extend the SCIM user profile to = include the attributes required for creating new PayPal accounts, we = realized that this is something that should be standardized as an = extension profile in SCIM (or a completely new financial user profile) = so it can benefit everyone in the fintech industry and make the = financial account onboarding interoperable. > =20 > May I know the process for standardizing it as part of the ietf SCIM = specification, and getting it approved by the group? > =20 > =20 > Thanks, > Jayadeba > =20 > From: Phil Hunt > > Date: Wednesday, August 22, 2018 at 2:49 PM > To: "Jena, Jayadeba" > > Cc: "Morteza Ansari (moransar)" >, Chuck Mortimore = >, = "scim@ietf.org " > > Subject: Re: [scim] SCIM: Questions regarding Error handling for Bulk = operations > =20 > =20 >> The service provider response MUST include the result of all >> processed operations. =20 > =20 > I see the poor wording. =E2=80=9Cprocessed=E2=80=9D could be = interpreted in some circles as successful items only.=20 > =20 > The intent was to be all records processed whether successful or not. = Without a response clients would not know the outcome of the = =E2=80=9Cmissing=E2=80=9D transactions and would be indeterminate. > =20 > Phil > =20 > Oracle Corporation, Identity Cloud Services Architect > @independentid > www.independentid.com = > phil.hunt@oracle.com >=20 >=20 >> On Aug 21, 2018, at 12:01 AM, Jena, Jayadeba > wrote: >> =20 >> Phil,=20 >> =20 >> The processing rules behavior is clear but I felt that the bulk = response handling for the partial failure cases is not super clear (or = ambiguous) from the perspective of a implementor- Whether the bulk = response should contain all failed items or the failed items should be = omitted in the response. This is how I and few of my colleagues at = PayPal reading the spec felt so I reached out to you for clarification. = We felt like there=E2=80=99s no authoritative statement. >> =20 >> Please feel free to consider this as an exception and ignore my = request to add to the documentation. >> =20 >> Thanks for the details clarification! It helped. >> =20 >> Thanks, >> Jayadeba >> =20 >> From: Phil Hunt > >> Date: Monday, August 20, 2018 at 11:34 PM >> To: "Jena, Jayadeba" > >> Cc: "Morteza Ansari (moransar)" >, Chuck Mortimore = >, = "scim@ietf.org " > >> Subject: Re: [scim] SCIM: Questions regarding Error handling for Bulk = operations >> =20 >> Jayadeba,=20 >> =20 >> I don=E2=80=99t believe I see an issue here. Keep in mind the = following from Sec 3.7: >> =20 >>> failOnErrors >>> An integer specifying the number of errors that the service >>> provider will accept before the operation is terminated and an >>> error response is returned. OPTIONAL in a request. Not valid = in >>> a response. >> =20 >> In the processing rules: >>> 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 the "failOnErrors" = attribute. >>> The "failOnErrors" attribute defines the number of errors that = the >>> service provider should accept before failing the remaining >>> operations returning the response. >> =20 >> Thus, unless a fatal error (e.g. like a syntax/parsing error) occurs, = a 200 response is almost always expected with any errors embedded in the = transaction - even if all transactions fail. >> =20 >> In each of your scenarios, I would expect 200 responses with = individual transactions indicating correct success/failure as if they = were their own separate HTTP request - e.g. so you would issue 409 for = the specific transaction status. >> =20 >> Phil >> =20 >> Oracle Corporation, Identity Cloud Services Architect >> @independentid >> www.independentid.com = >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>> On Aug 20, 2018, at 7:09 PM, Jena, Jayadeba > wrote: >>> =20 >>> Thanks Phil, Morteza! Appreciate your quick response in clarifying = this. >>> =20 >>> It would be great if the spec can be updated to clearly describe the = behavior of the bulk server wrt error handling in partial success cases = so anyone implementing the bulk API later doesn=E2=80=99t come across = the same set of questions. It would be great to add some canonical = examples as well. >>> =20 >>> Thanks again! >>> =20 >>> Jayadeba >>> =20 >>> From: Phil Hunt > >>> Date: Monday, August 20, 2018 at 1:40 PM >>> To: "Morteza Ansari (moransar)" > >>> Cc: "Jena, Jayadeba" >, = Chuck Mortimore >, "scim@ietf.org = " > >>> Subject: Re: [scim] SCIM: Questions regarding Error handling for = Bulk operations >>> =20 >>> Morteza/Jena,=20 >>> =20 >>> The IDCS (Identity Cloud Service) bulk endpoint returns an overall = 200 and then 409 for each resource operation that failed (due to cycle = or any other reason) and a 200/201 for those that succeed. >>> =20 >>> Phil >>> =20 >>> Oracle Corporation, Identity Cloud Services Architect >>> @independentid >>> www.independentid.com = >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>> On Aug 20, 2018, at 12:11 PM, Morteza Ansari (moransar) = > wrote: >>>> =20 >>>> Hi Jena, >>>> =20 >>>> Best option for getting clarification on SCIM spec is to reach out = to the WG mailing list: scim@ietf.org . Many more = eyes will see it there. >>>> =20 >>>> As to your specific question, I am actually not 100% sure. = Re-reading the spec seems to be a bit ambiguous there and I haven=E2=80=99= t actually implemented bulk myself. I believe the answer to both = scenarios is returning 200 responses with operation responses of 409 for = the failed. >>>> =20 >>>> Phil, others, do you have a better answer? Have we clarified this = somewhere else in the doc that I am missing? >>>> =20 >>>> =20 >>>> Cheers, >>>> Morteza >>>> =20 >>>> From: "Jena, Jayadeba" > >>>> Date: Friday, August 17, 2018 at 5:32 PM >>>> To: "morteza.ansari@cisco.com " = >, Chuck = Mortimore > >>>> Subject: SCIM: Questions regarding Error handling for Bulk = operations >>>> =20 >>>> Hi, >>>> =20 >>>> I=E2=80=99m from PayPal and trying to understand the SCIM bulk = specification and have questions around the error handling with = =E2=80=9CfailOnError=E2=80=9D not specified in the request. As an = example, I was reading through the section = (https://tools.ietf.org/html/rfc7644#section-3.7.1 = ) - which says that we need to return the error code 409 = when the circular dependency couldn=E2=80=99t be resolved by the server. = The behavior of the bulk server wrt is not clear to me when we have the = =E2=80=9CFailOnError=E2=80=9D flag is not specified. Please help clarify = if the following behavior is correct and as per the specification. >>>> =20 >>>> Scenario1: When there=E2=80=99s a bulk request body with 2 items, = failOnErrors flag is not specified in the request- The server while = processing the bulk requests, discovers circular dependency that it = couldn=E2=80=99t resolve, what would be the bulk response? Should the = bulk server return a top level 409 response or a 200 response with = operation response for each failed items (i.e 2 operation responses with = 409 as the code for each). >>>> Scenario2: When there=E2=80=99s a bulk request body with 3 items, = failOnErrors flag is not specified in the request- The server while = processing the bulk requests, discovers circular dependency that it = couldn=E2=80=99t resolve for the first 2 items, while the 3rd items = could be processed successfully, what would be the bulk response? Should = it be a 200 response with operation response for each failed items (i.e = 2 operation responses with 409 as the code for each) and then it also = contains the successful response for the 3rd item >>>> =20 >>>> Thanks, >>>> Jayadeba >>>> =20 >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_scim&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE= &r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DpyJbcSIML-m5QRPAfMRPW= 1D5vOwW3y_KWQo_pX0bJh0&s=3DQd2Np4bHIUk6wz2YbFfR1mQ9xfEPtgGxHm40luqoUjg&e=3D= = --Apple-Mail=_D9FCFAB7-A441-407B-94D0-8A48B4EE7DAD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Jena,

It=E2=80=99s really up to you how you want to go.

Within IETF, you can post a draft RFC = and then see if there is interest in chartering a WG.

For info on process check out RFC2026. = Also https://www.ietf.org/standards/process/

You are also free to = register new schema in IANA as an independent or through some other = industry SDO.

If= you are looking to get broader agreement and adoption, a WG (from IETF = or other) is the best route.

Phil

Oracle Corporation, Identity Cloud = Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Oct 3, 2018, at 3:00 PM, Jena, Jayadeba <jjena@paypal.com> = wrote:

Hello, 
 
In = PayPal, we have use-cases that cover a broad set of users/geographies = for account onboarding (i.e. to create PayPal accounts). While we were = trying to extend the SCIM user profile to include the attributes = required for creating new PayPal accounts, we realized that this is = something that should be standardized as an extension profile in SCIM = (or a completely new financial user profile) so it can benefit everyone = in the fintech industry and make the financial account onboarding = interoperable.
 
May I know the process for standardizing it as part of the = ietf SCIM specification, and getting it approved by the group?
 
 
Thanks,
Jayadeba
 
From: Phil Hunt <phil.hunt@oracle.com>
Date: Wednesday, August 22, = 2018 at 2:49 PM
To: "Jena, Jayadeba" <jjena@paypal.com>
Cc: "Morteza Ansari = (moransar)" <moransar=3D40cisco.com@dmarc.ietf.org>, Chuck = Mortimore <cmortimore@salesforce.com>, "scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] SCIM: = Questions regarding Error handling for Bulk operations
 
 
 =
The service provider response MUST include the result of all
   processed operations. 
 
I see the poor wording. =E2=80=9Cprocesse= d=E2=80=9D could be interpreted in some circles as successful items = only. 
 
The intent was to be all records processed whether successful = or not. Without a response clients would not know the outcome of the = =E2=80=9Cmissing=E2=80=9D transactions and would be indeterminate.
 
Phil
 
Oracle Corporation, Identity Cloud Services Architect
@independentid
phil.hunt@oracle.com


On Aug 21, 2018, at 12:01 AM, Jena, = Jayadeba <jjena@paypal.com> = wrote:
 
Phil, 
 
The processing rules behavior is clear = but I felt that the bulk response handling for the partial failure cases = is not super clear (or ambiguous) from the perspective of a implementor- = Whether the bulk response should contain all failed items or the failed = items should be omitted in the response. This is how I and few of my = colleagues at PayPal reading the spec felt so I reached out to you for = clarification. We felt like there=E2=80=99s no authoritative = statement.
 
Please feel free to consider this as an exception and ignore = my request to add to the documentation.
 
Thanks for the details clarification! = It helped.
 
Thanks,
Jayadeba
 
From: Phil Hunt <phil.hunt@oracle.com>
Date: Monday, August 20, 2018 = at 11:34 PM
To: "Jena, Jayadeba" <jjena@paypal.com>
Cc: "Morteza Ansari = (moransar)" <moransar=3D40cisco.com@dmarc.ietf.org>, Chuck = Mortimore <cmortimore@salesforce.com>, "scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] SCIM: = Questions regarding Error handling for Bulk operations
 
Jayadeba, 
 
I don=E2=80=99t believe I see an issue = here. Keep in mind the following from Sec 3.7:
 
failOnErrors
      An integer =
specifying the number of errors that the service
      provider will accept before =
the operation is terminated and an
      =
error response is returned.  OPTIONAL in a request.  Not valid =
in
      a response.
 
In the processing rules:
   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 the "failOnErrors" attribute.
   The "failOnErrors" =
attribute defines the number of errors that the
   service provider should accept before failing =
the remaining
   operations returning the response.
 
Thus, unless a fatal error = (e.g. like a syntax/parsing error) occurs, a 200 response is almost = always expected with any errors embedded in the transaction - even if = all transactions fail.
 
In each of your scenarios, I would = expect 200 responses with individual transactions indicating correct = success/failure as if they were their own separate HTTP request - e.g. = so you would issue 409 for the specific transaction status.
 
Phil
 
Oracle Corporation, Identity Cloud = Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.com



On Aug 20, 2018, at 7:09 PM, Jena, Jayadeba <jjena@paypal.com> wrote:
 
Thanks = Phil, Morteza! Appreciate your quick response in clarifying this.
 
It would be great if the spec can be = updated to clearly describe the behavior of the bulk server wrt error = handling in partial success cases so anyone implementing the bulk API = later doesn=E2=80=99t come across the same set of questions. It would be = great to add some canonical examples as well.
 
Thanks again!
 
Jayadeba
 
From: Phil Hunt <phil.hunt@oracle.com>
Date: Monday, August 20, 2018 = at 1:40 PM
To: "Morteza Ansari = (moransar)" <moransar=3D40cisco.com@dmarc.ietf.org>
Cc: "Jena, Jayadeba" <jjena@paypal.com>, Chuck Mortimore <cmortimore@salesforce.com>, "scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] SCIM: = Questions regarding Error handling for Bulk operations
 
Morteza/Jena, 
 
The IDCS = (Identity Cloud Service) bulk endpoint returns an overall 200 and then = 409 for each resource operation that failed (due to cycle or any other = reason) and a 200/201 for those that succeed.
 
Phil
 
Oracle = Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.com




On Aug = 20, 2018, at 12:11 PM, Morteza Ansari (moransar) <moransar=3D40cisco.com@dmarc.ietf.org> = wrote:
 
Hi = Jena,
 
Best = option for getting clarification on SCIM spec is to reach out to the WG = mailing list: scim@ietf.org. Many more eyes will see it = there.
 
As to = your specific question, I am actually not 100% sure. Re-reading the spec = seems to be a bit ambiguous there and I haven=E2=80=99t actually = implemented bulk myself. I believe the answer to both scenarios is = returning 200 responses with operation responses of 409 for the = failed.
 
Phil, = others, do you have a better answer? Have we clarified this somewhere = else in the doc that I am missing?
 
 
Cheers,
Morteza
 
From: "Jena, Jayadeba" <jjena@paypal.com>
Date: Friday, August 17, 2018 = at 5:32 PM
To: "morteza.ansari@cisco.com" <morteza.ansari@cisco.com>, Chuck Mortimore <cmortimore@salesforce.com>
Subject: SCIM: Questions = regarding Error handling for Bulk operations
 
Hi,
 
I=E2=80=99m from PayPal and trying to understand the SCIM = bulk specification and have questions around the error handling with = =E2=80=9CfailOnError=E2=80=9D not specified in the request. As an = example, I was reading through the section (https://tools.ietf.org/html/rfc7644#section-3.7.1) = - which says that we need to return the error code 409 when the circular = dependency couldn=E2=80=99t be resolved by the server. The behavior of = the bulk server wrt is not clear to me when we have the = =E2=80=9CFailOnError=E2=80=9D flag is not specified. Please help clarify = if the following behavior is correct and as per the specification.
 
  • Scenario1: = When there=E2=80=99s a bulk request body with 2 items, failOnErrors flag = is not specified in the request- The server while processing the bulk = requests, discovers circular dependency that it couldn=E2=80=99t = resolve, what would be the bulk response? Should the bulk server return = a top level 409 response or a 200 response with operation response for = each failed items (i.e 2 operation responses with 409 as the code for = each).
  • Scenario2: When there=E2=80=99s = a bulk request body with 3 items, failOnErrors flag is not specified in = the request- The server while processing the bulk requests, discovers = circular dependency that it couldn=E2=80=99t resolve for the first 2 = items, while the 3rd items could be processed = successfully, what would be the bulk response? Should it be a  200 = response with operation response for each failed items (i.e 2 operation = responses with 409 as the code for each) and then it also contains the = successful response for the 3rd item
 
Thanks,
Jayadeba
 
_______________________________________________
scim mailing list
scim@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_scim&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8= Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&am= p;m=3DpyJbcSIML-m5QRPAfMRPW1D5vOwW3y_KWQo_pX0bJh0&s=3DQd2Np4bHIUk6wz2Y= bFfR1mQ9xfEPtgGxHm40luqoUjg&e=3D

= --Apple-Mail=_D9FCFAB7-A441-407B-94D0-8A48B4EE7DAD--