From nobody Tue Feb 25 12:09:47 2020 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 1AEF73A11A0 for ; Tue, 25 Feb 2020 12:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 VbsUaCud7lB3 for ; Tue, 25 Feb 2020 12:09:44 -0800 (PST) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 13E5F3A1138 for ; Tue, 25 Feb 2020 12:09:43 -0800 (PST) Received: by mail-vs1-xe34.google.com with SMTP id c18so288605vsq.7 for ; Tue, 25 Feb 2020 12:09:43 -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=q5jPF11xNyaN3p62rbNywNsC+eLqrvON+Ci2ktrIHJc=; b=ZEcAwoLFCxDnHabUaZyvD6GoilaX+jYLPvlZPWJRgjv6DwL9B2kC7+dY0yYeEjUTcK VG2pxiOCbs2114ZAfGe8N16oSIdHZxIX8Mr5GOcHlJGmunLPE/TajLsMtpGJ+69etzYJ AfGhS24cHFGc1s/QwthKp4GQOYN8rAVHdF/xLEdaS8kWEfPVBulVt9rXeF86d4Qvw0g3 8J109nrYmDXjeAEuRmecjbfvuhavloA4BdL6DB+DDZTPSyDqvxlg8V6YtoOJY8zDRrJp Z9aP4bY3J6qFsudQ0VqLzcfKnL/x8sSasl5yrASjKeLJf26LoMA5Ufo7wK9cjo7CPmpK bJdg== 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=q5jPF11xNyaN3p62rbNywNsC+eLqrvON+Ci2ktrIHJc=; b=XtrceW3Ao3FtOtB9dqVIygePzqGzaxQjO9pMCOJ4nn0PyvTWwlPNu3jfQ2RwgATFhh b5SDMmX0qlPKaYDRc3bQM08AGuC1/jbqU6X4E0rJYu0ZhyOxilXbX/Bb9wXi3G8X2ZVZ aWZL0nTqOa1SADU9xd0FatElCCuGHA2Br529jhk9Zov6O3fDOB0gxeO8fXyYF+qhcHeC wfCEBJMK8C3FwabDJY25KkPWcywcL1a05wdfmnEt7uMi+vvlrn2eCnyV/M0d9SEvFxzH gErbnaizAGNtJp2GaLGpDW8I5FV7rOfQoOtoBoFDh8iSoFvGNdVqR5jR79MftZNTDR/a L4zg== X-Gm-Message-State: APjAAAX+358LQebK8NBuCNoKh71+kPCXC4CtTS3tZDembKPz3U4/Jrt+ uJo6cAL/dq56W7CUg/qyFAxp/os+BzM65QO8XUg7ll+G X-Google-Smtp-Source: APXvYqxjKNGO9GThHWQ8BilojWo/SES/hIuPACzh59dMBJP6zKezH4YGvct1OXAEd+OsJUPJiqEjJdVvwCJLfKpZEDg= X-Received: by 2002:a05:6102:190:: with SMTP id r16mr732174vsq.215.1582661382026; Tue, 25 Feb 2020 12:09:42 -0800 (PST) MIME-Version: 1.0 From: Shelley Date: Tue, 25 Feb 2020 14:09:30 -0600 Message-ID: To: scim@ietf.org Content-Type: multipart/alternative; boundary="00000000000079b864059f6c1138" Archived-At: Subject: [scim] HTTP Status Code 501 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 20:09:46 -0000 --00000000000079b864059f6c1138 Content-Type: text/plain; charset="UTF-8" */Me Endpoint Support* The SCIM 2 specification indicates that if a service provider does not support the "/Me" endpoint, it should respond with HTTP 501 [1]. This doesn't seem inline with the HTTP specification, which indicates that 501 is used when the server *does not recognize the request method* [2]. In the case of the "/Me" endpoint, however, the server *does *recognize the *method* (GET), but simply does not support a representation for the requested resource, which seems more inline with a *404* [3]. What was the reasoning behind the 501? Given the requirement is a "SHOULD" recommendation, I'm inclined to return the HTTP standard 404 in my service provider implementation, instead of the SCIM recommended 501. *PATCH Operation Support* The SCIM 1.1 and 2.0 specifications also imply that 501 should be returned when PATCH is not supported [4]. This also seems to violate the HTTP spec, if the server recognizes the PATCH method, but simply does not support this method for the requested resource. Instead, a *405* (Method Not Allowed) [5] seems more appropriate. [1] https://tools.ietf.org/html/rfc7644#section-3.11 [2] https://tools.ietf.org/html/rfc7231#section-6.6.2 [3] https://tools.ietf.org/html/rfc7231#section-6.5.4 [4] https://tools.ietf.org/html/rfc7644#section-3.12 [5] https://tools.ietf.org/html/rfc7231#section-6.5.5 --00000000000079b864059f6c1138 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
/Me Endpoint Support

The SCIM 2 speci= fication indicates that if a service provider does not support the "/M= e" endpoint, it should respond with HTTP 501 [1].

This doesn= 9;t seem inline with the HTTP specification, which indicates that 501 is us= ed when the server does not recognize the request method [2].=

In the case of the "/Me" endpoint, however, the server does recognize the method (GET), but simply does not support a = representation for the requested resource, which seems more inline with a <= b>404 [3].

What was the reasoning behind the 501? Given the requ= irement is a "SHOULD" recommendation, I'm inclined to return = the HTTP standard 404 in my service provider implementation, instead of the= SCIM recommended 501.

PATCH Operation Support

The SCIM 1.1 and 2.0 specifications also imply that 501 sho= uld be returned when PATCH is not supported [4]. This also seems to violate= the HTTP spec, if the server recognizes the PATCH method, but simply does = not support this method for the requested resource. Instead, a 405= =20 (Method Not Allowed)=20 [5] seems more appropriate.

