From nobody Sat Feb 3 09:14:55 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 9171712D946 for ; Sat, 3 Feb 2018 09:14:52 -0800 (PST) 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, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=wso2.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 LgbwmDpa3RTZ for ; Sat, 3 Feb 2018 09:14:50 -0800 (PST) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 7DD11128959 for ; Sat, 3 Feb 2018 09:14:48 -0800 (PST) Received: by mail-wr0-x233.google.com with SMTP id f6so23873313wra.6 for ; Sat, 03 Feb 2018 09:14:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wso2.com; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=3WpoCKnZtU4740PRmWbJDaSvZDsZKXJN2Se8VAd7BnE=; b=QZHuyzaaiJDPcgfFol3hkKKC2mLTpjFDxJMqQ1QTt/+bcPh4f39zx757as/Jsh1/nB Pn/wwQMwAq17dSfPvGGsMVIfL6QHDM2xD17gzWgVIxBq3RyFpUBp3g01qAKhZ5Oi3/CG 9fzl3yax9ruUgnl9vKbnVc3Zyvd1+HBsItyHg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=3WpoCKnZtU4740PRmWbJDaSvZDsZKXJN2Se8VAd7BnE=; b=AGpIItyPSqBrA5J3o1aJGC/K52LUzl50WSyBNF2Ai5hUdNVGkN/5MxRAtERvQBXSg/ 6Z9e0DB7s+bYLE0GbEG7PLGKkR8p2WOlVNLKqQYDOCjrihE/4Ckjfcs8eGczYdgRVia+ pT0TiECSjkSSZPBPMNJuIeU34hDBVixd0Tvzup6fYrOkCURbBP8X7Cryfi4b9W74iTA4 wQJVDEn+1iJ7PvkTpdo9oVTN0CjO3tWRrBRaV6bRewzHYxKuR8WWpqHOOb48t6+5k0hI j9zAZtcyB7A9i3DWW6JIenJYUIEc6p9+iWTGd8Fp1dFp5R+LpBcQbhSEbSMYcQQbmAeR kxPA== X-Gm-Message-State: AKwxytcF1xuuImKBj9E8fz7u7Dbxj5h8JzsVgLqYyLzXP7FYMyzPiZfB aiFEJVJTNqhpeXwuCodWQHju0HbbuaQ22p0wf4pchg== X-Google-Smtp-Source: AH8x225cmakOccPDgWcXeISfrj2l5UZrvn9OGbIPDObutAYmrcaI9LLNpZP5aAdzB+7jtthAO6+TpOf/F4HFueCLcWk= X-Received: by 10.223.134.237 with SMTP id 42mr12971055wry.283.1517678087073; Sat, 03 Feb 2018 09:14:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.136.57 with HTTP; Sat, 3 Feb 2018 09:14:46 -0800 (PST) From: Gayan Gunawardana Date: Sat, 3 Feb 2018 22:44:46 +0530 Message-ID: To: scim@ietf.org Cc: Phil Hunt Content-Type: multipart/alternative; boundary="001a114918f0439992056451f7be" Archived-At: Subject: [scim] Is it possible to control response content for resource Create/Update via attributes or excludedAttributes ? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 17:14:52 -0000 --001a114918f0439992056451f7be Content-Type: text/plain; charset="UTF-8" Appreciate your opinion regarding $subject. -- Gayan Gunawardana Senior Software Engineer; WSO2 Inc.; http://wso2.com/ Email: gayan@wso2.com Mobile: +94 (71) 8020933 --001a114918f0439992056451f7be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Appreciate your opinion regarding=C2=A0 $subject.

--
Gayan Gunawardana
<= font color=3D"#888888" face=3D"arial, sans-serif">Senior Software Engineer; WSO= 2 Inc.; http://wso2.com/=
--001a114918f0439992056451f7be-- From nobody Sat Feb 3 15:52:11 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 6C53D1204DA for ; Sat, 3 Feb 2018 15:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 u0_zCSy6mWS9 for ; Sat, 3 Feb 2018 15:52:08 -0800 (PST) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 CB02B1200F1 for ; Sat, 3 Feb 2018 15:52:08 -0800 (PST) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w13Nq7Fr030268; Sat, 3 Feb 2018 23:52:07 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2017-10-26; bh=zFMy/fCfblzo9/HWlGb5Yo+rZLIGasv54N0Mo/v+LhY=; b=ACio73yGrKl83o+odJjkrXbRR6tSbvJfj5Uptg24kBk0cWJ97cLnWGS3oSGie+7qwmSv fvLNqR2f11t68ofoUUnoQRyQWtgfkyneFHbMctbdJHB8yBYnr8VRiCqpPqgnPo7NkIkH FkqtYf9TGjFd6HFWzJlJfSIxugHx4NYW7EF9aVhy7Dv3amjhAaldBxvkilV4PmseqLds lMUho5HnR2JTpXah979IIoAnQJ0tF4/9VMRY2nMvrrBJzWTGZV5xSQkMGe8+04gQGENZ vw93/dNWtYZj0sVQyzZkgfiGQi42Uti9hf0XuKinDfj1pVwn3LDlTXo9G5PKK2OeKBrM qw== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2120.oracle.com with ESMTP id 2fw5qx9f12-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 03 Feb 2018 23:52:07 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w13Nq5fA014353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 3 Feb 2018 23:52:05 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w13Nq3TF031588; Sat, 3 Feb 2018 23:52:05 GMT Received: from [192.168.1.45] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 03 Feb 2018 15:52:02 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-5E00149B-DD81-4DD8-99BF-6775B53A3DCF Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (15D60) In-Reply-To: Date: Sat, 3 Feb 2018 15:52:01 -0800 Cc: scim@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <3981B1A7-BBD1-46B2-BF98-A1EEDC1377C1@oracle.com> References: To: Gayan Gunawardana X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8794 signatures=668662 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=679 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802030318 Archived-At: Subject: Re: [scim] Is it possible to control response content for resource Create/Update via attributes or excludedAttributes ? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 23:52:10 -0000 --Apple-Mail-5E00149B-DD81-4DD8-99BF-6775B53A3DCF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yes. See section 3.9 of RFC7644. Phil > On Feb 3, 2018, at 9:14 AM, Gayan Gunawardana wrote: > > Appreciate your opinion regarding $subject. > > -- > Gayan Gunawardana > Senior Software Engineer; WSO2 Inc.; http://wso2.com/ > Email: gayan@wso2.com > Mobile: +94 (71) 8020933 --Apple-Mail-5E00149B-DD81-4DD8-99BF-6775B53A3DCF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes. See section 3.9 of RFC7644.

Phil

On Feb 3, 2018, at 9:14 AM, G= ayan Gunawardana <gayan@wso2.com>= ; wrote:

Apprec= iate your opinion regarding  $subject.

--
Gayan Gunawardana
Senior Software Engineer; WSO2 Inc.; http= ://wso2.com/
= --Apple-Mail-5E00149B-DD81-4DD8-99BF-6775B53A3DCF-- From nobody Mon Feb 5 07:25:48 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 963FD126D73 for ; Mon, 5 Feb 2018 07:25:46 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8OLzEO0UHGkq for ; Mon, 5 Feb 2018 07:25:45 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 DAB3B1242F7 for ; Mon, 5 Feb 2018 07:25:44 -0800 (PST) Received: by mail-vk0-x230.google.com with SMTP id w201so17883231vkw.0 for ; Mon, 05 Feb 2018 07:25:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ltPBqcBQAGJfS9g8QCHDZrxlujaTe9DTstOLv46xo/s=; b=RCDVRW4nGnkkTPB6OGMvRI4LP2JEp9Xyce7Jy0YYApGBMJqT938D2R/+haDs0ZyoMr 5HyJPboK148hgOkDy8BljwifWo2Wav9a8lmTprEdQ7D+SzUMfDAWBTshXHvPvGcs+KsG YjY+NOhf3nsZYinEluoKNnQ3HPB0WnXu6zUi9omXbfE5dD6/BNVKKCZEhpSsIIvXwhWM P2dZlXQdDxUEO0QOvG+gx0XsgAsZlDgUXjUEM9i5iqkFmkqsNo16VEWp9fv74dW0LcYL WLC57a1XojylUEdlboAmhZxa2Pzxb4UnaR04434gHo15i8k15zsbZEvQ3sEtyKMjA+zk Wrpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ltPBqcBQAGJfS9g8QCHDZrxlujaTe9DTstOLv46xo/s=; b=TN4YxckpiNnk6CUMlbz/AXyIekenYywIOCnVPTszmqe3ZiWhhgkSEw4jW9d03H+hxL uDkUb2D2Ro94QGwaXHWBqukfbTPwP6b6TYYHCU2mOz9A0Hp1kGgNzUx6cbad1D2+CTJb 9XlUkdi9sGfO9waOmdUzOfgDrHdy6yv+RjzBjsiCa4/fXK3iNkIPZE0Zz2OSolbRzcjz KC7YD2toIFaQL9ovwyUs7prXA9zBaK/ztqv9aBrsE4qO3ye83d/I0YxP7Cbdnk84muWu vCjxmDBB7J3wz5VDaosLIwXIG7TT1cOWMC9CVKND7fF3kNtvhBP5Rxl03zIOTd2SSkmO QpYQ== X-Gm-Message-State: AKwxyteD64Vb2R2tcsnrDsc57ItF73C5oxZIIbAGWrpNAuVAfapFx2zl ob/UZtcyZ8jSkurnzHW8SlbxWKPNtwAy29RpGHw0qg== X-Google-Smtp-Source: AH8x226I/lHaMiUiEVg4qBM2dyn5mP4iZFkcNZBlq5nQIFmNMIo+JmDlXLVmfK/XVXA050Wp0cQau+o5BZDOyjtpB/8= X-Received: by 10.31.61.70 with SMTP id k67mr38011602vka.17.1517844343536; Mon, 05 Feb 2018 07:25:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.91.88 with HTTP; Mon, 5 Feb 2018 07:25:22 -0800 (PST) From: Aleksey Chernoraenko Date: Mon, 5 Feb 2018 09:25:22 -0600 Message-ID: To: scim@ietf.org Content-Type: multipart/alternative; boundary="001a114d9ac8ebc271056478ac12" Archived-At: Subject: [scim] How to specify core supported attributes? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 15:25:47 -0000 --001a114d9ac8ebc271056478ac12 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =E2=80=8B=E2=80=8B Hello, We are implementing SCIM Resource Provider for Users, Groups and a couple of custom resources. SCIM Core Schema RFC 7643 defines User resource so, that only userName and core attributes (id, schemas) are required. Plus it defines optional attributes like name, profileUrl, etc. Some optional attributes do not make sense in our context (e.g. ims) or are not supported or very expensive to be supported. >From the other hand, other optional attributes like name should be "required" and should be returned "always". What is the recommended way to express this, so that the clients would know what attributes should be provided? As much I understand rfc, we should provide the adjusted, tweaked version of core User schema on /Schemas endpoint. Is it correct way? Would it make our Provider "none SCIM compliant"? --- Thank you, Alexei --001a114d9ac8ebc271056478ac12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=E2=80= =8B=E2=80=8B
Hello,

