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

Craig McClanahan <craigmcc@gmail.com> Mon, 13 September 2021 21:41 UTC

Return-Path: <craigmcc@gmail.com>
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189163A1135 for <scim@ietfa.amsl.com>; Mon, 13 Sep 2021 14:41:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, HTTPS_HTTP_MISMATCH=0.1, 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 rWYclhzV3dV5 for <scim@ietfa.amsl.com>; Mon, 13 Sep 2021 14:41:46 -0700 (PDT)
Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (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 085EE3A1137 for <scim@ietf.org>; Mon, 13 Sep 2021 14:41:45 -0700 (PDT)
Received: by mail-yb1-xb32.google.com with SMTP id c6so23483541ybm.10 for <scim@ietf.org>; Mon, 13 Sep 2021 14:41:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=erYULW3dgW2f4DGAtgjucf0KrMSZojytvGZarcqNjGk=; b=cmUcVjkREQjq8emkVGop++wcLMHvU+S11DA6Bv1MggPbxjSmH98qx2OoDAhh6PAoQA o/kheOURpT+0ZtxbiG+AfDu04HcIj4M693C2wej50/pMhvBMwHy1FWpv3ocdBnM+IbZO 2lg6E66OTBfWIVgdjLGRZBAjWpj0xGvASf7VCIXFR65wFmb9lz8Yr/F33K0DZMbaqakA UGAmnhcJ9/12fGnnrQ+a1zQxl9QRGrxzL1Vx6HCeRz8KLJxW7tu5lPKFpx+vZdnlsi6j rX156aPhjbHI2QDpqyBFfXbvdARDWDxhY1e/J58LyaVmvg1okb/vZBZ7r3dbRrj4wfBz hvAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=erYULW3dgW2f4DGAtgjucf0KrMSZojytvGZarcqNjGk=; b=Jrl2QHR/hYqZd1uBWf1j111at6z68Pc3UT+U8Hkiq66VJx8ERXlSrfvDJCvPEGLieY HNpwILDD0K/tHTIQteM/Qg4tXythNtDkLWo/6G0vLt2VBk2JPpCr50PAVUPjLFtHOKkV x8U9kR8hi33FabxkMFkGO9EsHdX6xkFOvdSAUZmBv1HEkxghp6xd0j4f17yB11lVFNfE eYwLnQxMm5J0IgPgtIlfFMjQsNxD1w7SBsPnzlm7iH/HfHQrU9yyVlKpAtZDxvvGWHtk dM4L49DILo1rgwrJEGdL0780SoFB8KP6znM/yZvdXObi0Mru4SjkMUKaBCl6DuaBzRjt FHqA==
X-Gm-Message-State: AOAM530ioa0Phc28p9jzbLrjqxwRYQFiJx4V6uCbr2TRCkJ7cedzPUSA fw3mp/tSLD9s64ut+sACBxBtCuxyGRM0S1/h7Ek=
X-Google-Smtp-Source: ABdhPJwPy9ySzft3sUNLKZNBDWXsufF48phejUcUQir/cRhREprnLjPeTH73zpRcvJD7jQaTlTIOQhw9PUe8u29w/hE=
X-Received: by 2002:a25:2c9:: with SMTP id 192mr18651855ybc.175.1631569303856; Mon, 13 Sep 2021 14:41:43 -0700 (PDT)
MIME-Version: 1.0
References: <9BCA478F-548E-4F6A-9F1B-6D8E15AE9373@cisco.com> <BBE3BC42-F3C5-4B89-A10F-0949D9876E62@independentid.com> <7B200805-50FD-4C77-8F92-E9877F6E70B5@cisco.com> <c131d8dc-8072-f0dc-9ed2-69cffcbae4c7@pdmconsulting.net> <MWHPR19MB0957B822C7CE28EF366EAFA7E1D99@MWHPR19MB0957.namprd19.prod.outlook.com> <2b1c1794-137f-6fd7-eb84-9d1715ef7413@pdmconsulting.net>
In-Reply-To: <2b1c1794-137f-6fd7-eb84-9d1715ef7413@pdmconsulting.net>
Reply-To: craigmcc@gmail.com
From: Craig McClanahan <craigmcc@gmail.com>
Date: Mon, 13 Sep 2021 14:41:07 -0700
Message-ID: <CANgkmLAwvvZT0Mx0ZnbPbchkdJFYsLk=a0esNQ37E1oB6HaqOQ@mail.gmail.com>
To: Danny Mayer <mayer@pdmconsulting.net>
Cc: "Matt Peterson (mpeterso)" <Matt.Peterson=40oneidentity.com@dmarc.ietf.org>, "Nancy Cam-Winget (ncamwing)" <ncamwing=40cisco.com@dmarc.ietf.org>, Phil Hunt <phil.hunt@independentid.com>, "scim@ietf.org" <scim@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c86a5005cbe754b7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/zM4pygJiIr6wgy9V0h0hcgzpkHY>
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: Mon, 13 Sep 2021 21:41:52 -0000

For a paging use case, imagine you are trying to list the followers (or the
n-th subset of them) in your UI for a very popular person on Twitter.
You'll definitely want paging for something like that.

FWIW, this was the breaking point for the last project I worked on that was
looking at using SCIM -- we were in exactly the same situation when groups
got too large.

Craig McClanahan

On Mon, Sep 13, 2021 at 1:27 PM Danny Mayer <mayer@pdmconsulting.net> wrote:

> 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> <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>
> <ncamwing=40cisco.com@dmarc.ietf.org>rg>; Phil Hunt
> <phil.hunt@independentid.com> <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.
>
>
>
> 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>
> <phil.hunt@independentid.com>
> *Date: *Wednesday, September 8, 2021 at 6:34 PM
> *To: *ncamwing <ncamwing@cisco.com> <ncamwing@cisco.com>
> *Cc: *"scim@ietf.org" <scim@ietf.org> <scim@ietf.org> <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%7Cf724206102d841ce536508d974b89ea7%7C91c369b51c9e439c989c1867ec606603%7C0%7C0%7C637669158559076639%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=aTbIFVma5fAKXT1IFSNi0VMxhpHgwPxbzLLP8Lyfleg%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%7Cf724206102d841ce536508d974b89ea7%7C91c369b51c9e439c989c1867ec606603%7C0%7C0%7C637669158559086635%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dpdcId61OuqI2BznbvQYF%2BCM1xr3mDhbNeLra8R%2FFYk%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
>
>
>
>
>
>
>
>
> On Sep 8, 2021, at 5:21 PM, Nancy Cam-Winget (ncamwing) <
> 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%7Cf724206102d841ce536508d974b89ea7%7C91c369b51c9e439c989c1867ec606603%7C0%7C0%7C637669158559086635%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oAINKBwQkQ7brNWd9N3RS1L7kclX1ES9%2BXzMXINnMzQ%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%7Cf724206102d841ce536508d974b89ea7%7C91c369b51c9e439c989c1867ec606603%7C0%7C0%7C637669158559096631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hA9V7rnyX9ueO9RCfWtIea3YUnvA1tXL8zFIbrWZPZ4%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%7Cf724206102d841ce536508d974b89ea7%7C91c369b51c9e439c989c1867ec606603%7C0%7C0%7C637669158559106629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=N129Lu9sJF8uld90ch7n5bznb%2BkT1pq9C5%2B6UBzIHUg%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
>
>
>    1. New use cases may be added to the revised RFC
>
>
>    1. 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
>
>
>    1. 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
>
>
>    1. 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]
>
>
>    1. Support for advanced automation scenarios such as:
>
>
>    1. Discovery and negotiation of client credentials
>       2. Attribute mapping
>       3. Per-attribute schema negotiation
>
>
>    1. 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%7Cf724206102d841ce536508d974b89ea7%7C91c369b51c9e439c989c1867ec606603%7C0%7C0%7C637669158559106629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=uP8dDJjH%2FI%2Bhy5AoAOt6imwhj8N7sdC7lUlbDml2DN0%3D&reserved=0> as
>    a base)
>
>
>
> Best, Nancy (as one of the BoF chairs)
>
>
>
> _______________________________________________
> scim mailing list
> 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%7Cf724206102d841ce536508d974b89ea7%7C91c369b51c9e439c989c1867ec606603%7C0%7C0%7C637669158559116621%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DpSg289QfIVbN1KOPrHy2UzcI0lPpXQ0dGR3NnPtXII%3D&reserved=0>
>
>
>
>
>
> _______________________________________________
>
> scim mailing list
>
> 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%7Cf724206102d841ce536508d974b89ea7%7C91c369b51c9e439c989c1867ec606603%7C0%7C0%7C637669158559126620%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BkQqK3IdyA2D7Y%2F4OtSTbjlgsBS3U8VPTt3aEJv8gs0%3D&reserved=0>
>
>
> _______________________________________________
> scim mailing listscim@ietf.orghttps://www.ietf.org/mailman/listinfo/scim
>
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim
>