[1] https://tools.ietf.org/html/rfc76= 44#section-3.11
[2] https://tools.ietf.org/html/rfc7231#section-6.6.2
[3] https://= tools.ietf.org/html/rfc7231#section-6.5.4
--00000000000079b864059f6c1138-- From nobody Tue Feb 25 12:27:39 2020 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 DBAF23A1539 for ; Tue, 25 Feb 2020 12:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=independentid-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtiZDhyrXiov for ; Tue, 25 Feb 2020 12:27:36 -0800 (PST) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 44CCB3A1536 for ; Tue, 25 Feb 2020 12:27:36 -0800 (PST) Received: by mail-pl1-x62d.google.com with SMTP id y1so272432plp.7 for ; Tue, 25 Feb 2020 12:27:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=/yWtHqc/evCQVW2c8JBRyUr3cYaqP8ezCfJHK8LWfWk=; b=mQ8O/soSQtjhNENUhI5K56HdzsFGyGuvpV7/difPCTZLcrjTcSYTK0BYRWfx0nClxY Mwbmn9VthU2soa4mKluau0zW3t13qBFhr5bh6Ravalwtx8rZ30pWed5apS3A2UnYU5dQ i4Ov8PrGBNxvjkTQ6IFCk5Q2F5S3AhzKODbaxP4KODyZBQEsefD2DwB4kzIJXfWSkzF2 EuQDWn0fCGA6OMQZxH27pqbDQB4tSLycy461KpNaOBaBfbzgO3Y2oP7gU2mVoVOHszK8 6mXQUoYG3jwxWW1ZI72UE12R/0YePoTgua+TOgD00eIxPQ5gZIUCabhiPJPRlHXUfKrq 3zgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=/yWtHqc/evCQVW2c8JBRyUr3cYaqP8ezCfJHK8LWfWk=; b=jub1JTt27d2dJAcBWGr7Fq1FPAC29D/6jhKFtvw78LKC/eaz+jY9jWZRjp6LSHFJzk v2kTDeXCRQPLfWDs1ddoEfVvL498bJRhAHAKM+7JeLzLeGNp1+b818RVYLA5/PrRwsm+ etYAsjHk0J8ZJ0azh4LbeOkEAy9a4MGERk4PfgTZQW08TDPReEQNHS9iB1f7QfNq6os0 R/ZxjdqF9yvIKINFmdYKHKyxdj37N0NCu4HLT7KWpI0ksDsGxzT5lQvnT9UOrVzuNksN IAvj+ao4QxTLD1hdeuG2wl2n0c5iwtK8s6bwLKAVAk69ENK4YfsRw+tKavUx30iUL1Bh dhAw== X-Gm-Message-State: APjAAAUoUlQzuucc8DmquiI6ADq2igSnXVzz8/8cBixac2po94+SL0Ta Qwcn9QlevxKXGOkpeJ/2aMWEZ79tI/I= X-Google-Smtp-Source: APXvYqxdLZckB88Tjmdued4hZzOOjLT8l4mu6oTf7dH/pevExKb+Zp7RC5DTfmTCcJOKMRC2zk9c7w== X-Received: by 2002:a17:902:8a8e:: with SMTP id p14mr332307plo.28.1582662455385; Tue, 25 Feb 2020 12:27:35 -0800 (PST) Received: from ?IPv6:2605:8d80:444:2313:441a:e733:9b99:bb05? ([2605:8d80:444:2313:441a:e733:9b99:bb05]) by smtp.gmail.com with ESMTPSA id g19sm18207733pfh.134.2020.02.25.12.27.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 Feb 2020 12:27:34 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-A5D6366D-67FD-4F20-9868-9B62CF95D3E9 Content-Transfer-Encoding: 7bit From: Phillip Hunt Mime-Version: 1.0 (1.0) Date: Tue, 25 Feb 2020 12:27:24 -0800 Message-Id: References: Cc: scim@ietf.org In-Reply-To: To: Shelley X-Mailer: iPhone Mail (17C54) Archived-At: Subject: Re: [scim] HTTP Status Code 501 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 20:27:38 -0000 --Apple-Mail-A5D6366D-67FD-4F20-9868-9B62CF95D3E9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable There are two possibilities: - 501 the function of alias path mapping a security credential to a resource= is not available - 404 would make sense if the security credential used does not map to a sci= m resource in the server. Phil > On Feb 25, 2020, at 12:09 PM, Shelley wrote: >=20 > =EF=BB=BF > /Me Endpoint Support >=20 > The SCIM 2 specification indicates that if a service provider does not sup= port the "/Me" endpoint, it should respond with HTTP 501 [1]. >=20 > This doesn't seem inline with the HTTP specification, which indicates that= 501 is used when the server does not recognize the request method [2]. >=20 > In the case of the "/Me" endpoint, however, the server does recognize the m= ethod (GET), but simply does not support a representation for the requested r= esource, which seems more inline with a 404 [3]. >=20 > What was the reasoning behind the 501? Given the requirement is a "SHOULD"= recommendation, I'm inclined to return the HTTP standard 404 in my service p= rovider implementation, instead of the SCIM recommended 501. >=20 > PATCH Operation Support >=20 > The SCIM 1.1 and 2.0 specifications also imply that 501 should be returned= when PATCH is not supported [4]. This also seems to violate the HTTP spec, i= f the server recognizes the PATCH method, but simply does not support this m= ethod for the requested resource. Instead, a 405 (Method Not Allowed) [5] se= ems more appropriate. >=20 > [1] https://tools.ietf.org/html/rfc7644#section-3.11 > [2] https://tools.ietf.org/html/rfc7231#section-6.6.2 > [3] https://tools.ietf.org/html/rfc7231#section-6.5.4 > [4] https://tools.ietf.org/html/rfc7644#section-3.12 > [5] https://tools.ietf.org/html/rfc7231#section-6.5.5 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-A5D6366D-67FD-4F20-9868-9B62CF95D3E9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable There are two possibilities:
- 501 the f= unction of alias path mapping a security credential to a resource is not ava= ilable
- 404 would make sense if the security credential used does= not map to a scim resource in the server.

