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
- [scim] Call for support on proposed SCIM/SINS (re… Nancy Cam-Winget (ncamwing)
- Re: [scim] Call for support on proposed SCIM/SINS… Phil Hunt
- Re: [scim] Call for support on proposed SCIM/SINS… Danny Mayer
- Re: [scim] Call for support on proposed SCIM/SINS… Danny Mayer
- Re: [scim] Call for support on proposed SCIM/SINS… Mark Wahl
- Re: [scim] Call for support on proposed SCIM/SINS… Mike Kiser
- Re: [scim] Call for support on proposed SCIM/SINS… Erik Gustavson
- Re: [scim] [⚠️] Call for support on proposed SCIM… Alice Wang
- Re: [scim] Call for support on proposed SCIM/SINS… Matt Peterson (mpeterso)
- Re: [scim] Call for support on proposed SCIM/SINS… Nancy Cam-Winget (ncamwing)
- Re: [scim] Call for support on proposed SCIM/SINS… Danny Mayer
- Re: [scim] Call for support on proposed SCIM/SINS… Matt Peterson (mpeterso)
- Re: [scim] Call for support on proposed SCIM/SINS… Danny Mayer
- Re: [scim] Call for support on proposed SCIM/SINS… Craig McClanahan
- Re: [scim] Call for support on proposed SCIM/SINS… Matt Peterson (mpeterso)
- Re: [scim] Call for support on proposed SCIM/SINS… Paul Lanzi
- Re: [scim] Call for support on proposed SCIM/SINS… Danny Mayer
- Re: [scim] Call for support on proposed SCIM/SINS… Phillip Hunt
- Re: [scim] Call for support on proposed SCIM/SINS… Danny Mayer
- Re: [scim] Call for support on proposed SCIM/SINS… Phillip Hunt
- Re: [scim] Call for support on proposed SCIM/SINS… Danny Mayer
- Re: [scim] Call for support on proposed SCIM/SINS… Ryan Bradley
- Re: [scim] Call for support on proposed SCIM/SINS… Roman Danyliw