We are impleme= nting SCIM Resource Provider for Users, Groups and a couple of custom resou= rces.
SCIM Core Schema= RFC 7643 defines User resource so, that only userName and core attributes = (id, schemas) are required. Plus it defines optional attributes like name, = profileUrl, etc.

<= /font>
Some optional attribut= es do not make sense in our context (e.g. ims) or are not supported or very= expensive to be supported.
From the other hand, other optional attributes like name should be &q= uot;required" and should be returned "always".
<= div>
What is the recommended way to express this, so that= the clients would know what attributes should be provided?
As much I understand rfc, we should p= rovide the adjusted, tweaked version of core User schema on /Schemas endpoi= nt. Is it correct way?
Would it make our Provider "none SCIM compliant"?

---
Thank you,
Alexei<= /font>
--001a114d9ac8ebc271056478ac12-- From nobody Mon Feb 5 09:57:55 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 E1C10127599 for ; Mon, 5 Feb 2018 09:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 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_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 3JcT2DhOEnMO for ; Mon, 5 Feb 2018 09:57:51 -0800 (PST) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 84B5F127369 for ; Mon, 5 Feb 2018 09:57:51 -0800 (PST) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w15HurBd027557; Mon, 5 Feb 2018 17:57:49 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-2017-10-26; bh=noMb/0qOyxH+42++TeDuyG4bCK5oCORtDOJiPR2VN28=; b=pTxVUN5Cg/H5MlZx5rwYd21LQcuPiEGDZ9ctEIDaao2BL60Y/TwwgQrPiq2ny2TaF6vr Ipgd6mQ4zoVf/GrQ3ZxYiLFPlOEVD4LetPyfG1Vjjy919h58oCfvA3AUqoXd2d+6OFA6 88auwK1Q8lqdhLQIVm3CehOrSOfjBOrplPuaRg1j2r+cS84TF+56FpeTNlWCvXC6Jl1v coZQ9yJQ6gm8enEcqy4AmL5hPWJbBbuUU92Hr8GPLSJnnlrDmqMiYUHW6YrEd+PMGeJH aS8GJZvpCbLVk6YNcd0b8L17uAHm2uK1ECQ+9ZiclY30PfOdts6xSNlYaPddaiLyYPkP aQ== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2fxv30g0s5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 05 Feb 2018 17:57:49 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w15Hvn4A025794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 5 Feb 2018 17:57:49 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w15HvmRl018026; Mon, 5 Feb 2018 17:57:49 GMT Received: from [192.168.1.25] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Feb 2018 09:57:48 -0800 From: Phil Hunt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_768A3D5C-F9D1-48B4-A226-3A95AEABD1D5" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 5 Feb 2018 09:57:46 -0800 In-Reply-To: Cc: scim@ietf.org To: Aleksey Chernoraenko References: X-Mailer: Apple Mail (2.3445.5.20) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8796 signatures=668662 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-1711220000 definitions=main-1802050226 Archived-At: Subject: Re: [scim] How to specify core supported attributes? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 17:57:54 -0000 --Apple-Mail=_768A3D5C-F9D1-48B4-A226-3A95AEABD1D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Aleksey, This happens a lot particularly when adapting SCIM protocol on top of = applications (e.g. payroll, HCM, CRM, etc). Each app has data they care = about that is a sub-set of what is seen in IDM systems. The point of = 7643 is really to define standard attribute names, types, syntax, and = handling that developers can count on. IMO, you do not have to implement the schema exactly as published in = 7643. It is quite common practice to omit attributes (e.g. such as an = app that doesn=E2=80=99t care about ims). Note that renaming standard = attributes or changing their formats will produce interop concerns. Use the extension mechanism to define your own app specific attributes = (see section 3.3 of 7643 and 4.3 for the EnterpriseUser example). You are free to omit unused attributes from your schema. You document = what your server actually supports in the /Schemas endpoint. Taken in combination with RFC7644=E2=80=99s =E2=80=9Crobust approach", = when a client sends you an attribute your server does not care about, = the server is free to ignore the data =E2=80=94 without throwing an = error. And likewise clients should not expect a server to regurgitate a = record exactly as presented.=20 Hope this helps clarify. Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Feb 5, 2018, at 7:25 AM, Aleksey Chernoraenko = wrote: >=20 > =E2=80=8B=E2=80=8BHello, >=20 > We are implementing SCIM Resource Provider for Users, Groups and a = couple of custom resources. > SCIM Core Schema RFC 7643 defines User resource so, that only userName = and core attributes (id, schemas) are required. Plus it defines optional = attributes like name, profileUrl, etc. >=20 > Some optional attributes do not make sense in our context (e.g. ims) = or are not supported or very expensive to be supported. > =46rom the other hand, other optional attributes like name should be = "required" and should be returned "always". >=20 > What is the recommended way to express this, so that the clients would = know what attributes should be provided? > As much I understand rfc, we should provide the adjusted, tweaked = version of core User schema on /Schemas endpoint. Is it correct way? > Would it make our Provider "none SCIM compliant"? >=20 > --- > Thank you, > Alexei > _______________________________________________ > 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=3DGLhVp9jP_gbDtVJtxohNM= MwBzQnt7GFCvPsGsT583vo&s=3DRMMu2R0XXu75jgdfyFcraH-_VCJ9gqmAoEmo6z9VnPU&e=3D= --Apple-Mail=_768A3D5C-F9D1-48B4-A226-3A95AEABD1D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Aleksey,

This happens a lot particularly when adapting SCIM protocol = on top of applications (e.g. payroll, HCM, CRM, etc). Each app has data = they care about that is a sub-set of what is seen in IDM systems. The = point of 7643 is really to define standard attribute names, types, = syntax, and handling that developers can count on.

IMO, you do not have to = implement the schema exactly as published in 7643.  It is quite = common practice to omit attributes (e.g. such as an app that doesn=E2=80=99= t care about ims). Note that renaming standard attributes or changing = their formats will produce interop concerns.

Use the extension mechanism to define = your own app specific attributes (see section 3.3 of 7643 and 4.3 for = the EnterpriseUser example).

You are free to omit unused attributes = from your schema.  You document what your server actually supports = in the /Schemas endpoint.

Taken in combination with RFC7644=E2=80=99s =E2=80=9Crobust = approach", when a client sends you an attribute your server does not = care about, the server is free to ignore the data  =E2=80=94 = without throwing an error.  And likewise clients should not expect = a server to regurgitate a record exactly as presented. 

Hope this helps = clarify.

Phil

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

On Feb 5, 2018, at 7:25 AM, Aleksey Chernoraenko <achernoraenko@gmail.com> wrote:

=E2=80=8B=E2=80=8B=
Hello,

We are implementing SCIM = Resource Provider for Users, Groups and a couple of custom = resources.
SCIM Core Schema RFC 7643 defines User resource = so, that only userName and core attributes (id, schemas) are required. = Plus it defines optional attributes like name, profileUrl, = etc.

Some optional attributes do not = make sense in our context (e.g. ims) or are not supported or very = expensive to be supported.
=46rom the other hand, other = optional attributes like name should be "required" and should be = returned "always".

What is the recommended way to = express this, so that the clients would know what attributes should be = provided?
As much I understand rfc, we should provide the = adjusted, tweaked version of core User schema on /Schemas endpoint. Is = it correct way?
Would it make our Provider "none SCIM = compliant"?

---
Thank = you,
Alexei
_______________________________________________
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=3DGLhVp9jP_gbDtVJtxohNMMwBzQnt7GFCvPsGsT583vo&s=3DRMMu2R0XXu75jgdf= yFcraH-_VCJ9gqmAoEmo6z9VnPU&e=3D

