Re: [scim] Call for support on proposed SCIM/SINS (re)charter

Danny Mayer <mayer@pdmconsulting.net> Tue, 14 September 2021 17:48 UTC

Return-Path: <mayer@pdmconsulting.net>
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 044CC3A271A for <scim@ietfa.amsl.com>; Tue, 14 Sep 2021 10:48:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 QdF1YPnn3-kJ for <scim@ietfa.amsl.com>; Tue, 14 Sep 2021 10:48:36 -0700 (PDT)
Received: from chessie.everett.org (chessie.everett.org [IPv6:2001:470:1:205::234]) (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 5AE4C3A271C for <scim@ietf.org>; Tue, 14 Sep 2021 10:48:36 -0700 (PDT)
Received: from newusers-MBP.fios-router.home (pool-108-26-179-179.bstnma.fios.verizon.net [108.26.179.179]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 4H89nB1zSWzMNQG; Tue, 14 Sep 2021 17:48:30 +0000 (UTC)
To: Phillip Hunt <phil.hunt@independentid.com>
Cc: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>, scim@ietf.org, "Matt Peterson (mpeterso)" <Matt.Peterson=40oneidentity.com@dmarc.ietf.org>
References: <1f7befb0-8f13-2b67-7447-9b65f738f5c9@pdmconsulting.net> <AFA4C5C7-2F5A-413F-BF55-E6E6B7938075@independentid.com>
From: Danny Mayer <mayer@pdmconsulting.net>
Message-ID: <3b111a3c-1544-63e2-95f7-09276164db46@pdmconsulting.net>
Date: Tue, 14 Sep 2021 13:48:29 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <AFA4C5C7-2F5A-413F-BF55-E6E6B7938075@independentid.com>
Content-Type: multipart/alternative; boundary="------------1DCA15B9318710E0D9CD2729"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/Dvd34HftZJupiue-XjbIQjdXngA>
Subject: Re: [scim] Call for support on proposed SCIM/SINS (re)charter
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Simple Cloud Identity Management BOF <scim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scim>, <mailto:scim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/scim/>
List-Post: <mailto:scim@ietf.org>
List-Help: <mailto:scim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scim>, <mailto:scim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2021 17:48:44 -0000

Personally I'd find that an opportunity for abuse. Now you have the 
headache of how to manage those different scopes if you were to allow 
that. Can you provide a use case where that would be the right thing to do?

Danny

On 9/14/21 1:04 PM, Phillip Hunt wrote:
> The authz token contains scopes that enable access. Part of the policy 
> can be to allow unlimited or different limits to list responses.
>
> Nothing says results sets are limited to 1000. The spec just says 
> there may be limits.
>
> Phil
>
>> On Sep 14, 2021, at 8:53 AM, Danny Mayer <mayer@pdmconsulting.net> wrote:
>>
>> 
>>
>> I don't know what scenarios would require more than one ID for the 
>> scim protocol. You are not logging into the system, it's a REST 
>> service call, and only one system should be performing management on 
>> that system. What's the use case for more than one application making 
>> scim protocol calls?
>>
>> Danny
>>
>> On 9/13/21 8:22 PM, Phillip Hunt wrote:
>>>
>>> Ahem. Maybe just change the maximum results limit for privileged 
>>> clients that need it?
>>>
>>> Maybe this is a best practice item?
>>>
>>> Phil
>>>
>>>> On Sep 13, 2021, at 4:53 PM, Danny Mayer <mayer@pdmconsulting.net> 
>>>> wrote:
>>>>
>>>> 
>>>>
>>>> The experience I've had in doing pagination mostly (but not 
>>>> exclusively) involved HR systems which had a 1000 per response 
>>>> limit but were not related to usage of scim. However any API call 
>>>> that returns a list can be subject to a limit by the scim server, 
>>>> most likely in order to preserve resources and not to tax the memory.
>>>>
>>>> Danny
>>>>
>>>> On 9/13/21 5:45 PM, Matt Peterson (mpeterso) wrote:
>>>>>
>>>>> I agree.
>>>>>
>>>>> Pagination and Synchronization show up under the same bullet in 
>>>>> the charter, but, like you, I think of them as separate (possibly 
>>>>> related) topics.  I am interested in both topics.
>>>>>
>>>>> As proof, I’m hoping to get feedback from anyone that has 
>>>>> additional pagination use case besides the “use of pagination for 
>>>>> initial load of synchronized objects”:
>>>>>
>>>>>  1. Fetch all users and groups for the application side cache so
>>>>>     that the application can use this cache to quickly make
>>>>>     authorization decisions. ß Pagination
>>>>>  2. Incrementally keep the application-side cache of users and
>>>>>     groups up to date with changes being made on the SCIM server.
>>>>>     ß Synchronization
>>>>>
>>>>> One classic use case for pagination is to support pages of results 
>>>>> in a UI.   Like Google search results.   Is anyone doing this?
>>>>>
>>>>> We aren’t.  For UI to find/search SCIM objects, we use a more 
>>>>> modern  “Typeahead Find” pattern that is preferred by our users – 
>>>>> and it does not require pagination.
>>>>>
>>>>> Again… I don’t know all the use cases for pagination.  I’m sure 
>>>>> there are more out there that are very relevant.  Step one is 
>>>>> making a list of reasons people need pagination.
>>>>>
>>>>> *From:* Danny Mayer <mayer@pdmconsulting.net>
>>>>> *Sent:* Monday, September 13, 2021 2:27 PM
>>>>> *To:* Matt Peterson (mpeterso) <Matt.Peterson@oneidentity.com>; 
>>>>> Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com>; Phil Hunt 
>>>>> <phil.hunt@independentid.com>
>>>>> *Cc:* scim@ietf.org
>>>>> *Subject:* Re: [scim] Call for support on proposed SCIM/SINS 
>>>>> (re)charter
>>>>>
>>>>> *CAUTION:*This email originated from outside of the organization. 
>>>>> Do not follow guidance, click links, or open attachments unless 
>>>>> you recognize the sender and know the content is safe.
>>>>>
>>>>> Matt,
>>>>>
>>>>> Synchronization and paging are different issues and should be 
>>>>> handled separately. You may need paging for synchronization but 
>>>>> that may not be the only case. I don't personally know of other 
>>>>> cases but I would like to hear other people's experience of this 
>>>>> so that the requirements be properly included in the draft RFCs.
>>>>>
>>>>> Danny
>>>>>
>>>>> On 9/13/21 11:02 AM, Matt Peterson (mpeterso) wrote:
>>>>>
>>>>>     Danny,
>>>>>
>>>>>     One of the goals of the workgroup is to understand what the
>>>>>     pagination use cases are (besides initial loading of object
>>>>>     set to be synchronized).
>>>>>
>>>>>     I’m eager to start keeping track of pagination use cases.  Can
>>>>>     you posting to the list the use cases that you are thinking of
>>>>>     you’d need pagination for?   Thanks!
>>>>>
>>>>>     *From:* scim <scim-bounces@ietf.org>
>>>>>     <mailto:scim-bounces@ietf.org> *On Behalf Of *Danny Mayer
>>>>>     *Sent:* Friday, September 10, 2021 6:11 PM
>>>>>     *To:* Nancy Cam-Winget (ncamwing)
>>>>>     <ncamwing=40cisco.com@dmarc.ietf.org>
>>>>>     <mailto:ncamwing=40cisco.com@dmarc.ietf.org>; Phil Hunt
>>>>>     <phil.hunt@independentid.com> <mailto:phil.hunt@independentid.com>
>>>>>     *Cc:* scim@ietf.org <mailto:scim@ietf.org>
>>>>>     *Subject:* Re: [scim] Call for support on proposed SCIM/SINS
>>>>>     (re)charter
>>>>>
>>>>>     *CAUTION:*This email originated from outside of the
>>>>>     organization. Do not follow guidance, click links, or open
>>>>>     attachments unless you recognize the sender and know the
>>>>>     content is safe.
>>>>>
>>>>>     Pagination and synchronization are really different issues.
>>>>>     Synchronization MAY need pagination but not necessarily. There
>>>>>     are other reasons why pagination may be necessary.
>>>>>
>>>>>     Danny
>>>>>
>>>>>     On 9/10/21 8:00 PM, Nancy Cam-Winget (ncamwing) wrote:
>>>>>
>>>>>         Thanks for the feedback Phil.  I’m trying to determine
>>>>>         proposed changes to the charter text…..I suspect there
>>>>>         might have been a translation issue for synchronization
>>>>>         being more about pagination than paging?
>>>>>
>>>>>         If you can provide suggested updates, it will be helpful
>>>>>         to rally agreement for the updates too.
>>>>>
>>>>>         Best, Nancy
>>>>>
>>>>>         *From: *Phil Hunt <phil.hunt@independentid.com>
>>>>>         <mailto:phil.hunt@independentid.com>
>>>>>         *Date: *Wednesday, September 8, 2021 at 6:34 PM
>>>>>         *To: *ncamwing <ncamwing@cisco.com>
>>>>>         <mailto:ncamwing@cisco.com>
>>>>>         *Cc: *"scim@ietf.org" <mailto:scim@ietf.org>
>>>>>         <scim@ietf.org> <mailto:scim@ietf.org>
>>>>>         *Subject: *Re: [scim] Call for support on proposed
>>>>>         SCIM/SINS (re)charter
>>>>>
>>>>>         Nancy,
>>>>>
>>>>>         Thanks for putting this together.
>>>>>
>>>>>         For this go around my interest lies mainly in Events and
>>>>>         Synchronization and profiles.  I am willing to provide
>>>>>         updated drafts for this process after some initial
>>>>>         agreement on cases.  Drafts already in the archive (they
>>>>>         may be fairly out of date!):
>>>>>
>>>>>         * SCIM Events - draft-hunt-idevent-scim
>>>>>         <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-hunt-idevent-scim&data=04%7C01%7CMatt.Peterson%40oneidentity.com%7Ca46f65d815bb4b0a23a808d976f4e531%7C91c369b51c9e439c989c1867ec606603%7C0%7C0%7C637671616475053385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WMiHg3saMHfMs1hpvfbpMlBtvpDlW6l5KxYI9s%2B1pYc%3D&reserved=0>
>>>>>         (needs to be updated to reflect the work we did in RFC8417)
>>>>>
>>>>>         * OpenId Connect Profile for SCIM -
>>>>>         https://openid.net/specs/openid-connect-scim-profile-1_0.html
>>>>>         <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-scim-profile-1_0.html&data=04%7C01%7CMatt.Peterson%40oneidentity.com%7Ca46f65d815bb4b0a23a808d976f4e531%7C91c369b51c9e439c989c1867ec606603%7C0%7C0%7C637671616475063383%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GO3%2By2rzIuUXWTn5uYVhRZlKrOLZs%2BJbsA6Ue%2BaAqpk%3D&reserved=0>
>>>>>
>>>>>         Regarding the MV-Paging draft.  This draft has nothing to
>>>>>         do with synchronization and is intended for clients who
>>>>>         need to pull a limited number of values in a
>>>>>         multi-valued-attribute in situations such as large groups.
>>>>>         Most typical use would be in building a user interface
>>>>>         allowing the searching of MVAs.
>>>>>
>>>>>         As far as exploring using paging as a synchronization
>>>>>         approach is not something we should explore (ie in the
>>>>>         charter). IMHO this appraoch an anti-pattern.  If its
>>>>>         needed, I am happy to add text in the best practices or
>>>>>         elsewhere as to why this isn’t a great approach from the
>>>>>         perspective of security, DoS, timeliness, scale, and cost.
>>>>>
>>>>>         That said, a couple people indicated they wanted stateful
>>>>>         paging. Unfortunately they didn’t elaborate on a use case.
>>>>>
>>>>>         Phil Hunt
>>>>>
>>>>>         @independentid
>>>>>
>>>>>         phil.hunt@independentid.com
>>>>>         <mailto:phil.hunt@independentid.com>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>             On Sep 8, 2021, at 5:21 PM, Nancy Cam-Winget
>>>>>             (ncamwing) <ncamwing=40cisco.com@dmarc.ietf.org
>>>>>             <mailto:ncamwing=40cisco.com@dmarc.ietf.org>> wrote:
>>>>>
>>>>>             Hello SCIM participants,
>>>>>
>>>>>             After some virtual meetings (thank you Pam for hosting
>>>>>             these!) and discussion, there is a new proposed
>>>>>             charter that addresses the points raised at the IETF
>>>>>             111 SINS session.
>>>>>
>>>>>             This is a call for support of the charter defined
>>>>>             below, please provide your response by Sept. 24, 2021.
>>>>>
>>>>>             As you respond in support for the charter, please also
>>>>>             specify if you are willing to produce, review and/or
>>>>>             implement the resulting documents.
>>>>>
>>>>>             Otherwise, do provide feedback in the time window if
>>>>>             there are concerns or issues you see with the charter
>>>>>             below:
>>>>>
>>>>>
>>>>>               Charter
>>>>>
>>>>>             The System for Cross-domain Identity Management (SCIM)
>>>>>             specification is an HTTP-based protocol that makes
>>>>>             managing identities in multi-domain scenarios easier.
>>>>>             SCIM was last published in 2015 and has seen growing
>>>>>             adoption.
>>>>>
>>>>>             One goal for this working group is to shepherd SCIM,
>>>>>             currently RFC series 7642
>>>>>             <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7642&data=04%7C01%7CMatt.Peterson%40oneidentity.com%7Ca46f65d815bb4b0a23a808d976f4e531%7C91c369b51c9e439c989c1867ec606603%7C0%7C0%7C637671616475073378%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oLizxx9sLS7M7VO9g9q58VMEg2MmQAOfr1vVW%2FeEB3M%3D&reserved=0>,
>>>>>             7643
>>>>>             <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7643&data=04%7C01%7CMatt.Peterson%40oneidentity.com%7Ca46f65d815bb4b0a23a808d976f4e531%7C91c369b51c9e439c989c1867ec606603%7C0%7C0%7C637671616475073378%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=PMP0OLBA%2FeTnUBvPQ98nPc%2BLtcLt0g6eDfaPmUs6J%2Fs%3D&reserved=0>,
>>>>>             7644
>>>>>             <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7644&data=04%7C01%7CMatt.Peterson%40oneidentity.com%7Ca46f65d815bb4b0a23a808d976f4e531%7C91c369b51c9e439c989c1867ec606603%7C0%7C0%7C637671616475083370%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4TzG7KMTWS2xR%2F90Dg7am9d3uux2AEsljnKxi6MXIlA%3D&reserved=0>,
>>>>>             through the Internet Standard process. The group will
>>>>>             deliver revised specifications for the SCIM
>>>>>             requirements as Informational, and for the SCIM
>>>>>             protocol and base schema suitable for consideration as
>>>>>             a Standard. This work will be based upon the existing
>>>>>             RFCs, errata and interoperabilty feedback, and
>>>>>             incorporate current security and privacy best practices.
>>>>>
>>>>>             In addition to revising the requirements, protocol and
>>>>>             base schema RFCs, the group will also consider
>>>>>             additional specifications as extensions to SCIM that
>>>>>             have found broad adoption and are ready for standards
>>>>>             track. This includes profiles and schemas for
>>>>>             interoperability in additional scenarios. The working
>>>>>             group will develop additional Proposed Standard RFCs
>>>>>             based on outcomes of the following work:
>>>>>
>>>>>              1. Revision of the informational RFC 7642 will:
>>>>>
>>>>>                  1. Focus on Use cases and implementation patterns
>>>>>
>>>>>                      1. Pull vs. Push based use cases
>>>>>                      2. Events and signals use cases
>>>>>                      3. Deletion use cases
>>>>>
>>>>>                  2. New use cases may be added to the revised RFC
>>>>>
>>>>>              2. Revision of RFC 7643/44 will include:
>>>>>
>>>>>                  1. Profiling SCIM relationships with other
>>>>>                     identity-centric protocols such as OAuth 2.0,
>>>>>                     OpenID Connect, Shared Signals, and Fastfed
>>>>>                  2. Updates to the evolution of the externalid usage
>>>>>
>>>>>              3. Document SCIM support for synchronization-related
>>>>>                 goals between domains focused on:
>>>>>
>>>>>                  1. Handling returning large result sets through
>>>>>                     paging, based on [draft-hunt-scim-mv-paging-00]
>>>>>                  2. Incremental approaches to synchronization
>>>>>
>>>>>              4. Support for deletion-related goals including:
>>>>>
>>>>>                  1. Handling Deletes in SCIM Servers that don’t
>>>>>                     allow Deletes (Soft Deletes) - based on
>>>>>                     [draft-ansari-scim-soft-delete-00]
>>>>>
>>>>>              5. Support for advanced automation scenarios such as:
>>>>>
>>>>>                  1. Discovery and negotiation of client credentials
>>>>>                  2. Attribute mapping
>>>>>                  3. Per-attribute schema negotiation
>>>>>
>>>>>              6. Enhance the existing schema to support exchanging
>>>>>                 of HR, Enterprise group and privileged access
>>>>>                 management (using draft-grizzle-scim-pam
>>>>>                 <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fid%2Fdraft-grizzle-scim-pam-ext-00.html&data=04%7C01%7CMatt.Peterson%40oneidentity.com%7Ca46f65d815bb4b0a23a808d976f4e531%7C91c369b51c9e439c989c1867ec606603%7C0%7C0%7C637671616475093372%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=woNtUiY5QKELNZayuM2Qw7gAgl0Pbf7cZ4bSsHOSMPs%3D&reserved=0> as
>>>>>                 a base)
>>>>>
>>>>>             Best, Nancy (as one of the BoF chairs)
>>>>>
>>>>>             _______________________________________________
>>>>>             scim mailing list
>>>>>             scim@ietf.org <mailto:scim@ietf.org>
>>>>>             https://www.ietf.org/mailman/listinfo/scim
>>>>>             <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscim&data=04%7C01%7CMatt.Peterson%40oneidentity.com%7Ca46f65d815bb4b0a23a808d976f4e531%7C91c369b51c9e439c989c1867ec606603%7C0%7C0%7C637671616475093372%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=o3ErZ8qFl5rkAgQ13peqw%2B0JUzY1iBl35HHR1YddOvY%3D&reserved=0>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>         _______________________________________________
>>>>>
>>>>>         scim mailing list
>>>>>
>>>>>         scim@ietf.org  <mailto:scim@ietf.org>
>>>>>
>>>>>         https://www.ietf.org/mailman/listinfo/scim  <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscim&data=04%7C01%7CMatt.Peterson%40oneidentity.com%7Ca46f65d815bb4b0a23a808d976f4e531%7C91c369b51c9e439c989c1867ec606603%7C0%7C0%7C637671616475103368%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XuV7MLYaKK1AXeqtGtFLr00wTjEAC567%2FccPBZ%2FzyjI%3D&reserved=0>
>>>>>
>>>>>
>>>>>
>>>>>     _______________________________________________
>>>>>
>>>>>     scim mailing list
>>>>>
>>>>>     scim@ietf.org  <mailto:scim@ietf.org>
>>>>>
>>>>>     https://www.ietf.org/mailman/listinfo/scim  <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscim&data=04%7C01%7CMatt.Peterson%40oneidentity.com%7Ca46f65d815bb4b0a23a808d976f4e531%7C91c369b51c9e439c989c1867ec606603%7C0%7C0%7C637671616475113358%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2vduvTBDkOfiiupZkQ%2B3Kn%2BrKJM5EZZhycEn5dJX4uM%3D&reserved=0>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> scim mailing list
>>>>> scim@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/scim
>>>
>>> _______________________________________________
>>> scim mailing list
>>> scim@ietf.org
>>> https://www.ietf.org/mailman/listinfo/scim