Phil

On Feb 25, 2020, at 12:09 PM= , Shelley <randomshelley@gmail.com> wrote:

<= blockquote type=3D"cite">
=EF=BB=BF
/M= e Endpoint Support

The SCIM 2 specification indicates that if= a service provider does not support the "/Me" endpoint, it should respond w= ith HTTP 501 [1].

This doesn't seem inline with the HTTP specificatio= n, which indicates that 501 is used when the server does not recognize th= e request method [2].

In the case of the "/Me" endpoint, h= owever, the server does recognize the method (GET), but simply= does not support a representation for the requested resource, which seems m= ore inline with a 404 [3].

What was the reasoning behind the 5= 01? Given the requirement is a "SHOULD" recommendation, I'm inclined to retu= rn the HTTP standard 404 in my service provider implementation, instead of t= he SCIM recommended 501.

PATCH Operation Support

The SCIM 1.1 and 2.0 specifications also imply that 501 sho= uld be returned when PATCH is not supported [4]. This also seems to violate t= he HTTP spec, if the server recognizes the PATCH method, but simply does not= support this method for the requested resource. Instead, a 405=20 (Method Not Allowed)=20 [5] seems more appropriate.

[1] https://tools.ietf.org/html/rfc7644= #section-3.11
[2] https://tools.ietf.org/html/rfc7231#section-6.6.2
=
_______________________________________________
scim m= ailing list
scim@ietf.org
https://www.ietf.o= rg/mailman/listinfo/scim
= --Apple-Mail-A5D6366D-67FD-4F20-9868-9B62CF95D3E9-- From nobody Wed Feb 26 09:31:03 2020 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 693673A0DF5 for ; Wed, 26 Feb 2020 09:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 vUraI6Nes1dj for ; Wed, 26 Feb 2020 09:31:00 -0800 (PST) Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (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 C5A403A0DFF for ; Wed, 26 Feb 2020 09:30:59 -0800 (PST) Received: by mail-vk1-xa35.google.com with SMTP id y201so790332vky.8 for ; Wed, 26 Feb 2020 09:30:59 -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=EiNQJLCmY7b84yHZ27MNjeVAdXhCtUfOrWftBbgTS5k=; b=AEZyhirpEU9JaT4sirVyWrXQi8gcqzkRRSRI3yAF39/27dypQm2nP4algj+87qZRZL ht0vSfClPmCGQOR0ANEyC7jj5h0Ls6AYoyEpBuM+kenZdq2z/Zs8UHLUyLASdvfb+w5o zK54hZ7i5QDpL0qxjq63oeqio64LG/uTCy2w5EoM4NVvQZHrG6SKZ8uQE/5popeTD4UQ +Y9z5Y/DiEbGeIQ/RtExA1B9uiTEW1rIb4CcNNfBwELYDkfV3JEPtte8FHIn2VblJeAK Sp52qjcaq6oRh9yknInn4pHSJodcDNpIeU2i6AjinbeBs4GEqx9xvy4HITFMe4lgbFzE rpGw== 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=EiNQJLCmY7b84yHZ27MNjeVAdXhCtUfOrWftBbgTS5k=; b=b5LorRieDgPsU1KU96djNZZwZrhz04ylGHPZH/c5EE1biODoTdnkLNpHSrsLjSlUTl +bizSaEq7nRqpZttmEjcWBrt57wJXhvgC02VUh33EP06RxNNziquNDcqsjTz87lGF3An RUxy09EYaw5Sq18DkmCau8HljRcD9ZG+lRyIONgardLTALox/58rfrlJkmqiBNv3bQC9 ylxE413rez/sRK4NAjrJN2sVhbw+DQgLoGl0IZ3WhiCTI/8SlOokm5K/rAiXPRMR8mBm SbCMSE/v0hktJpBFVgRaHxFgAA66vb+fu9wiVX+u8TCK0HrIY1DydBdfOjcj0ETiztHW EZ9g== X-Gm-Message-State: APjAAAXbhSxO7W9DVo/DmfI8cbF0A1J/caZkysmh3QOY6+HtKC3twnnJ Iis6+iCRko3HmL4AhAB/Qxz2XDbHAIKx5/N1M/CxJmMLoIQ= X-Google-Smtp-Source: APXvYqztNjjUd5IjC4wT99WISyOmPjJP6thN03eN3ZjMqy+nElu3yVk6KzBdxKblwLvIKleKBhnwECiXd/ngkzw+xlo= X-Received: by 2002:a05:6122:1066:: with SMTP id k6mr181592vko.68.1582738258413; Wed, 26 Feb 2020 09:30:58 -0800 (PST) MIME-Version: 1.0 From: Shelley Date: Wed, 26 Feb 2020 11:30:46 -0600 Message-ID: To: scim@ietf.org Content-Type: multipart/alternative; boundary="000000000000aa4bca059f7df7eb" Archived-At: Subject: [scim] /ServiceProviderConfig vs. /ServiceProviderConfigs X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 17:31:02 -0000 --000000000000aa4bca059f7df7eb Content-Type: text/plain; charset="UTF-8" I just wanted to get some confirmation regarding the service provider configuration endpoint in SCIM 2.0. My understanding from the RFCs [1] and some past discussions (e.g. [3]) is that the endpoint is intended to be* /ServiceProviderConfig *(singular) in SCIM 2.0, despite that it was */ServiceProviderConfigs* (plural) in SCIM 1.1. However, there are some *errata *that state the SCIM 2.0 RFC documents are incorrect and actually should use the plural form [3,4]. I'm assuming these are just erroneous errata? [1] https://tools.ietf.org/html/rfc7644#section-4 [2] https://mailarchive.ietf.org/arch/msg/scim/8DlmxC-2Ju-VqYCHZwXK2Z6O_90/ [3] https://www.rfc-editor.org/errata/eid4979 [4] https://www.rfc-editor.org/errata/eid4978 --000000000000aa4bca059f7df7eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I just wanted to get some confirmation regarding the servi= ce provider configuration endpoint in SCIM 2.0.

My understanding fro= m the RFCs [1] and some past discussions (e.g. [3]) is that the endpoint is= intended to be /ServiceProviderConfig (singular) in SCIM 2.0, despi= te that it was /ServiceProviderConfigs (plural) in SCIM 1.1.

= However, there are some errata that state the SCIM 2.0 RFC documents= are incorrect and actually should use the plural form [3,4]. I'm assum= ing these are just erroneous errata?

[1] https://tools.ietf.org/html/rfc7644#section-= 4
[2] https://mailarchive.ietf.org/arch/msg/scim/8DlmxC-2Ju= -VqYCHZwXK2Z6O_90/
[3] https://www.rfc-editor.org/errata/eid4979
[4] https://www.rfc-editor.org/errata/= eid4978
--000000000000aa4bca059f7df7eb-- From nobody Wed Feb 26 10:47:37 2020 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 442633A10E2 for ; Wed, 26 Feb 2020 10:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=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=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 0hGAjsfiUeaK for ; Wed, 26 Feb 2020 10:47:24 -0800 (PST) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 4D5113A10EB for ; Wed, 26 Feb 2020 10:47:24 -0800 (PST) Received: by mail-ua1-x92e.google.com with SMTP id p2so1353064uao.9 for ; Wed, 26 Feb 2020 10:47:24 -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=WfsmjI5xk7W3t3/MzsWTPK3TDcPV85uHv+XeV2D3Ifs=; b=rft7/Z6VDSaeyVhYBFNrAKounrizjURq5vXiGDUf8qkEcu9dvGl7EUKBqJ5tsysFkt kk3S2smp88XJXM0hhLvqPeb1qGilbPfotLuOiOPu9uTm7ubniD7WHFpnqrTyDlHIBlLa qPt6npHRpaxC3Eb1QlRuLfztu8McB18Iyo2UjelgOfXFtHXt5DcVcrqqr2U0Tap5VWp+ JRK/QWAdNsL76KCXVm0FU8slLL9uIdgdBof13EyIQgRdB5Xe85b1cOa0XizdZOyuqohh +0ReaNCPWZB8qAuATua55ekuBdbsl2gMuCmcz1WVgYDLU6rlSOu3zLFDlTWBnOsBVSU7 yLdQ== 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=WfsmjI5xk7W3t3/MzsWTPK3TDcPV85uHv+XeV2D3Ifs=; b=MY4qEFqsBIAmGfzeLKweSiOD/WCAevVYqF8en+B0wl/VrFL0MX632aMy/uKFCgNtcn N7UqQxIBHLUylRQyBkaQeeCK7/g6E39PeUgTNaTjeQ3EbVM+Wd9OohrJDQLoSlA3K6Nj sjjApkfSW2/K410+4ohglUPnG3yxZLQLDYyL7Bn5EHELFGAwMziefwnnoXhJzdByR/+s RgsXbjQAuJe/v/Ff6T4OxoGINlU9nMbNGsztZ0BBBcwZ0C83OL0L9FdxGzQgei3ZtbFv BpQYgyKUBft2OTgfk8z5hmeKy1EyV8B1LzDNkhY/L72ZlWvy0silUHKqih4FX1imlkxs 7Qng== X-Gm-Message-State: APjAAAUG/arrlgCK/20M352G+nL1gSW+DdodLvDRMwbkn3f1A3Ay0HqD PzACQ7zhTi+ob64XU8b01gVNdc8CVZzIEL98QaJ8j+0kElM= X-Google-Smtp-Source: APXvYqwNJmuBYd6DDS6m/CaLu6Mh2Dfk82BRACg+VZ9ncPsJeySL2VDAI8N3Wh8WNJZo4eX6J4KfUlPLiAHnZtoJV2E= X-Received: by 2002:ab0:74ce:: with SMTP id f14mr331842uaq.118.1582742838435; Wed, 26 Feb 2020 10:47:18 -0800 (PST) MIME-Version: 1.0 From: Shelley Date: Wed, 26 Feb 2020 12:47:07 -0600 Message-ID: To: scim@ietf.org Content-Type: multipart/alternative; boundary="000000000000a7e548059f7f08e9" Archived-At: Subject: [scim] Root Query & Search Requirements X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 18:47:36 -0000 --000000000000a7e548059f7f08e9 Content-Type: text/plain; charset="UTF-8" The server root is not defined as a supported endpoint [1] for querying (GET), yet the inline text for the Query Resources section [2] implies that it is a required endpoint responsible for returning all resource types: *> Queries MAY be performed against a SCIM resource object, a resource type > endpoint, or a SCIM server root.* > *> A query against a server root indicates that all resources within the > server SHALL be included, subject to filtering...* > *> When processing query operations using endpoints that include more than > one SCIM resource type (e.g., a query from the server root endpoint)...* > Similarly, searching (POST) [3] seems to assume that the search is attached to a valid SCIM endpoint, although the root is not clearly defined as such: * > The inclusion of "/.search" on the end of a valid SCIM endpoint...* > I found some old tickets/discussions [4,5,6] that proposed making these requirements more clear in the RFC text and service provider configuration, but that clarity doesn't appear to have made its way into the final RFCs. Can someone provide some clarity on whether the server root must be a supported SCIM endpoint responsible for returning all resources (subject to standard filtering) and/or if it must support the .search capability? Our SCIM implementation does not currently have any use cases that would benefit from querying/searching across resource types, any I would prefer to add any custom support there unless it becomes necessary (i.e. just return a basic 404 response for any requests to the server root as an unknown/unsupported resource). [1] https://tools.ietf.org/html/rfc7644#section-3.2 [2] https://tools.ietf.org/html/rfc7644#section-3.4.2 [3] https://tools.ietf.org/html/rfc7644#section-3.4.3 [4] https://trac.ietf.org/trac/scim/ticket/42 [5] https://mailarchive.ietf.org/arch/msg/scim/WOT40hJ9t5RB1vEnwGoePWW18dI/ [6] https://mailarchive.ietf.org/arch/msg/scim/MXu6yJ3TxYTm566hW99TGTpvoZg/ --000000000000a7e548059f7f08e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The server root is not defined as a suppor= ted endpoint [1] for querying (GET), yet the inline text for the Query Reso= urces section [2] implies that it is a required endpoint responsible for re= turning all resource types:

> Queries MAY be performed aga= inst a SCIM resource object, a resource type endpoint, or a SCIM server roo= t.

> A query against a server root indicates tha= t all resources within the server SHALL be included, subject to filtering..= .

> When processing query operations using endpoints that inclu= de more than one SCIM resource type (e.g., a query from the server root end= point)...

Similarly, sea= rching (POST) [3] seems to assume that the search is attached to a valid SC= IM endpoint, although the root is not clearly defined as such:

> The inclusion of "/.search" on the end of a valid SCIM en= dpoint...

I found some old tickets/discussions= [4,5,6] that proposed making these requirements more clear in the RFC text= and service provider configuration, but that clarity doesn't appear to= have made its way into the final RFCs.

Can someon= e provide some clarity on whether the server root must be a supported SCIM = endpoint responsible for returning all resources (subject to standard filte= ring) and/or if it must support the .search capability?

Our SCIM implementation does not currently have any use cases that wo= uld benefit from querying/searching across resource types, any I would pref= er to add any custom support there unless it becomes necessary (i.e. just r= eturn a basic 404 response for any requests to the server root as an unknow= n/unsupported resource).

--000000000000a7e548059f7f08e9-- From nobody Wed Feb 26 13:39:17 2020 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 F360E3A07E4; Wed, 26 Feb 2020 13:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 ObgSP_ahBOC1; Wed, 26 Feb 2020 13:39:09 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AF503A0848; Wed, 26 Feb 2020 13:39:09 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0C4A1F406F0; Wed, 26 Feb 2020 13:38:56 -0800 (PST) To: randomshelley@gmail.com, phil.hunt@yahoo.com, kelly.grizzle@sailpoint.com, erik.wahlstrom@nexusgroup.com, cmortimore@salesforce.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: barryleiba@computer.org, iesg@ietf.org, scim@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200226213856.0C4A1F406F0@rfc-editor.org> Date: Wed, 26 Feb 2020 13:38:56 -0800 (PST) Archived-At: Subject: [scim] [Errata Verified] RFC7643 (5991) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 21:39:16 -0000 The following errata report has been verified for RFC7643, "System for Cross-domain Identity Management: Core Schema". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5991 -------------------------------------- Status: Verified Type: Editorial Reported by: Shelley Baker Date Reported: 2020-02-26 Verified by: Barry Leiba (IESG) Section: 8.3 Original Text ------------- "addresses": [ { "streetAddress": "100 Universal City Plaza", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "USA", "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA", "type": "work", "primary": true }, { "streetAddress": "456 Hollywood Blvd", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "USA", "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA", "type": "home" } ], Corrected Text -------------- "addresses": [ { "streetAddress": "100 Universal City Plaza", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "US", "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA", "type": "work", "primary": true }, { "streetAddress": "456 Hollywood Blvd", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "US", "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA", "type": "home" } ], Notes ----- Section 4.1.2 requires the use of the ISO 3166-1 "alpha-2" code format for the "country" attribute; however, sections 8.2 and 8.3 incorrectly specify "USA" instead of "US" for the "country" attribute. -------------------------------------- RFC7643 (draft-ietf-scim-core-schema-22) -------------------------------------- Title : System for Cross-domain Identity Management: Core Schema Publication Date : September 2015 Author(s) : P. Hunt, Ed., K. Grizzle, E. Wahlstroem, C. Mortimore Category : PROPOSED STANDARD Source : System for Cross-domain Identity Management Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Wed Feb 26 13:40:34 2020 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 E3D6D3A07C4; Wed, 26 Feb 2020 13:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 v4t5k1-fGNiP; Wed, 26 Feb 2020 13:40:23 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C2F13A0496; Wed, 26 Feb 2020 13:40:23 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 236A6F406F0; Wed, 26 Feb 2020 13:40:10 -0800 (PST) To: randomshelley@gmail.com, phil.hunt@yahoo.com, kelly.grizzle@sailpoint.com, erik.wahlstrom@nexusgroup.com, cmortimore@salesforce.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: barryleiba@computer.org, iesg@ietf.org, scim@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200226214010.236A6F406F0@rfc-editor.org> Date: Wed, 26 Feb 2020 13:40:10 -0800 (PST) Archived-At: Subject: [scim] [Errata Verified] RFC7643 (5990) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 21:40:25 -0000 The following errata report has been verified for RFC7643, "System for Cross-domain Identity Management: Core Schema". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5990 -------------------------------------- Status: Verified Type: Editorial Reported by: Shelley Baker Date Reported: 2020-02-26 Verified by: Barry Leiba (IESG) Section: 8.2 Original Text ------------- "addresses": [ { "type": "work", "streetAddress": "100 Universal City Plaza", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "USA", "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA", "primary": true }, { "type": "home", "streetAddress": "456 Hollywood Blvd", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "USA", "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA" } ], Corrected Text -------------- "addresses": [ { "type": "work", "streetAddress": "100 Universal City Plaza", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "US", "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA", "primary": true }, { "type": "home", "streetAddress": "456 Hollywood Blvd", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "US", "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA" } ], Notes ----- Section 4.1.2 requires the use of the ISO 3166-1 "alpha-2" code format for the "country" attribute; however, sections 8.2 and 8.3 incorrectly specify "USA" instead of "US" for the "country" attribute. -------------------------------------- RFC7643 (draft-ietf-scim-core-schema-22) -------------------------------------- Title : System for Cross-domain Identity Management: Core Schema Publication Date : September 2015 Author(s) : P. Hunt, Ed., K. Grizzle, E. Wahlstroem, C. Mortimore Category : PROPOSED STANDARD Source : System for Cross-domain Identity Management Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Wed Feb 26 14:05:19 2020 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 553583A088C for ; Wed, 26 Feb 2020 14:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=independentid-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tK9wl2qiNkdD for ; Wed, 26 Feb 2020 14:05:08 -0800 (PST) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 6D6583A08C4 for ; Wed, 26 Feb 2020 14:05:08 -0800 (PST) Received: by mail-pl1-x62b.google.com with SMTP id g6so247436plp.6 for ; Wed, 26 Feb 2020 14:05:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=17hT/Et4+P8b2E1IDiBoKlSiiuYydoLjr34GPTXKitc=; b=gv5vEbvbag2v8YzA89Rp8441rz2yi/cOa++sAKjELFILYgla4jY0+m0XVXccMMy68f VixiZPewifNl97tF4K96HMHPosXJT3u9ASApFFGj8Zf1uL3DGFU/3zpEfugxcry7sb6I AqAHWtfffWKiKyk9x0/2WdmjTVfFTPWtJ+QtJnt8ddSBHSGWOZ4A8+EzepAAnT5kkqZe Jastj1HS4ewV8w8ndkkXmBR4Ua+Fu6qgcGMRRFbdeh0VbcEOAwmgJmwH6fhC2yr8O3k+ rAE1u4nUkIcnxTi2OWqFVLzQRumnB1JUDNcca0IaIuiDrrQoINK1xe9jZwyNBZWJccSK EipQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=17hT/Et4+P8b2E1IDiBoKlSiiuYydoLjr34GPTXKitc=; b=Eahb6F8/GyeNmlTm87p/lpweluI4HoIrstMGupLp9T6gP8BN9jatYzadFrBHW4mgTw mVZtMxSWMWB8tnaf2NeWsfR0EjQ7tZewvohb44jROvHtC7xQIRxSLkCBYf1k1aKlQGWe gz872pgE0N8bjggF57EtelvPEYXJbvHqIKGijfoaPGcqDZNKtSh9GFBPlcImWHvk5i8g Cye9CD5HZwPMTelTyRjZM5mCjKJH6E9x9duunww0q895W2uVwVb6UJsTdKK+1P2j4twi vdYVqCT3j9ceUJZs/CLAstdimUjrgCJa45+TvQ2V3lHx0fpNstmwN5dT4E5roilXLicd DRiQ== X-Gm-Message-State: APjAAAWe5RCV1h/++R/u/O+Wcm9mD+mG9bK48BTJoXAZMgRKemWALBIh gAcl/uUY0w5TYC67iaT58KuLKonXdK0= X-Google-Smtp-Source: APXvYqwIBh1PU7Vi9MTalqjmBMIHfyrFvmwnTyj2BFz4oQdM+3J4YLrygLuMAyahziNMzRvniaR57Q== X-Received: by 2002:a17:90a:a386:: with SMTP id x6mr133103pjp.108.1582754707345; Wed, 26 Feb 2020 14:05:07 -0800 (PST) Received: from ?IPv6:2605:8d80:441:4e54:3dda:693a:9c22:e79? ([2605:8d80:441:4e54:3dda:693a:9c22:e79]) by smtp.gmail.com with ESMTPSA id m16sm4043424pfh.60.2020.02.26.14.05.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Feb 2020 14:05:06 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-7EE7D9D8-C89B-47EB-A092-E7BEBEED5D84 Content-Transfer-Encoding: 7bit From: Phillip Hunt Mime-Version: 1.0 (1.0) Date: Wed, 26 Feb 2020 15:05:05 -0700 Message-Id: <24BBC17A-4013-4DF7-987F-C73C4AB52A46@independentid.com> References: Cc: scim@ietf.org In-Reply-To: To: Shelley X-Mailer: iPhone Mail (17C54) Archived-At: Subject: Re: [scim] /ServiceProviderConfig vs. /ServiceProviderConfigs X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 22:05:17 -0000 --Apple-Mail-7EE7D9D8-C89B-47EB-A092-E7BEBEED5D84 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I would have to check. But it is singular because it is not a container but a= resource.=20 Phil > On Feb 26, 2020, at 10:31 AM, Shelley wrote: >=20 > =EF=BB=BF > I just wanted to get some confirmation regarding the service provider conf= iguration endpoint in SCIM 2.0. >=20 > My understanding from the RFCs [1] and some past discussions (e.g. [3]) is= that the endpoint is intended to be /ServiceProviderConfig (singular) in SC= IM 2.0, despite that it was /ServiceProviderConfigs (plural) in SCIM 1.1. >=20 > However, there are some errata that state the SCIM 2.0 RFC documents are i= ncorrect and actually should use the plural form [3,4]. I'm assuming these a= re just erroneous errata? >=20 > [1] https://tools.ietf.org/html/rfc7644#section-4 > [2] https://mailarchive.ietf.org/arch/msg/scim/8DlmxC-2Ju-VqYCHZwXK2Z6O_90= / > [3] https://www.rfc-editor.org/errata/eid4979 > [4] https://www.rfc-editor.org/errata/eid4978 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-7EE7D9D8-C89B-47EB-A092-E7BEBEED5D84 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I would have to check. But it is singular b= ecause it is not a container but a resource. 

P= hil

On Feb 26, 2020, at 1= 0:31 AM, Shelley <randomshelley@gmail.com> wrote:

=
=EF=BB=BF
I= just wanted to get some confirmation regarding the service provider configu= ration endpoint in SCIM 2.0.

My understanding from the RFCs [1] and s= ome past discussions (e.g. [3]) is that the endpoint is intended to be /S= erviceProviderConfig (singular) in SCIM 2.0, despite that it was /Ser= viceProviderConfigs (plural) in SCIM 1.1.

However, there are some= errata that state the SCIM 2.0 RFC documents are incorrect and actua= lly should use the plural form [3,4]. I'm assuming these are just erroneous e= rrata?

[1] = https://tools.ietf.org/html/rfc7644#section-4
[2] https://mai= larchive.ietf.org/arch/msg/scim/8DlmxC-2Ju-VqYCHZwXK2Z6O_90/
[3] https://www.rfc-editor.org= /errata/eid4979
[4] https://www.rfc-editor.org/errata/eid4978
_______________________________________________
scim m= ailing list
scim@ietf.org
https://www.ietf.o= rg/mailman/listinfo/scim
= --Apple-Mail-7EE7D9D8-C89B-47EB-A092-E7BEBEED5D84-- From nobody Sat Feb 29 09:05:35 2020 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 4C83F3A0F19 for ; Sat, 29 Feb 2020 09:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=independentid-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaSxNdsV_S2M for ; Sat, 29 Feb 2020 09:05:32 -0800 (PST) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 E636C3A0F17 for ; Sat, 29 Feb 2020 09:05:31 -0800 (PST) Received: by mail-pj1-x1031.google.com with SMTP id i11so2540750pju.3 for ; Sat, 29 Feb 2020 09:05:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=qUi8j+FGiw5iwEdghUjupxE0axG9jQkBXTInPIf8v4g=; b=KDt6CCuVK8PlTVhiA8HF6mU+0IcU9J6maHeAYgIJNDXfpdWhFvAvnuEArKkSQLU3BT zfZfxJh6cs9VOWDG1udWRfgc5Tisv749Q/ZaR+B5t/DbyxouQHRFVLuY9ksEn+L8P6be q3XthyOmva77W/aDh0PdonoHTKuAyUKoicXHkoRpTFOblFeGn68X+5T8i3yz21OhPyJ1 Td8OeaOm8Sx2AY75qXFvTipd7+pPwqkOapMq/N+t0VWo48pPcE28HkaWaMi3PKIru9RT H50cy2RUQqZWC7IKVeaqk/ii+j80w4Oxlfq2N3tasWKu7nmAB0ZjVscGXoSHNuT77Rsq HhkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=qUi8j+FGiw5iwEdghUjupxE0axG9jQkBXTInPIf8v4g=; b=QEoLnGvd4BH2DmNMIaq7XwHIF3h4uaIniaelaWfbjXa47VQqCo5dq1ne9qBe7QtAsK yas16EulBWLMiMEBtm4wbr7Qy8T07au6hQrU2PaQ+qFUolhpSEdDS18GQSVX7BYP7iiD 7QV/qvKaYZN+afI6oM2NKN8DwHvr0B8t0hOx9iCAyIEbSeBXOqxylsjSt6Av2FbCG/Mu FJuPRMvEZGfBjaGzDSRnWWpld0vY0Kwb8cJrROMcUUpm0JiU7uPhy5/r/6FNPqP0vF/Y mSh6TNkbqn9F2pBaJ1XklPhOQ45JX4rjvwFTKi9vPR/gG33nXuDb2ttRoaDPSvluox2F pvBg== X-Gm-Message-State: APjAAAXiRkGg7fbZByLGTeEAGOE8I/qxnr19Oe+Jp+uQhpxgblbKKpmt wyfEMMdzEADFKQdz14IomudYbQ== X-Google-Smtp-Source: APXvYqxEoWYvN0JKcOiwGNhbk3GyXhugylt+Gwjv648+iFwfAy9KPCJqJjjxA9x0cK3yrCBeKwRYOA== X-Received: by 2002:a17:90a:da03:: with SMTP id e3mr11402422pjv.100.1582995930918; Sat, 29 Feb 2020 09:05:30 -0800 (PST) Received: from phil-mbp-dev.hitronhub.home (S01069050ca4597c3.ek.shawcable.net. [68.145.161.248]) by smtp.gmail.com with ESMTPSA id b18sm15564564pfd.63.2020.02.29.09.05.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Feb 2020 09:05:30 -0800 (PST) From: Phillip Hunt Message-Id: <12070853-9D12-4C07-A11D-29B67905BA0A@independentid.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_86557B97-E5A2-4852-97F7-B018AE141591" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sat, 29 Feb 2020 10:05:28 -0700 In-Reply-To: Cc: scim@ietf.org To: Shelley References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [scim] Root Query & Search Requirements X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 17:05:34 -0000 --Apple-Mail=_86557B97-E5A2-4852-97F7-B018AE141591 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Shelley, Section 3.4.2.1 of RFC7644 states that the server root is a valid search = endpoint.=20 The root is not and endpoint for the purpose of holding resources. It = only holds the resource type containers (which each define their own = endpoint) and which in turn contain resources=20 The use case for querying from the root came from implementers who were = using SCIM in a directory lookup style of functionality and performing = search while typing type of functionality. In these cases the scim = client does not know what type of resource the user wants and wants to = be able to return all resource types, or a specific set of types (like = Users and Groups). Phil Hunt @independentid phil.hunt@independentid.com > On Feb 26, 2020, at 11:47 AM, Shelley wrote: >=20 > The server root is not defined as a supported endpoint [1] for = querying (GET), yet the inline text for the Query Resources section [2] = implies that it is a required endpoint responsible for returning all = resource types: >=20 > > Queries MAY be performed against a SCIM resource object, a resource = type endpoint, or a SCIM server root. >=20 > > A query against a server root indicates that all resources within = the server SHALL be included, subject to filtering.... >=20 > > When processing query operations using endpoints that include more = than one SCIM resource type (e.g., a query from the server root = endpoint)... >=20 > Similarly, searching (POST) [3] seems to assume that the search is = attached to a valid SCIM endpoint, although the root is not clearly = defined as such: >=20 > > The inclusion of "/.search" on the end of a valid SCIM endpoint... >=20 > I found some old tickets/discussions [4,5,6] that proposed making = these requirements more clear in the RFC text and service provider = configuration, but that clarity doesn't appear to have made its way into = the final RFCs. >=20 > Can someone provide some clarity on whether the server root must be a = supported SCIM endpoint responsible for returning all resources (subject = to standard filtering) and/or if it must support the .search capability? >=20 > Our SCIM implementation does not currently have any use cases that = would benefit from querying/searching across resource types, any I would = prefer to add any custom support there unless it becomes necessary (i.e. = just return a basic 404 response for any requests to the server root as = an unknown/unsupported resource). >=20 > [1] https://tools.ietf.org/html/rfc7644#section-3.2 = > [2] https://tools.ietf.org/html/rfc7644#section-3.4.2 = > [3] https://tools.ietf.org/html/rfc7644#section-3.4.3 = > [4] https://trac.ietf.org/trac/scim/ticket/42 = > [5] = https://mailarchive.ietf.org/arch/msg/scim/WOT40hJ9t5RB1vEnwGoePWW18dI/ = > [6] = https://mailarchive.ietf.org/arch/msg/scim/MXu6yJ3TxYTm566hW99TGTpvoZg/ = _= ______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_86557B97-E5A2-4852-97F7-B018AE141591 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Shelley,

Section 3.4.2.1 of RFC7644 states that the server root is a = valid search endpoint. 

The root is not and endpoint for the = purpose of holding resources. It only holds the resource type containers = (which each define their own endpoint) and which in turn contain = resources 

The use case for querying from the root came from = implementers who were using SCIM in a directory lookup style of = functionality and performing search while typing type of functionality. = In these cases the scim client does not know what type of resource the = user wants and wants to be able to return all resource types, or a = specific set of types (like Users and Groups).

Phil Hunt
@independentid



On Feb 26, 2020, at 11:47 AM, Shelley <randomshelley@gmail.com> wrote:

The server root is not = defined as a supported endpoint [1] for querying (GET), yet the inline = text for the Query Resources section [2] implies that it is a required = endpoint responsible for returning all resource types:

> = Queries MAY be performed against a SCIM resource object, a resource type = endpoint, or a SCIM server root.

> A = query against a server root indicates that all resources within the = server SHALL be included, subject to = filtering....

> When processing query operations using endpoints that = include more than one SCIM resource type (e.g., a query from the server = root endpoint)...

Similarly, = searching (POST) [3] seems to assume that the search is attached to a = valid SCIM endpoint, although the root is not clearly defined as = such:

> The inclusion of "/.search" on the end of a valid = SCIM endpoint...

I = found some old tickets/discussions [4,5,6] that proposed making these = requirements more clear in the RFC text and service provider = configuration, but that clarity doesn't appear to have made its way into = the final RFCs.

Can someone provide some clarity on whether the server root = must be a supported SCIM endpoint responsible for returning all = resources (subject to standard filtering) and/or if it must support the = .search capability?

Our SCIM implementation does not currently have any use cases = that would benefit from querying/searching across resource types, any I = would prefer to add any custom support there unless it becomes necessary = (i.e. just return a basic 404 response for any requests to the server = root as an unknown/unsupported resource).

[1] https://tools.ietf.org/html/rfc7644#section-3.2
[2] https://tools.ietf.org/html/rfc7644#section-3.4.2
[3] https://tools.ietf.org/html/rfc7644#section-3.4.3
[4]=20 https://trac.ietf.org/trac/scim/ticket/42
[5]= https://mailarchive.ietf.org/arch/msg/scim/WOT40hJ9t5RB1vEnwGoe= PWW18dI/
[6] https://mailarchive.ietf.org/arch/msg/scim/MXu6yJ3TxYTm566hW99T= GTpvoZg/
_______________________________________________
scim = mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

= --Apple-Mail=_86557B97-E5A2-4852-97F7-B018AE141591-- From nobody Sat Feb 29 16:50:28 2020 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 7936A3A129B for ; Wed, 26 Feb 2020 11:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 2s77J48zOSeA for ; Wed, 26 Feb 2020 11:16:50 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E73D3A1289 for ; Wed, 26 Feb 2020 11:16:50 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id EAB5CF40710; Wed, 26 Feb 2020 11:16:36 -0800 (PST) To: phil.hunt@yahoo.com, kelly.grizzle@sailpoint.com, erik.wahlstrom@nexusgroup.com, cmortimore@salesforce.com, barryleiba@computer.org, aamelnikov@fastmail.fm, adam@nostrum.com, moransar@cisco.com, leifj@sunet.se X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: randomshelley@gmail.com, scim@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200226191636.EAB5CF40710@rfc-editor.org> Date: Wed, 26 Feb 2020 11:16:36 -0800 (PST) Archived-At: X-Mailman-Approved-At: Sat, 29 Feb 2020 16:50:27 -0800 Subject: [scim] [Technical Errata Reported] RFC7643 (5990) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 19:16:54 -0000 The following errata report has been submitted for RFC7643, "System for Cross-domain Identity Management: Core Schema". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5990 -------------------------------------- Type: Technical Reported by: Shelley Baker Section: 8.2 Original Text ------------- "addresses": [ { "type": "work", "streetAddress": "100 Universal City Plaza", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "USA", "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA", "primary": true }, { "type": "home", "streetAddress": "456 Hollywood Blvd", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "USA", "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA" } ], Corrected Text -------------- "addresses": [ { "type": "work", "streetAddress": "100 Universal City Plaza", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "US", "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA", "primary": true }, { "type": "home", "streetAddress": "456 Hollywood Blvd", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "US", "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA" } ], Notes ----- Section 4.1.2 requires the use of the ISO 3166-1 "alpha-2" code format for the "country" attribute; however, sections 8.2 and 8.3 incorrectly specify "USA" instead of "US" for the "country" attribute. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7643 (draft-ietf-scim-core-schema-22) -------------------------------------- Title : System for Cross-domain Identity Management: Core Schema Publication Date : September 2015 Author(s) : P. Hunt, Ed., K. Grizzle, E. Wahlstroem, C. Mortimore Category : PROPOSED STANDARD Source : System for Cross-domain Identity Management Area : Applications and Real-Time Stream : IETF Verifying Party : IESG