= --Apple-Mail=_768A3D5C-F9D1-48B4-A226-3A95AEABD1D5-- From nobody Mon Feb 5 10:33:15 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 68CAF12D88E for ; Mon, 5 Feb 2018 10:33:08 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 dUwijHVqEU-a for ; Mon, 5 Feb 2018 10:33:06 -0800 (PST) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (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 CAB2B12D93F for ; Mon, 5 Feb 2018 10:33:05 -0800 (PST) Received: by mail-ua0-x22b.google.com with SMTP id q8so19309744uae.4 for ; Mon, 05 Feb 2018 10:33:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=GH1X0tO8ogSPFumk5+PtbNHhtYgl4Pe8apUx1I4BxZ4=; b=Q+8OlBpcMfio4eud1+WpBmg9Z1h+bM9nIaQHeJPY3Tu+PcklQVFCTDlRrvUr0OCXO2 oAD9lWcTkJAsBsqioFGd7VdCxc027etDcy80NpKtKsL0KVEfU5ahXimRxei6n8iaNhWs Dk2r4nM4onBZWAy1IxTJoH8FgfKJHsuvFc62LftWMSuiZSz5UKmL86rs39suH4jt1FAe W9cMzQWgQFlYuCwrBa/ImI6DrpWmjPOs+Yrrrhayzl6QVirxDcR3+yh2AXNuwivH3Qq4 GJzvOXMj/CqcKLXXTk92O/POQE60QvTCmFiTJSjTVAD5RA/iiIoTowPDj4Eg4EY6i/y2 M0Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GH1X0tO8ogSPFumk5+PtbNHhtYgl4Pe8apUx1I4BxZ4=; b=P7MJpwF2KM7e0t4TpN7Kg5F+9dO7C99c8ktDGvswH3m/brJCzSngYZRFf5wiTD+GoW m1clNNvuwjcrTQwriM+eKvEhpn8fUNj9ZVpNLNVQmgNMh1ClN+IHTFqmVN/DYiZBR6hs XQUsO+ZIfYJHO/byP8tv/peCDTeIR86MYoY7cbDTvIPcXQPL/KdV7+Z8Ei5yhMNqZHKT cV/eNP6HHY9EoTAmhOrA9drObfHOZl9fP4DRQB4oAuYG/ukT+Xgyi02wKBNWK+YnWc/T 2FG/6PvS3rhJDwvHHYWseFBO/A/3U1nwwQ63XOrieQIJvM0BL/nPbuzgF2dkQg7gv1Qe xZDw== X-Gm-Message-State: APf1xPADPWFaYToBys8aXQpS8dZQHxuxmWV40WpJ9VVE0GTFkFZx4u34 Um1GWOIMsC0ynnLd8JOzBqx388geKAJmWOSXH/M= X-Google-Smtp-Source: AH8x226/BNWuWMoDgpydvdvKxh0/iuRwRLuGC/LUT9cCb4YJe3GDvGh/BBNOdx952FdBvo/U2v4H6ooymOcbfrcTjz0= X-Received: by 10.176.81.171 with SMTP id g40mr10643640uaa.150.1517855584465; Mon, 05 Feb 2018 10:33:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.91.88 with HTTP; Mon, 5 Feb 2018 10:32:43 -0800 (PST) From: Aleksey Chernoraenko Date: Mon, 5 Feb 2018 12:32:43 -0600 Message-ID: To: scim@ietf.org Content-Type: multipart/alternative; boundary="94eb2c18f980eeb60e05647b4a23" Archived-At: Subject: Re: [scim] How to specify core supported attributes? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 18:33:08 -0000 --94eb2c18f980eeb60e05647b4a23 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the reply! Yes, this clarification really helps. Not sure, but maybe some explanation needs to be added in RFC itself? --- Alexei On Mon, Feb 5, 2018 at 11:57 AM, Phil Hunt wrote: > Aleksey, > > This happens a lot particularly when adapting SCIM protocol on top of > applications (e.g. payroll, HCM, CRM, etc). Each app has data they care > about that is a sub-set of what is seen in IDM systems. The point of 7643 > is really to define standard attribute names, types, syntax, and handling > that developers can count on. > > IMO, you do not have to implement the schema exactly as published in > 7643. It is quite common practice to omit attributes (e.g. such as an ap= p > that doesn=E2=80=99t care about ims). Note that renaming standard attribu= tes or > changing their formats will produce interop concerns. > > Use the extension mechanism to define your own app specific attributes > (see section 3.3 of 7643 and 4.3 for the EnterpriseUser example). > > You are free to omit unused attributes from your schema. You document > what your server actually supports in the /Schemas endpoint. > > Taken in combination with RFC7644=E2=80=99s =E2=80=9Crobust approach", wh= en a client sends > you an attribute your server does not care about, the server is free to > ignore the data =E2=80=94 without throwing an error. And likewise clien= ts should > not expect a server to regurgitate a record exactly as presented. > > Hope this helps clarify. > > Phil > > Oracle Corporation, Identity Cloud Services Architect > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Feb 5, 2018, at 7:25 AM, Aleksey Chernoraenko > wrote: > > =E2=80=8B=E2=80=8B > Hello, > > We are implementing SCIM Resource Provider for Users, Groups and a couple > of custom resources. > SCIM Core Schema RFC 7643 defines User resource so, that only userName an= d > core attributes (id, schemas) are required. Plus it defines optional > attributes like name, profileUrl, etc. > > Some optional attributes do not make sense in our context (e.g. ims) or > are not supported or very expensive to be supported. > From the other hand, other optional attributes like name should be > "required" and should be returned "always". > > What is the recommended way to express this, so that the clients would > know what attributes should be provided? > As much I understand rfc, we should provide the adjusted, tweaked version > of core User schema on /Schemas endpoint. Is it correct way? > Would it make our Provider "none SCIM compliant"? > > --94eb2c18f980eeb60e05647b4a23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
Thanks for the reply!
Yes, this clarification really helps.
Not sure=
, but maybe some explanation needs to be added in RFC itself?

---
Alexei

On Mon, Feb 5, 2018 at 11:57 AM, Phil Hunt &l= t;phil.hunt@oracl= e.com> wrote:
Aleksey,

=
This happens a lot particularly when adapting SCIM protocol on top of = applications (e.g. payroll, HCM, CRM, etc). Each app has data they care abo= ut that is a sub-set of what is seen in IDM systems. The point of 7643 is r= eally to define standard attribute names, types, syntax, and handling that = developers can count on.

IMO, you do not have to i= mplement the schema exactly as published in 7643.=C2=A0 It is quite common = practice to omit attributes (e.g. such as an app that doesn=E2=80=99t care = about ims). Note that renaming standard attributes or changing their format= s will produce interop concerns.

Use the extension= mechanism to define your own app specific attributes (see section 3.3 of 7= 643 and 4.3 for the EnterpriseUser example).

You are= free to omit unused attributes from your schema.=C2=A0 You document what y= our server actually supports in the /Schemas endpoint.

=
Taken in combination with RFC7644=E2=80=99s =E2=80=9Crobust approach&q= uot;, when a client sends you an attribute your server does not care about,= the server is free to ignore the data =C2=A0=E2=80=94 without throwing an = error.=C2=A0 And likewise clients should not expect a server to regurgitate= a record exactly as presented.=C2=A0

Hope this he= lps clarify.

Phil

Oracle Corporation, Identity Cloud Services Architect
@ind= ependentid
phil.hunt@oracle.com
<= /div>

On Feb 5, 20= 18, at 7:25 AM, Aleksey Chernoraenko <achernoraenko@gmail.com> wrote:

=
=E2=80= =8B=E2=80=8B
Hello,

We are impleme= nting SCIM Resource Provider for Users, Groups and a couple of custom resou= rces.
SCIM Core Schema= RFC 7643 defines User resource so, that only userName and core attributes = (id, schemas) are required. Plus it defines optional attributes like name, = profileUrl, etc.

<= /font>
Some optional attribut= es do not make sense in our context (e.g. ims) or are not supported or very= expensive to be supported.
From the other hand, other optional attributes like name should be &q= uot;required" and should be returned "always".
<= div>
What is the recommended way to express this, so that= the clients would know what attributes should be provided?
As much I understand rfc, we should p= rovide the adjusted, tweaked version of core User schema on /Schemas endpoi= nt. Is it correct way?
Would it make our Provider "none SCIM compliant"?
--94eb2c18f980eeb60e05647b4a23-- From nobody Tue Feb 6 12:06: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 2EA24127AD4 for ; Tue, 6 Feb 2018 12:06:18 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 S0qS61XVrg9n for ; Tue, 6 Feb 2018 12:06:16 -0800 (PST) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (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 BA13612773A for ; Tue, 6 Feb 2018 12:06:16 -0800 (PST) Received: by mail-vk0-x235.google.com with SMTP id a63so1934120vkg.6 for ; Tue, 06 Feb 2018 12:06:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=MfLeD2kfB8oz40g1Q45bSSkkiraDgUHJswtrMikcJig=; b=ao/xTJwPSXh6x6PnNSHCQzc1oPi9a1aWNiK+2MCH7INY/zIvQ7vXL3HmoKHZ1SoOwx OMiSXYCfNjCIGG2D/Je9UHe3VxRV8DauP2n1wmtivejvl6IdhCZ990vMWeka/AIcEnXm 2bM/pyfymPe7zWHfW22QKf3Fhtw/bSSrfskuWFW1EkSvPvffKX5G9uUK6ftNDDxzfBcY NIQPOyjAKKvg52d+Bc5f7thO9gL1e5yc/R9JD9ydgUw2Wbble+xeG5dFzwzvnnPuEZVz 8LuD177Mpf35E4wOlbxvlERULBMVLVHE1btxoG6enIxw10W3ymo7p2AtKYiNmymyP/mf nm0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=MfLeD2kfB8oz40g1Q45bSSkkiraDgUHJswtrMikcJig=; b=NjY9FK/Gff+0zxhQEim2na0fR7ekJIZz2kAJ02AiX8SdaCoYFBpHCG9nQhBPE8Nxxw fD1IrFsJ8FjCDOw8VJJRiWaxfeHcyw2h2PTWAhh3LO6pD9G6BRNh9HYn2v5dt1eKxLmr UXQspHZ8Xzi+1L2C+1K7tHnGCX3Qox7CQDxoNOVsS7rb3428PTHMGnSNAg2a5PxdPEln /fRFORtEu6Lyp/3DIMURhitShiT4j5cfWTZ4l5VpJ0uaotu92ZhkTfuD2kcxwxKYWrGS aNLSK8XnfkFvYOqZ/yDfjopjIpAgWmXE8QYNyf8RCQuX2751hzWmJNoWz32Rj7UHy3B1 Bpbg== X-Gm-Message-State: APf1xPAAJAo6MCribXHtCMbI/EfnjrvH7nLE6w0aelC5ohlM5AcYCeb+ uYS8mYpfYWUNi+aD+2pUNwO/awwy3mWe2HMnC/asCg== X-Google-Smtp-Source: AH8x226p/0BOdorU15SE2/e7tGNBHAf57LZZjK/o4W9e7BOc8iRNtOxqHPuNWtlSq1siUp7++aGUizPf2TMloPzB/kk= X-Received: by 10.31.222.67 with SMTP id v64mr3241623vkg.123.1517947575433; Tue, 06 Feb 2018 12:06:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.91.88 with HTTP; Tue, 6 Feb 2018 12:05:55 -0800 (PST) From: Aleksey Chernoraenko Date: Tue, 6 Feb 2018 14:05:55 -0600 Message-ID: To: scim@ietf.org Content-Type: multipart/alternative; boundary="94eb2c07cd76059807056490b67a" Archived-At: Subject: [scim] =?utf-8?q?Pagination_for_large_=E2=80=8Bmulti-valued_attri?= =?utf-8?q?butes?= X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 20:06:18 -0000 --94eb2c07cd76059807056490b67a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =E2=80=8B=E2=80=8B Hello, SCIM defines "startIndex" and "count" pagination query parameters that allow to control the amount of returned resources. SCIM protocol seems to represent pagination only for top level resources (e.g. /Users?startIndex=3D2&count=3D10) and does not address pagination for multi-valued attributes, like group membership. Are there any plans/draft or recommendations how to handle such use cases? --- Thank you, Alexei --94eb2c07cd76059807056490b67a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=E2=80=8B=E2=80=8B
Hello,

SCIM defi= nes "startIndex" and "count" pagination query parameter= s that allow to control the amount of returned resources.

SCIM proto= col seems to represent pagination only for top level resources (e.g. /Users= ?startIndex=3D2&count=3D10) and does not address pagination for multi-v= alued attributes, like group membership.

Are there any plans/draft o= r recommendations how to handle such use cases?

---
Thank you,Alexei
--94eb2c07cd76059807056490b67a-- From nobody Wed Feb 7 08:27:24 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 9E3D712E043 for ; Wed, 7 Feb 2018 08:27:19 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sailpoint.onmicrosoft.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 C_8folgYjFpX for ; Wed, 7 Feb 2018 08:27:14 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0134.outbound.protection.outlook.com [104.47.34.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A03F712E042 for ; Wed, 7 Feb 2018 08:27:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sailpoint.onmicrosoft.com; s=selector1-sailpoint-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yUwqwYj/LzatIUVCxjWrMH2TAWnq2QtxAMHpTx8/GHE=; b=PEhaaSwfeljpY5sDrBbrb75GxXfVWzo0mgoi+uD8Wsub55nESBXKl1RVQOoukJsQcChsv2QW0wEP7Bs+f3katYuPQOd2QGgaw/5WiRyL6XTzwvItEjVLbrA/KR/+zlHIBSJx3KIe2OuIFsweyk4OQqgzNxcblQs90x5wwv2ThRo= Received: from BN6PR04MB0339.namprd04.prod.outlook.com (10.168.225.20) by BN6PR04MB0898.namprd04.prod.outlook.com (10.174.95.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Wed, 7 Feb 2018 16:27:10 +0000 Received: from BN6PR04MB0339.namprd04.prod.outlook.com ([10.168.225.20]) by BN6PR04MB0339.namprd04.prod.outlook.com ([10.168.225.20]) with mapi id 15.20.0464.012; Wed, 7 Feb 2018 16:27:10 +0000 From: Kelly Grizzle To: Aleksey Chernoraenko , "scim@ietf.org" Thread-Topic: =?utf-8?B?W3NjaW1dIFBhZ2luYXRpb24gZm9yIGxhcmdlIOKAi211bHRpLXZhbHVlZCBh?= =?utf-8?Q?ttributes?= Thread-Index: AQHTn4X3vM15a5PZF0WfCZANqrJVD6OZIJ1w Date: Wed, 7 Feb 2018 16:27:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kelly.grizzle@sailpoint.com; x-originating-ip: [70.114.154.180] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR04MB0898; 7:tZD15pAqWBR2j4Jmh4yDjkc4yMgLHaReD99lcRoOa9Pb37VAV2XiyXLlmDyghZ3ikxK9gFuZ4ckjJjr2jEYz5s/plLUXIDdVluBjlHCixj+39vBOcPzdDcxP9YxP+9FQJ0eM0ELgaV6D7rbM0F0YwVa5bCY/ESi3fUhb5lTA6ulCoI7zWl3Xeiqe1m4CuHesL7A81ZbKlFXpvmTAGGoMdOfs0rOzfw7ia1U8QoO74JKynoY1UiItWPwbc//VZ7Qg x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c5280c7f-cea6-4f73-b3a5-08d56e47a353 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BN6PR04MB0898; x-ms-traffictypediagnostic: BN6PR04MB0898: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231101)(2400082)(944501161)(93006095)(93001095)(6041288)(20161123564045)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:BN6PR04MB0898; BCL:0; PCL:0; RULEID:; SRVR:BN6PR04MB0898; x-forefront-prvs: 0576145E86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39380400002)(376002)(39850400004)(396003)(346002)(199004)(189003)(77096007)(478600001)(102836004)(2906002)(39060400002)(33656002)(53546011)(5660300001)(59450400001)(6506007)(55016002)(74316002)(6116002)(790700001)(6436002)(7736002)(76176011)(6246003)(3280700002)(53936002)(7696005)(3660700001)(106356001)(54896002)(6306002)(66066001)(26005)(9686003)(229853002)(3846002)(2900100001)(14454004)(186003)(81156014)(81166006)(8936002)(105586002)(99286004)(68736007)(2501003)(97736004)(316002)(86362001)(2950100002)(25786009)(110136005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR04MB0898; H:BN6PR04MB0339.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sailpoint.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: dr34NStngRKhlWKlIhpN8qxoT6x+hp2vXdDSLMo/srCeKmpHX20/1t4yl7rXip5OsvOc0Ey0y+UDaS1kT84pJQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR04MB0339DA4DEAD2F499398CE612E2FC0BN6PR04MB0339namp_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com X-MS-Exchange-CrossTenant-Network-Message-Id: c5280c7f-cea6-4f73-b3a5-08d56e47a353 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2018 16:27:10.3292 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c848b2a-49ba-4c39-9749-118d06717a84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR04MB0898 Archived-At: Subject: Re: [scim] =?utf-8?q?Pagination_for_large_=E2=80=8Bmulti-valued_attr?= =?utf-8?q?ibutes?= X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 16:27:20 -0000 --_000_BN6PR04MB0339DA4DEAD2F499398CE612E2FC0BN6PR04MB0339namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxleGVpIOKAkyBObyB0aGVyZSBpcyBhIG5vdCBhIGRyYWZ0IG9yIHBsYW4gdG8gYWRkcmVz cyB0aGlzIGN1cnJlbnRseS4gIEl0IGhhcyBiZWVuIGRpc2N1c3NlZCwgYW5kIHRoZSB3b3JraW5n IGdyb3VwIGRlY2lkZWQgZm9yIG5vdyB0aGF0IHNlcnZpY2UgcHJvdmlkZXJzIGNhbiB1c2UgYSDi gJxyZXR1cm5lZOKAnSB2YWx1ZSBvZiDigJxyZXF1ZXN04oCdIGZvciBsYXJnZSBhdHRyaWJ1dGVz IHN1Y2ggYXMgdGhpcy4gIFRoaXMgcHJldmVudHMgdGhlIGZ1bGwgdmFsdWUgZnJvbSBiZWluZyBy ZXR1cm5lZCBvbiBtb3N0IGNhbGxzLCBidXQgZG9lcyBub3QgZ2l2ZSBhIGdyZWF0IHNvbHV0aW9u IGlmIHlvdSB3YW50IHRvIHJldHJpZXZlIHRoZSBmdWxsIGxpc3QuDQoNCkFsc28sIHRoaXMgaXMg b25lIG9mIHRoZSBwcm9ibGVtcyB0aGF0IHRoZSBQQVRDSCBvcGVyYXRpb24gaXMgdHJ5aW5nIHRv IGFkZHJlc3MuICBUaGlzIGFsbG93cyBjbGllbnRzIHRvIHVwZGF0ZSBsYXJnZSBhdHRyaWJ1dGVz IChhZGRpbmcgb3IgcmVtb3ZpbmcgdmFsdWVzKSB3aXRob3V0IGhhdmluZyB0byByZWFkIHRoZSBl bnRpcmUgYXR0cmlidXRlLg0KDQotLUtlbGx5DQoNCkZyb206IHNjaW0gW21haWx0bzpzY2ltLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGVrc2V5IENoZXJub3JhZW5rbw0KU2VudDog VHVlc2RheSwgRmVicnVhcnkgNiwgMjAxOCAyOjA2IFBNDQpUbzogc2NpbUBpZXRmLm9yZw0KU3Vi amVjdDogW3NjaW1dIFBhZ2luYXRpb24gZm9yIGxhcmdlIOKAi211bHRpLXZhbHVlZCBhdHRyaWJ1 dGVzDQoNCuKAi+KAiw0KSGVsbG8sDQoNClNDSU0gZGVmaW5lcyAic3RhcnRJbmRleCIgYW5kICJj b3VudCIgcGFnaW5hdGlvbiBxdWVyeSBwYXJhbWV0ZXJzIHRoYXQgYWxsb3cgdG8gY29udHJvbCB0 aGUgYW1vdW50IG9mIHJldHVybmVkIHJlc291cmNlcy4NCg0KU0NJTSBwcm90b2NvbCBzZWVtcyB0 byByZXByZXNlbnQgcGFnaW5hdGlvbiBvbmx5IGZvciB0b3AgbGV2ZWwgcmVzb3VyY2VzIChlLmcu IC9Vc2Vycz9zdGFydEluZGV4PTImY291bnQ9MTApIGFuZCBkb2VzIG5vdCBhZGRyZXNzIHBhZ2lu YXRpb24gZm9yIG11bHRpLXZhbHVlZCBhdHRyaWJ1dGVzLCBsaWtlIGdyb3VwIG1lbWJlcnNoaXAu DQoNCkFyZSB0aGVyZSBhbnkgcGxhbnMvZHJhZnQgb3IgcmVjb21tZW5kYXRpb25zIGhvdyB0byBo YW5kbGUgc3VjaCB1c2UgY2FzZXM/DQoNCi0tLQ0KVGhhbmsgeW91LA0KQWxleGVpDQo= --_000_BN6PR04MB0339DA4DEAD2F499398CE612E2FC0BN6PR04MB0339namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxp bms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhpIEFsZXhlaSDigJMgTm8gdGhlcmUgaXMgYSBub3QgYSBkcmFmdCBvciBwbGFuIHRv IGFkZHJlc3MgdGhpcyBjdXJyZW50bHkuJm5ic3A7IEl0IGhhcyBiZWVuIGRpc2N1c3NlZCwgYW5k IHRoZSB3b3JraW5nIGdyb3VwIGRlY2lkZWQgZm9yIG5vdyB0aGF0IHNlcnZpY2UgcHJvdmlkZXJz IGNhbiB1c2UgYSDigJxyZXR1cm5lZOKAnSB2YWx1ZSBvZiDigJxyZXF1ZXN04oCdIGZvciBsYXJn ZSBhdHRyaWJ1dGVzIHN1Y2ggYXMgdGhpcy4mbmJzcDsgVGhpcw0KIHByZXZlbnRzIHRoZSBmdWxs IHZhbHVlIGZyb20gYmVpbmcgcmV0dXJuZWQgb24gbW9zdCBjYWxscywgYnV0IGRvZXMgbm90IGdp dmUgYSBncmVhdCBzb2x1dGlvbiBpZiB5b3Ugd2FudCB0byByZXRyaWV2ZSB0aGUgZnVsbCBsaXN0 LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHNvLCB0aGlzIGlzIG9uZSBvZiB0aGUgcHJvYmxl bXMgdGhhdCB0aGUgUEFUQ0ggb3BlcmF0aW9uIGlzIHRyeWluZyB0byBhZGRyZXNzLiZuYnNwOyBU aGlzIGFsbG93cyBjbGllbnRzIHRvIHVwZGF0ZSBsYXJnZSBhdHRyaWJ1dGVzIChhZGRpbmcgb3Ig cmVtb3ZpbmcgdmFsdWVzKSB3aXRob3V0IGhhdmluZyB0byByZWFkIHRoZSBlbnRpcmUgYXR0cmli dXRlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLUtlbGx5PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPkZyb206PC9iPiBzY2ltIFttYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnXSA8Yj5P biBCZWhhbGYgT2YNCjwvYj5BbGVrc2V5IENoZXJub3JhZW5rbzxicj4NCjxiPlNlbnQ6PC9iPiBU dWVzZGF5LCBGZWJydWFyeSA2LCAyMDE4IDI6MDYgUE08YnI+DQo8Yj5Ubzo8L2I+IHNjaW1AaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3NjaW1dIFBhZ2luYXRpb24gZm9yIGxhcmdlIOKA i211bHRpLXZhbHVlZCBhdHRyaWJ1dGVzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbWJyaWEgTWF0aCZxdW90Oyxz ZXJpZiI+4oCL4oCLPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IZWxsbyw8YnI+DQo8YnI+DQpTQ0lNIGRlZmluZXMgJnF1b3Q7c3RhcnRJbmRleCZx dW90OyBhbmQgJnF1b3Q7Y291bnQmcXVvdDsgcGFnaW5hdGlvbiBxdWVyeSBwYXJhbWV0ZXJzIHRo YXQgYWxsb3cgdG8gY29udHJvbCB0aGUgYW1vdW50IG9mIHJldHVybmVkIHJlc291cmNlcy48YnI+ DQo8YnI+DQpTQ0lNIHByb3RvY29sIHNlZW1zIHRvIHJlcHJlc2VudCBwYWdpbmF0aW9uIG9ubHkg Zm9yIHRvcCBsZXZlbCByZXNvdXJjZXMgKGUuZy4gL1VzZXJzP3N0YXJ0SW5kZXg9MiZhbXA7Y291 bnQ9MTApIGFuZCBkb2VzIG5vdCBhZGRyZXNzIHBhZ2luYXRpb24gZm9yIG11bHRpLXZhbHVlZCBh dHRyaWJ1dGVzLCBsaWtlIGdyb3VwIG1lbWJlcnNoaXAuPGJyPg0KPGJyPg0KQXJlIHRoZXJlIGFu eSBwbGFucy9kcmFmdCBvciByZWNvbW1lbmRhdGlvbnMgaG93IHRvIGhhbmRsZSBzdWNoIHVzZSBj YXNlcz88YnI+DQo8YnI+DQotLS08YnI+DQpUaGFuayB5b3UsPGJyPg0KQWxleGVpPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR04MB0339DA4DEAD2F499398CE612E2FC0BN6PR04MB0339namp_-- From nobody Wed Feb 7 08:44:28 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 B5F4C124F57 for ; Wed, 7 Feb 2018 08:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 l2HT_s6TYNSQ for ; Wed, 7 Feb 2018 08:44:24 -0800 (PST) Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 F118912D7FB for ; Wed, 7 Feb 2018 08:44:23 -0800 (PST) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w17GfsUL081162; Wed, 7 Feb 2018 16:44:22 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2017-10-26; bh=kNDFeX7KFtn7ymOKTclEjmmnF3ZeFcxxIqsqhHL/HpY=; b=Y+iJSEtl7nb14oiwFTWfFEecYGoU5xcemeSEAPi8ztAPzVt97TN8o9OXjk18s5U3gvCZ KPd052jA9VbMkafAzpkz5DsG1FI3XOvJEYBULYdcbmNjbxV0UtKPXSE2p1S0I87r+a7O 9ekUOvHiggSzGIocJ0T8n44W3T3mgTY8G6MmPfU8w4CV/C/uH7KBvfHeyV03mP9M/X0L A7Kg7aU08vOJB2twDf5Je4yXxRWJG4XxOCx7asGfFcBAcybmfRn9IVpI67ZrftEY1Ami pjlRRdAo1xJQEBEFA0CiED7TKm7Heh28R9qWyNCCmM2eBhCX/guzcBQzlwSCwac/euWv jg== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2120.oracle.com with ESMTP id 2g04h38cdm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 07 Feb 2018 16:44:22 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w17GiLxA024953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 7 Feb 2018 16:44:21 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w17GiKo4027790; Wed, 7 Feb 2018 16:44:20 GMT Received: from [10.0.26.242] (/206.116.109.185) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Feb 2018 08:44:20 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-AC1FE571-1BAB-4C92-BB4B-B1D0FF88F075 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (15D60) In-Reply-To: Date: Wed, 7 Feb 2018 08:44:18 -0800 Cc: Aleksey Chernoraenko , "scim@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: To: Kelly Grizzle X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8798 signatures=668663 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-1711220000 definitions=main-1802070211 Archived-At: Subject: Re: [scim] =?utf-8?q?Pagination_for_large_=E2=80=8Bmulti-valued_attr?= =?utf-8?q?ibutes?= X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 16:44:27 -0000 --Apple-Mail-AC1FE571-1BAB-4C92-BB4B-B1D0FF88F075 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 There is also a practical problem of consistency. Paging in scim is subject t= o change between requests.=20 The group discussed supporting paging with a result set for consistency, but= the scale of intended scim usage would become challenging and expensive for= most implementers. It also opens the door to DoS attacks because of the res= ources such calls would consume.=20 Then there is the why question. Enumerating large groups raises privacy conc= erns. This type of action is usually quite limited to things like audit syst= ems. In these cases, because paging is not consistent, it is much better to e= at the whole elephant and get all values in one call.=20 Phil > On Feb 7, 2018, at 8:27 AM, Kelly Grizzle wr= ote: >=20 > Hi Alexei =E2=80=93 No there is a not a draft or plan to address this curr= ently. It has been discussed, and the working group decided for now that se= rvice providers can use a =E2=80=9Creturned=E2=80=9D value of =E2=80=9Creque= st=E2=80=9D for large attributes such as this. This prevents the full value= from being returned on most calls, but does not give a great solution if yo= u want to retrieve the full list. > =20 > Also, this is one of the problems that the PATCH operation is trying to ad= dress. This allows clients to update large attributes (adding or removing v= alues) without having to read the entire attribute. > =20 > --Kelly > =20 > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Aleksey Chernoraenk= o > Sent: Tuesday, February 6, 2018 2:06 PM > To: scim@ietf.org > Subject: [scim] Pagination for large =E2=80=8Bmulti-valued attributes > =20 > =E2=80=8B=E2=80=8B > Hello, >=20 > SCIM defines "startIndex" and "count" pagination query parameters that all= ow to control the amount of returned resources. >=20 > SCIM protocol seems to represent pagination only for top level resources (= e.g. /Users?startIndex=3D2&count=3D10) and does not address pagination for m= ulti-valued attributes, like group membership. >=20 > Are there any plans/draft or recommendations how to handle such use cases?= >=20 > --- > Thank you, > Alexei > _______________________________________________ > 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=3D85am0fsWIUdt_GtySTbIxdrAi= BPR9Uj7m4NCxKasMoU&s=3DgBOvAbkEpQlYlLgz-Xn119F9mavBadvf5oNyg6fICXI&e=3D --Apple-Mail-AC1FE571-1BAB-4C92-BB4B-B1D0FF88F075 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1

There is also a pract= ical problem of consistency. Paging in scim is subject to change between req= uests. 

The group discussed supporting paging w= ith a result set for consistency, but the scale of intended scim usage would= become challenging and expensive for most implementers. It also opens the d= oor to DoS attacks because of the resources such calls would consume. <= /div>

Then there is the why question. Enumerating large g= roups raises privacy concerns. This type of action is usually quite limited t= o things like audit systems. In these cases, because paging is not consisten= t, it is much better to eat the whole elephant and get all values in one cal= l. 

Phil

On Feb 7, 2018, at 8:27 AM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:
<= br>

Hi Alexei =E2=80=93 No there is a not a draft or plan= to address this currently.  It has been discussed, and the working gro= up decided for now that service providers can use a =E2=80=9Creturned=E2=80=9D= value of =E2=80=9Crequest=E2=80=9D for large attributes such as this. = This prevents the full value from being returned on most calls, but does not giv= e a great solution if you want to retrieve the full list.

 

Also, this is one of the problems that the PATCH oper= ation is trying to address.  This allows clients to update large attrib= utes (adding or removing values) without having to read the entire attribute= .

 

--Kelly

 

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Aleksey Chernoraenko
Sent: Tuesday, February 6, 2018 2:06 PM
To: scim@ietf.org
Subject: [scim] Pagination for large =E2=80=8Bmulti-valued attributes=

 

=E2=80=8B=E2=80=8B

Hello,

SCIM defines "startIndex" and "count" pagination query parameters that allow= to control the amount of returned resources.

SCIM protocol seems to represent pagination only for top level resources (e.= g. /Users?startIndex=3D2&count=3D10) and does not address pagination for= multi-valued attributes, like group membership.

Are there any plans/draft or recommendations how to handle such use cases?
---
Thank you,
Alexei

= --Apple-Mail-AC1FE571-1BAB-4C92-BB4B-B1D0FF88F075-- From nobody Wed Feb 7 13:20:05 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 13AA4128961 for ; Wed, 7 Feb 2018 13:20:04 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=oneidentity.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 LDh7ZGXW5UUv for ; Wed, 7 Feb 2018 13:20:01 -0800 (PST) Received: from amersmtp4.quest.com (amersmtp4.quest.com [12.106.87.249]) (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 3762112711D for ; Wed, 7 Feb 2018 13:20:00 -0800 (PST) Received: from amersmtp4.quest.com (127.0.0.1) id hfdmo20171s4 for ; Wed, 7 Feb 2018 13:20:00 -0800 (envelope-from ) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oneidentity.com; s=default; i=@oneidentity.com; h=Received: Received:Received:From:To:CC:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:Content-Type:Content-Transfer-Encoding: MIME-Version; bh=iItAzf279CJhlyYehxHScMnSZZOvuRlZYsZ9MDLqKjM=; b=b/MO8oFgEos6QfVCWtgCztvDcg0HxfXDT+sYfXCdMBdAA0I60eJZ8eu/6Ey8ZV lI7/OuL23klP0w0KYxQcYMYr789tHhnV/Hlab2gBhuQMVuyOyYUea11JdJTA8kce E5U4H4nTo4goBcXdmVkb8+UPLW6RuWzUUwnqQVuxI26RE= Received: from alvetxw02.prod.quest.corp ([10.1.100.92]) by amersmtp4.quest.com ([10.1.100.249]) (SonicWALL 9.0.5.2075 ) with ESMTPS (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256/256) id o201802072119590411408-82; Wed, 07 Feb 2018 13:19:59 -0800 Received: from ALVHTXW01.prod.quest.corp (10.1.135.17) by ALVETXW02.alvetxw02.prod.quest.corp (10.1.100.92) with Microsoft SMTP Server (TLS) id 14.3.279.2; Wed, 7 Feb 2018 13:19:59 -0800 Received: from ALVMBXW01.prod.quest.corp ([fe80::cc5a:be3d:40e:3012]) by ALVHTXW01.prod.quest.corp ([::1]) with mapi id 14.03.0279.002; Wed, 7 Feb 2018 13:19:59 -0800 From: "Matt Peterson (mpeterso)" To: Aleksey Chernoraenko CC: "scim@ietf.org" Thread-Topic: =?utf-8?B?W3NjaW1dICBQYWdpbmF0aW9uIGZvciBsYXJnZSDigIttdWx0aS12YWx1ZWQg?= =?utf-8?Q?attributes?= Thread-Index: AQHToDL1fomR8UCSo0u93DiivwVO4KOZTAng Date: Wed, 7 Feb 2018 21:19:58 +0000 Message-ID: <7F2B7AC6C3EEDC4A9C067A7852FA8A2D4AA18A89@ALVMBXW01.prod.quest.corp> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.104.155] x-c2processedorg: 0b7fb32a-9e41-4a01-8d60-ef67dd9ea696 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Mlf-CnxnMgmt-Allow: 10.1.100.92 X-Mlf-Version: 9.0.5.2075 X-Mlf-License: BSVKCAPE_ X-Mlf-UniqueId: o201802072119590411408 Archived-At: Subject: Re: [scim] =?utf-8?q?Pagination_for_large_=E2=80=8Bmulti-valued_attr?= =?utf-8?q?ibutes?= X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 21:20:04 -0000 QWxlc2tleSwNCg0KSSB3aXNoIHRoZXJlIHdlcmUgYSBiZXR0ZXIgYW5zd2VyIHRvIHlvdXIgcXVl c3Rpb24gdGhhbiB0aGUgb25lIGZyb20gS2VsbHkuICBSZXByZXNlbnRpbmcgZ3JvdXAgbWVtYmVy c2hpcHMgYXMgbXVsdGktdmFsdWVkIGF0dHJpYnV0ZXMgaXMgYSBtYXRlcmlhbCBmbGF3IGluIFND SU0uDQoNCkkgdGhpbmsgdGhhdCB0aGUg4oCcR2V0QWxs4oCdIHNjZW5hcmlvIGlzIG11Y2ggbW9y ZSBjb21tb24gdGhhdCB0aGUgU0NJTSBhdXRob3JzIGFudGljaXBhdGVkLiAgIEkgd291bGQgYmUg dmVyeSBzdXBwb3J0aXZlIG9mIGEgZHJhZnQgcHJvcG9zaW5nIGEgYmV0dGVyIHJlcHJlc2VudGF0 aW9uIGZvciBncm91cCBtZW1iZXJzaGlwLiAgVGhlcmUgYXJlIHNldmVyYWwgd2VsbCBkZXNpZ24g cGF0dGVybnMgdGhhdCBjb3VsZCBiZSBmb2xsb3dlZC4gIA0KDQpJcyB0aGVyZSBhbnlvbmUgb3V0 IHRoZXJlIHRoYXQgdGhpbmtzIHRoaXMgaXMgYSBwcm9ibGVtIHdvcnRoIGFkZHJlc3Npbmcgd2l0 aCBhIGRyYWZ0PyAgDQoNCi0tDQpNYXR0DQoNCkZyb206IFBoaWwgSHVudCBbbWFpbHRvOnBoaWwu aHVudEBvcmFjbGUuY29tXSANClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgNywgMjAxOCA5OjQ0 IEFNDQpUbzogS2VsbHkgR3JpenpsZSA8a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tPg0KQ2M6 IEFsZWtzZXkgQ2hlcm5vcmFlbmtvIDxhY2hlcm5vcmFlbmtvQGdtYWlsLmNvbT47IHNjaW1AaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2NpbV0gUGFnaW5hdGlvbiBmb3IgbGFyZ2Ug4oCLbXVsdGkt dmFsdWVkIGF0dHJpYnV0ZXMNCg0KKzENCg0KVGhlcmUgaXMgYWxzbyBhIHByYWN0aWNhbCBwcm9i bGVtIG9mIGNvbnNpc3RlbmN5LiBQYWdpbmcgaW4gc2NpbSBpcyBzdWJqZWN0IHRvIGNoYW5nZSBi ZXR3ZWVuIHJlcXVlc3RzLsKgDQoNClRoZSBncm91cCBkaXNjdXNzZWQgc3VwcG9ydGluZyBwYWdp bmcgd2l0aCBhIHJlc3VsdCBzZXQgZm9yIGNvbnNpc3RlbmN5LCBidXQgdGhlIHNjYWxlIG9mIGlu dGVuZGVkIHNjaW0gdXNhZ2Ugd291bGQgYmVjb21lIGNoYWxsZW5naW5nIGFuZCBleHBlbnNpdmUg Zm9yIG1vc3QgaW1wbGVtZW50ZXJzLiBJdCBhbHNvIG9wZW5zIHRoZSBkb29yIHRvIERvUyBhdHRh Y2tzIGJlY2F1c2Ugb2YgdGhlIHJlc291cmNlcyBzdWNoIGNhbGxzIHdvdWxkIGNvbnN1bWUuwqAN Cg0KVGhlbiB0aGVyZSBpcyB0aGUgd2h5IHF1ZXN0aW9uLiBFbnVtZXJhdGluZyBsYXJnZSBncm91 cHMgcmFpc2VzIHByaXZhY3kgY29uY2VybnMuIFRoaXMgdHlwZSBvZiBhY3Rpb24gaXMgdXN1YWxs eSBxdWl0ZSBsaW1pdGVkIHRvIHRoaW5ncyBsaWtlIGF1ZGl0IHN5c3RlbXMuIEluIHRoZXNlIGNh c2VzLCBiZWNhdXNlIHBhZ2luZyBpcyBub3QgY29uc2lzdGVudCwgaXQgaXMgbXVjaCBiZXR0ZXIg dG8gZWF0IHRoZSB3aG9sZSBlbGVwaGFudCBhbmQgZ2V0IGFsbCB2YWx1ZXMgaW4gb25lIGNhbGwu wqANCg0KUGhpbA0KDQpPbiBGZWIgNywgMjAxOCwgYXQgODoyNyBBTSwgS2VsbHkgR3JpenpsZSA8 bWFpbHRvOmtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbT4gd3JvdGU6DQpIaSBBbGV4ZWkg4oCT IE5vIHRoZXJlIGlzIGEgbm90IGEgZHJhZnQgb3IgcGxhbiB0byBhZGRyZXNzIHRoaXMgY3VycmVu dGx5LsKgIEl0IGhhcyBiZWVuIGRpc2N1c3NlZCwgYW5kIHRoZSB3b3JraW5nIGdyb3VwIGRlY2lk ZWQgZm9yIG5vdyB0aGF0IHNlcnZpY2UgcHJvdmlkZXJzIGNhbiB1c2UgYSDigJxyZXR1cm5lZOKA nSB2YWx1ZSBvZiDigJxyZXF1ZXN04oCdIGZvciBsYXJnZSBhdHRyaWJ1dGVzIHN1Y2ggYXMgdGhp cy7CoCBUaGlzIHByZXZlbnRzIHRoZSBmdWxsIHZhbHVlIGZyb20gYmVpbmcgcmV0dXJuZWQgb24g bW9zdCBjYWxscywgYnV0IGRvZXMgbm90IGdpdmUgYSBncmVhdCBzb2x1dGlvbiBpZiB5b3Ugd2Fu dCB0byByZXRyaWV2ZSB0aGUgZnVsbCBsaXN0Lg0KwqANCkFsc28sIHRoaXMgaXMgb25lIG9mIHRo ZSBwcm9ibGVtcyB0aGF0IHRoZSBQQVRDSCBvcGVyYXRpb24gaXMgdHJ5aW5nIHRvIGFkZHJlc3Mu wqAgVGhpcyBhbGxvd3MgY2xpZW50cyB0byB1cGRhdGUgbGFyZ2UgYXR0cmlidXRlcyAoYWRkaW5n IG9yIHJlbW92aW5nIHZhbHVlcykgd2l0aG91dCBoYXZpbmcgdG8gcmVhZCB0aGUgZW50aXJlIGF0 dHJpYnV0ZS4NCsKgDQotLUtlbGx5DQrCoA0KRnJvbTogc2NpbSBbbWFpbHRvOnNjaW0tYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsZWtzZXkgQ2hlcm5vcmFlbmtvDQpTZW50OiBUdWVz ZGF5LCBGZWJydWFyeSA2LCAyMDE4IDI6MDYgUE0NClRvOiBtYWlsdG86c2NpbUBpZXRmLm9yZw0K U3ViamVjdDogW3NjaW1dIFBhZ2luYXRpb24gZm9yIGxhcmdlIOKAi211bHRpLXZhbHVlZCBhdHRy aWJ1dGVzDQrCoA0K4oCL4oCLDQpIZWxsbywNCg0KU0NJTSBkZWZpbmVzICJzdGFydEluZGV4IiBh bmQgImNvdW50IiBwYWdpbmF0aW9uIHF1ZXJ5IHBhcmFtZXRlcnMgdGhhdCBhbGxvdyB0byBjb250 cm9sIHRoZSBhbW91bnQgb2YgcmV0dXJuZWQgcmVzb3VyY2VzLg0KDQpTQ0lNIHByb3RvY29sIHNl ZW1zIHRvIHJlcHJlc2VudCBwYWdpbmF0aW9uIG9ubHkgZm9yIHRvcCBsZXZlbCByZXNvdXJjZXMg KGUuZy4gL1VzZXJzP3N0YXJ0SW5kZXg9MiZjb3VudD0xMCkgYW5kIGRvZXMgbm90IGFkZHJlc3Mg cGFnaW5hdGlvbiBmb3IgbXVsdGktdmFsdWVkIGF0dHJpYnV0ZXMsIGxpa2UgZ3JvdXAgbWVtYmVy c2hpcC4NCg0KQXJlIHRoZXJlIGFueSBwbGFucy9kcmFmdCBvciByZWNvbW1lbmRhdGlvbnMgaG93 IHRvIGhhbmRsZSBzdWNoIHVzZSBjYXNlcz8NCg0KLS0tDQpUaGFuayB5b3UsDQpBbGV4ZWkNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzY2ltIG1haWxp bmcgbGlzdA0KbWFpbHRvOnNjaW1AaWV0Zi5vcmcNCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9f c2NpbSZkPUR3SUNBZyZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9K bkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09ODVhbTBm c1dJVWR0X0d0eVNUYkl4ZHJBaUJQUjlVajdtNE5DeEthc01vVSZzPWdCT3ZBYmtFcFFsWWxMZ3ot WG4xMTlGOW1hdkJhZHZmNW9OeWc2ZklDWEkmZT0NCg== From nobody Wed Feb 7 21:00:09 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 B2D5F124BFA for ; Wed, 7 Feb 2018 21:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, 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=gmail.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 JWGPWEJMBSok for ; Wed, 7 Feb 2018 21:00:04 -0800 (PST) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (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 527491241F3 for ; Wed, 7 Feb 2018 21:00:04 -0800 (PST) Received: by mail-ua0-x236.google.com with SMTP id q8so2113208uae.4 for ; Wed, 07 Feb 2018 21:00:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=t5nV2WNPhVR0gbww1EX4kHw9F5IV4JY/noHPfQy+Nig=; b=OuCohTpK5K8x3AAiXxQZFNyTrtwwZNco8A9dtwFtD5P2JGxA4rccuCRDOhDYqBnl41 INzTaqyj5ckQQk+MgzkiFULYu9AXG7aJCJQQHQTsu7+L1tEJEqnIm/8yqoC1MQmk0UYe szX8HvnsTukIF6vMLx2oEOZnsbCOU6Bw0q7H5g5AYXz/DoUDYcIdNeu7PJ+MWhDce6gz /P9sOxi1ft5P1KFBhJMs+0Z8qfkRSU5FkkMeIJV93r+q5qAKKZIGJLu9KqyYPWptGedm JapF2VSqD74cTCmfHO8hAWKZXfKs/4KCiZwvC5sVCeDOThdapIB0pJLX40/e9hWTJUu2 VyYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=t5nV2WNPhVR0gbww1EX4kHw9F5IV4JY/noHPfQy+Nig=; b=DRq7GJDS/sSjB6HKEvqWat0zlJyn5WeSgn1ZATPejwqavye9hSWQ59PCgr/Jk22ufc UaugdGpRCQVcb5XUfqh+EqAb09Ei8MJYLE0YEbFFjMoixobIbdA6DElOPiLNEeWGBQSL wQ45lQN8sZzAXBz3BZ+EXiAiYVnjOrUoEItvxdFvVQL9UtVj4PHKcbMKrLc3PiqqyO5C CjNP1WkqrA7V9od+xvk/ahFC2oXIASe7jh0ecZAFXUH7hpG5yyKNz78rRfCXLbxLvfxZ KC/tkULhcloEeahzOkXQiNGN0QEK3w8kruHogv6FgkHN0UOP1eLnC1thGg/QGRYhL1Y4 rZMA== X-Gm-Message-State: APf1xPBt7hcxiUwYC2sjM8KAVd0kbd9WbEO52lOkRgpQkXxQJy5o8CPM 7eFeaVLqjtZbaqOJUBbr2hWEfNiXAVUsi+ojrqsUQA== X-Google-Smtp-Source: AH8x2259zmvbPJbikzKjnHcFrzPyRle+5rLtWtUSiXJ4f5LQh+xi0DboLozcztkYe5FK4qskmcIPjpcvkzIFZfFcebc= X-Received: by 10.176.81.171 with SMTP id g40mr7509463uaa.150.1518066003300; Wed, 07 Feb 2018 21:00:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.91.88 with HTTP; Wed, 7 Feb 2018 20:59:42 -0800 (PST) In-Reply-To: <7F2B7AC6C3EEDC4A9C067A7852FA8A2D4AA18A89@ALVMBXW01.prod.quest.corp> References: <7F2B7AC6C3EEDC4A9C067A7852FA8A2D4AA18A89@ALVMBXW01.prod.quest.corp> From: Aleksey Chernoraenko Date: Wed, 7 Feb 2018 22:59:42 -0600 Message-ID: To: "scim@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c18f980df54b60564ac4894" Archived-At: Subject: Re: [scim] =?utf-8?q?Pagination_for_large_=E2=80=8Bmulti-valued_attr?= =?utf-8?q?ibutes?= X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 05:00:07 -0000 --94eb2c18f980df54b60564ac4894 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Matt, =E2=80=9Crequest=E2=80=9D value for =E2=80=9Creturned=E2=80=9D will work, a= nd I think this should be default for large attributes. My initial idea was to use SCIM as a general CRUD api for all our IAM resources, not only for the ones that are allowed for provisioning - we wouldn't want to support another interface (e.g. OData). If pagination for such attributes is a problem, we will have to come up with some kind of extension. On the other hand, addressing this in more general terms would be helpful. --- Alexei On Wed, Feb 7, 2018 at 3:19 PM, Matt Peterson (mpeterso) < Matt.Peterson@oneidentity.com> wrote: > Aleskey, > > I wish there were a better answer to your question than the one from > Kelly. Representing group memberships as multi-valued attributes is a > material flaw in SCIM. > > I think that the =E2=80=9CGetAll=E2=80=9D scenario is much more common th= at the SCIM > authors anticipated. I would be very supportive of a draft proposing a > better representation for group membership. There are several well desig= n > patterns that could be followed. > > Is there anyone out there that thinks this is a problem worth addressing > with a draft? > > -- > Matt > > From: Phil Hunt [mailto:phil.hunt@oracle.com] > Sent: Wednesday, February 7, 2018 9:44 AM > To: Kelly Grizzle > Cc: Aleksey Chernoraenko ; scim@ietf.org > Subject: Re: [scim] Pagination for large =E2=80=8Bmulti-valued attributes > > +1 > > There is also a practical problem of consistency. Paging in scim is > subject to change between requests. > > The group discussed supporting paging with a result set for consistency, > but the scale of intended scim usage would become challenging and expensi= ve > for most implementers. It also opens the door to DoS attacks because of t= he > resources such calls would consume. > > Then there is the why question. Enumerating large groups raises privacy > concerns. This type of action is usually quite limited to things like aud= it > systems. In these cases, because paging is not consistent, it is much > better to eat the whole elephant and get all values in one call. > > Phil > > On Feb 7, 2018, at 8:27 AM, Kelly Grizzle sailpoint.com> wrote: > Hi Alexei =E2=80=93 No there is a not a draft or plan to address this cur= rently. > It has been discussed, and the working group decided for now that service > providers can use a =E2=80=9Creturned=E2=80=9D value of =E2=80=9Crequest= =E2=80=9D for large attributes such > as this. This prevents the full value from being returned on most calls, > but does not give a great solution if you want to retrieve the full list. > > Also, this is one of the problems that the PATCH operation is trying to > address. This allows clients to update large attributes (adding or > removing values) without having to read the entire attribute. > > --Kelly > > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Aleksey > Chernoraenko > Sent: Tuesday, February 6, 2018 2:06 PM > To: mailto:scim@ietf.org > Subject: [scim] Pagination for large =E2=80=8Bmulti-valued attributes > > =E2=80=8B=E2=80=8B > Hello, > > SCIM defines "startIndex" and "count" pagination query parameters that > allow to control the amount of returned resources. > > SCIM protocol seems to represent pagination only for top level resources > (e.g. /Users?startIndex=3D2&count=3D10) and does not address pagination f= or > multi-valued attributes, like group membership. > > Are there any plans/draft or recommendations how to handle such use cases= ? > > --- > Thank you, > Alexei > _______________________________________________ > scim mailing list > mailto:scim@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_scim&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7= qIr > MUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPk > AI1aLcLN4KZNA&m=3D85am0fsWIUdt_GtySTbIxdrAiBPR9Uj7m4NCxKasMoU > &s=3DgBOvAbkEpQlYlLgz-Xn119F9mavBadvf5oNyg6fICXI&e=3D > --=20 Best regards, Aleksey Chernoraenko --94eb2c18f980df54b60564ac4894 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Matt,

=E2=80=9Crequest=E2=80=9D value for =E2=80=9C= returned=E2=80=9D will work, and I think this should be default for large a= ttributes.

My initial idea was to use SCIM as a general CRUD api for= all our IAM resources, not only for the ones that are allowed for provisio= ning - we wouldn't want to support another interface (e.g. OData).
I= f pagination for such attributes is a problem, we will have to come up with= some kind of extension.


On the other hand, addressing this in m= ore general terms would be helpful.

---
Alexei


On Wed, Feb 7, 2018 at 3:19 = PM, Matt Peterson (mpeterso) <Matt.Peterson@oneidentity.com> wrote:
Al= eskey,

I wish there were a better answer to your question than the one from Kelly.= =C2=A0 Representing group memberships as multi-valued attributes is a mater= ial flaw in SCIM.

I think that the =E2=80=9CGetAll=E2=80=9D scenario is much more common that= the SCIM authors anticipated.=C2=A0 =C2=A0I would be very supportive of a = draft proposing a better representation for group membership.=C2=A0 There a= re several well design patterns that could be followed.

Is there anyone out there that thinks this is a problem worth addressing wi= th a draft?

--
Matt

From: Phil Hunt [mailto:phil.hunt@o= racle.com]
Sent: Wednesday, February 7, 2018 9:44 AM
To: Kelly Grizzle <kelly.= grizzle@sailpoint.com>
Cc: Aleksey Chernoraenko <ach= ernoraenko@gmail.com>; scim@ietf.or= g
Subject: Re: [scim] Pagination for large =E2=80=8Bmulti-valued attributes
+1

There is also a practical problem of consistency. Paging in scim is subject= to change between requests.=C2=A0

The group discussed supporting paging with a result set for consistency, bu= t the scale of intended scim usage would become challenging and expensive f= or most implementers. It also opens the door to DoS attacks because of the = resources such calls would consume.=C2=A0

Then there is the why question. Enumerating large groups raises privacy con= cerns. This type of action is usually quite limited to things like audit sy= stems. In these cases, because paging is not consistent, it is much better = to eat the whole elephant and get all values in one call.=C2=A0

Phil

On Feb 7, 2018, at 8:27 AM, Kelly Grizzle <= ;mailto:kelly.grizzle@s= ailpoint.com> wrote:
Hi Alexei =E2=80=93 No there is a not a draft or plan to address this curre= ntly.=C2=A0 It has been discussed, and the working group decided for now th= at service providers can use a =E2=80=9Creturned=E2=80=9D value of =E2=80= =9Crequest=E2=80=9D for large attributes such as this.=C2=A0 This prevents = the full value from being returned on most calls, but does not give a great= solution if you want to retrieve the full list.
=C2=A0
Also, this is one of the problems that the PATCH operation is trying to add= ress.=C2=A0 This allows clients to update large attributes (adding or remov= ing values) without having to read the entire attribute.
=C2=A0
--Kelly
=C2=A0
From: scim [mailto:scim-bounces@ie= tf.org] On Behalf Of Aleksey Chernoraenko
Sent: Tuesday, February 6, 2018 2:06 PM
To: mailto:scim@ietf.org
Subject: [scim] Pagination for large =E2=80=8Bmulti-= valued attributes
=C2=A0
=E2=80=8B=E2=80=8B
Hello,

SCIM defines "startIndex" and "count" pagination query = parameters that allow to control the amount of returned resources.

SCIM protocol seems to represent pagination only for top level resources (e= .g. /Users?startIndex=3D2&count=3D10) and does not address pagination f= or multi-valued attributes, like group membership.

Are there any plans/draft or recommendations how to handle such use cases?<= br>
---
Thank you,
Alexei
_______________________________________________
scim mailing list
mailto:scim@ietf.org
http= s://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_m= ailman_listinfo_scim&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8P= Zh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D85am0fsWIUdt_GtySTbIxdrAiBPR9Uj7m4NCxKasMoU&s=3DgBOvAbkEpQlYlLgz-Xn119F9mavBadvf5oNyg6fICXI&e=3D



--
Best regards,
Aleksey Chernoraenko
--94eb2c18f980df54b60564ac4894-- From nobody Tue Feb 27 04:54:07 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 896E3126BFD for ; Tue, 27 Feb 2018 04:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 leVMyqEM_b4i for ; Tue, 27 Feb 2018 04:54:04 -0800 (PST) Received: from surlej.switch.ch (surlej.switch.ch [IPv6:2001:620:0:1001::69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0B4212420B for ; Tue, 27 Feb 2018 04:54:03 -0800 (PST) Received: from macrb.switch.ch ([130.59.17.20]) by surlej.switch.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1eqeld-0004FH-Gf for scim@ietf.org; Tue, 27 Feb 2018 13:54:01 +0100 To: "scim@ietf.org" From: Rolf Brugger Message-ID: Date: Tue, 27 Feb 2018 13:54:01 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [scim] Schema Extension Question X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 12:54:06 -0000 Hi all, We plan to use SCIM in one of our services. We will need a schema extension, and I was wondering if we can choose our own schema extension URI, or if it has to be hierarchically below in the namespace "urn:ietf:params:scim:schemas:extension"? Does our extension have to be registered somewhere? If we can define our own URI, we would probably use something like "urn:mace:switch.ch:SWITCHeduid" (according to https://www.switch.ch/aai/mace/ ) Cheers Rolf -- SWITCH Rolf Brugger, Trust & Identity Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland direct +41 44 268 15 89 rolf.brugger@switch.ch, https://www.switch.ch From nobody Wed Feb 28 07:24:13 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 AEA0212D88F for ; Wed, 28 Feb 2018 07:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 LwJMnt8qG2FB for ; Wed, 28 Feb 2018 07:24:11 -0800 (PST) Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (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 0B32812D77C for ; Wed, 28 Feb 2018 07:24:10 -0800 (PST) Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w1SFMBVT032048; Wed, 28 Feb 2018 15:24:08 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2017-10-26; bh=Rx00NKAId8IijYn2WCskpjvGcZI0SPeCSFMIA4FwMZ8=; b=g6qPYWIoBowWqApu3uCpj65RUw6NcBdNPGB80cWFLTugioNjJTm7O4KtEKjvp9/3ghOq fuecSP66+PtoPS/qK+BJtznX8iCNEmapl9uesg3AyrHi+huBaVMGKOy06Hzv+hkJkVQN x1ukLarBIwXjHp05o1+bTpjnxNjZVDRMnWcMgKIemtQqK1EJeJhTGeY8XGtRA2vzVjJX dmoh95Bzj7DVSqpMhlCjRPPElzWP2FJZqiOwJ6CSn2FiSByLQ80g+s3nIUNgxsWkxhnu SekzeuT3+/5Pub4wLHd+J/1C6QoU4rb6wBut+88AUnveK3AgyQzUzfNEGFAe14WlLkri CQ== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2130.oracle.com with ESMTP id 2gdvx90t5k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 28 Feb 2018 15:24:08 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w1SFO71i004125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 28 Feb 2018 15:24:07 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w1SFO7wq020750; Wed, 28 Feb 2018 15:24:07 GMT Received: from [192.168.1.27] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Feb 2018 07:24:07 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (15D60) In-Reply-To: Date: Wed, 28 Feb 2018 07:24:05 -0800 Cc: "scim@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1C072172-9EF8-4941-B0D8-7FAF8BEAF8A6@oracle.com> References: To: Rolf Brugger X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8817 signatures=668681 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-1711220000 definitions=main-1802280187 Archived-At: Subject: Re: [scim] Schema Extension Question X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 15:24:13 -0000 There is a registration process described in the IANA section.=20 In practice people don=E2=80=99t usually register schemas for local or speci= fic deployment use and often do use shorter urns. This can become a migratio= n issue if you have a need to register in IANA SCIM registry down the road. = =20 Phil > On Feb 27, 2018, at 4:54 AM, Rolf Brugger wrote: >=20 > Hi all, >=20 > We plan to use SCIM in one of our services. We will need a schema extensio= n, and I was wondering if we can choose our own schema extension URI, or if i= t has to be hierarchically below in the namespace "urn:ietf:params:scim:sche= mas:extension"? >=20 > Does our extension have to be registered somewhere? >=20 > If we can define our own URI, we would probably use something like "urn:ma= ce:switch.ch:SWITCHeduid" (according to https://urldefense.proofpoint.com/v2= /url?u=3Dhttps-3A__www.switch.ch_aai_mace_&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZY= R8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D= KN5wrUhJxy4TFaMiUQf1CBiiMb-8XYyOkA48eBy0aOQ&s=3D1d1TRPe015MDsqAKfOBvNgx0Sig5= JWdWY0RjXgPMgbc&e=3D ) >=20 > Cheers > Rolf >=20 > --=20 > SWITCH > Rolf Brugger, Trust & Identity > Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland > direct +41 44 268 15 89 > rolf.brugger@switch.ch, https://urldefense.proofpoint.com/v2/url?u=3Dhttps= -3A__www.switch.ch&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_Jn= E&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DKN5wrUhJxy4TFaMiUQf1CB= iiMb-8XYyOkA48eBy0aOQ&s=3DHIHzAVwT2UgaGrfLDDtvZcMGBYAS39E2WLrNuYkvuEg&e=3D >=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=3DKN5wrUhJxy4TFaMiUQf1CBiiM= b-8XYyOkA48eBy0aOQ&s=3D76joCnl202Nd9yuHIK6zFCzH6AwnMFLokMtLtyGVFoQ&e=3D