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

[Danny Mayer <[e-mail]>]

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 <[e-mail]>
> *Sent:* Monday, September 13, 2021 2:27 PM
> *To:* Matt Peterson (mpeterso) <[e-mail]>; Nancy 
> Cam-Winget (ncamwing) <[e-mail]>; Phil Hunt 
> <[e-mail]>
> *Cc:* [e-mail]
> *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 <[e-mail]>
>     <mailto:[e-mail]> *On Behalf Of *Danny Mayer
>     *Sent:* Friday, September 10, 2021 6:11 PM
>     *To:* Nancy Cam-Winget (ncamwing)
>     <ncamwing=[e-mail]>
>     <mailto:ncamwing=[e-mail]>; Phil Hunt
>     <[e-mail]> <mailto:[e-mail]>
>     *Cc:* [e-mail] <mailto:[e-mail]>
>     *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 <[e-mail]>
>         <mailto:[e-mail]>
>         *Date: *Wednesday, September 8, 2021 at 6:34 PM
>         *To: *ncamwing <[e-mail]> <mailto:[e-mail]>
>         *Cc: *"[e-mail]" <mailto:[e-mail]> <[e-mail]>
>         <mailto:[e-mail]>
>         *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
>
>         [e-mail] <mailto:[e-mail]>
>
>
>
>
>
>             On Sep 8, 2021, at 5:21 PM, Nancy Cam-Winget (ncamwing)
>             <ncamwing=[e-mail]
>             <mailto:ncamwing=[e-mail]>> 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
>             [e-mail] <mailto:[e-mail]>
>             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
>
>         [e-mail]  <mailto:[e-mail]>
>
>         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
>
>     [e-mail]  <mailto:[e-mail]>
>
>     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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/scim