Re: [scim] SCIM financial user profile

Phil Hunt <phil.hunt@oracle.com> Thu, 04 October 2018 18:39 UTC

Return-Path: <phil.hunt@oracle.com>
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 <scim@ietfa.amsl.com>; 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 <scim@ietfa.amsl.com>; 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 <scim@ietf.org>; 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 <phil.hunt@oracle.com>
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, 04 Oct 2018 11:39:43 -0700
In-Reply-To: <A915C0E9-1F00-45C1-AC96-A460E522F045@paypalcorp.com>
Cc: "Morteza Ansari (moransar)" <moransar=40cisco.com@dmarc.ietf.org>, Chuck Mortimore <cmortimore@salesforce.com>, "scim@ietf.org" <scim@ietf.org>
To: "Jena, Jayadeba" <jjena@paypal.com>
References: <A915C0E9-1F00-45C1-AC96-A460E522F045@paypalcorp.com>
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: <https://mailarchive.ietf.org/arch/msg/scim/XWXMvU_A9kczBCxq0KS6a0sk5gs>
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 <scim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scim>, <mailto:scim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/scim/>
List-Post: <mailto:scim@ietf.org>
List-Help: <mailto:scim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scim>, <mailto:scim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Oct 2018 18:39:59 -0000

Jena,

It’s 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 <http://www.independentid.com/>phil.hunt@oracle.com <mailto: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 <mailto:phil.hunt@oracle.com>>
> Date: Wednesday, August 22, 2018 at 2:49 PM
> To: "Jena, Jayadeba" <jjena@paypal.com <mailto:jjena@paypal.com>>
> Cc: "Morteza Ansari (moransar)" <moransar=40cisco.com@dmarc.ietf.org <mailto:moransar=40cisco.com@dmarc.ietf.org>>, Chuck Mortimore <cmortimore@salesforce.com <mailto:cmortimore@salesforce.com>>, "scim@ietf.org <mailto:scim@ietf.org>" <scim@ietf.org <mailto: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. “processed” 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 “missing” transactions and would be indeterminate.
>  
> Phil
>  
> Oracle Corporation, Identity Cloud Services Architect
> @independentid
> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=s0D3cSBxVU-tgl73FJQ6myV8B0-O37Eq5xbwf_gw4JM&s=4gje3FebhIc5Uq8vARqIsO9gT98W-6Fu1A4oZ64S434&e=>
> phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
> 
> 
>> On Aug 21, 2018, at 12:01 AM, Jena, Jayadeba <jjena@paypal.com <mailto: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’s 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 <mailto:phil.hunt@oracle.com>>
>> Date: Monday, August 20, 2018 at 11:34 PM
>> To: "Jena, Jayadeba" <jjena@paypal.com <mailto:jjena@paypal.com>>
>> Cc: "Morteza Ansari (moransar)" <moransar=40cisco.com@dmarc.ietf.org <mailto:moransar=40cisco.com@dmarc.ietf.org>>, Chuck Mortimore <cmortimore@salesforce.com <mailto:cmortimore@salesforce.com>>, "scim@ietf.org <mailto:scim@ietf.org>" <scim@ietf.org <mailto:scim@ietf.org>>
>> Subject: Re: [scim] SCIM: Questions regarding Error handling for Bulk operations
>>  
>> Jayadeba, 
>>  
>> I don’t 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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=kkqUZJQyDycxKrJh7C0yXIK455QjHVPkc8lWvzE77aA&s=7ulncV_Y7oQ9atfau_mCbWEWya8IWZsNoq-7PG_OlhE&e=>
>> phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
>> 
>> 
>> 
>>> On Aug 20, 2018, at 7:09 PM, Jena, Jayadeba <jjena@paypal.com <mailto: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’t 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 <mailto:phil.hunt@oracle.com>>
>>> Date: Monday, August 20, 2018 at 1:40 PM
>>> To: "Morteza Ansari (moransar)" <moransar=40cisco.com@dmarc.ietf.org <mailto:moransar=40cisco.com@dmarc.ietf.org>>
>>> Cc: "Jena, Jayadeba" <jjena@paypal.com <mailto:jjena@paypal.com>>, Chuck Mortimore <cmortimore@salesforce.com <mailto:cmortimore@salesforce.com>>, "scim@ietf.org <mailto:scim@ietf.org>" <scim@ietf.org <mailto: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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=IW0pK2S_tDZmsBAMNhx8eLn8fo8aY4TrxLKHLiFPzes&s=XAhIpuMi7adufIojCfe2ULfCBG2aTKK_Go3jH5zgrw0&e=>
>>> phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
>>> 
>>> 
>>> 
>>> 
>>>> On Aug 20, 2018, at 12:11 PM, Morteza Ansari (moransar) <moransar=40cisco.com@dmarc.ietf.org <mailto:moransar=40cisco.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 <mailto: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’t 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 <mailto:jjena@paypal.com>>
>>>> Date: Friday, August 17, 2018 at 5:32 PM
>>>> To: "morteza.ansari@cisco.com <mailto:morteza.ansari@cisco.com>" <morteza.ansari@cisco.com <mailto:morteza.ansari@cisco.com>>, Chuck Mortimore <cmortimore@salesforce.com <mailto:cmortimore@salesforce.com>>
>>>> Subject: SCIM: Questions regarding Error handling for Bulk operations
>>>>  
>>>> Hi,
>>>>  
>>>> I’m from PayPal and trying to understand the SCIM bulk specification and have questions around the error handling with “failOnError” not specified in the request. As an example, I was reading through the section (https://tools.ietf.org/html/rfc7644#section-3.7.1 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7644-23section-2D3.7.1&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=pyJbcSIML-m5QRPAfMRPW1D5vOwW3y_KWQo_pX0bJh0&s=rd-Tvkl4RlzRIcibzydGY6X7AR9lv3FOPuTCB6MNgZ8&e=>) - which says that we need to return the error code 409 when the circular dependency couldn’t be resolved by the server. The behavior of the bulk server wrt is not clear to me when we have the “FailOnError” flag is not specified. Please help clarify if the following behavior is correct and as per the specification.
>>>>  
>>>> Scenario1: When there’s 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’t 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’s 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’t 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 <mailto:scim@ietf.org>
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_scim&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=pyJbcSIML-m5QRPAfMRPW1D5vOwW3y_KWQo_pX0bJh0&s=Qd2Np4bHIUk6wz2YbFfR1mQ9xfEPtgGxHm40luqoUjg&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_scim&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=pyJbcSIML-m5QRPAfMRPW1D5vOwW3y_KWQo_pX0bJh0&s=Qd2Np4bHIUk6wz2YbFfR1mQ9xfEPtgGxHm40luqoUjg&e=>