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

[Danny Mayer <[e-mail]>]

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]>
> *Date: *Wednesday, September 8, 2021 at 6:34 PM
> *To: *ncamwing <[e-mail]>
> *Cc: *"[e-mail]" <[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://tools.ietf.org/html/draft-hunt-idevent-scim>  (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://openid.net/specs/openid-connect-scim-profile-1_0.html>
>
> 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://datatracker.ietf.org/doc/html/rfc7642>, 7643
>     <https://datatracker.ietf.org/doc/html/rfc7643>, 7644
>     <https://datatracker.ietf.org/doc/html/rfc7644>, 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:
>
>       * Revision of the informational RFC 7642 will:
>
>           o Focus on Use cases and implementation patterns
>
>               + Pull vs. Push based use cases
>               + Events and signals use cases
>               + Deletion use cases
>
>           o New use cases may be added to the revised RFC
>
>       * Revision of RFC 7643/44 will include:
>
>           o Profiling SCIM relationships with other identity-centric
>             protocols such as OAuth 2.0, OpenID Connect, Shared
>             Signals, and Fastfed
>           o Updates to the evolution of the externalid usage
>
>       * Document SCIM support for synchronization-related goals
>         between domains focused on:
>
>           o Handling returning large result sets through paging, based
>             on [draft-hunt-scim-mv-paging-00]
>           o Incremental approaches to synchronization
>
>       * Support for deletion-related goals including:
>
>           o Handling Deletes in SCIM Servers that don’t allow Deletes
>             (Soft Deletes) - based on [draft-ansari-scim-soft-delete-00]
>
>       * Support for advanced automation scenarios such as:
>
>           o Discovery and negotiation of client credentials
>           o Attribute mapping
>           o Per-attribute schema negotiation
>
>       * Enhance the existing schema to support exchanging of HR,
>         Enterprise group and privileged access management (using
>         draft-grizzle-scim-pam
>         <https://tools.ietf.org/id/draft-grizzle-scim-pam-ext-00.html> 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://www.ietf.org/mailman/listinfo/scim>
>
>
> _______________________________________________
> scim mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/scim