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

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Thu, 9 Sep 2021 00:21:56 +0000

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:
     *   Focus on Use cases and implementation patterns
        *   Pull vs. Push based use cases
        *   Events and signals use cases
        *   Deletion use cases
     *   New use cases may be added to the revised RFC
  *   Revision of RFC 7643/44 will include:
     *   Profiling SCIM relationships with other identity-centric protocols such as OAuth 2.0, OpenID Connect, Shared Signals, and Fastfed
     *   Updates to the evolution of the externalid usage
  *   Document SCIM support for synchronization-related goals between domains focused on:
     *   Handling returning large result sets through paging, based on [draft-hunt-scim-mv-paging-00]
     *   Incremental approaches to synchronization
  *   Support for deletion-related goals including:
     *   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:
     *   Discovery and negotiation of client credentials
     *   Attribute mapping
     *   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)

---

From: Phil Hunt <[email-masked]>
Date: Wed, 8 Sep 2021 18:33:58 -0700

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

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
[email-masked]

> On Sep 8, 2021, at 5:21 PM, Nancy Cam-Winget (ncamwing) <ncamwing=[email-masked]> wrote:
> 
> Hello SCIM participants,
>  
> 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.
> 
> Revision of the informational RFC 7642 will:
> Focus on Use cases and implementation patterns
> Pull vs. Push based use cases
> Events and signals use cases
> Deletion use cases
> New use cases may be added to the revised RFC
> Revision of RFC 7643/44 will include:
> Profiling SCIM relationships with other identity-centric protocols such as OAuth 2.0, OpenID Connect, Shared Signals, and Fastfed
> Updates to the evolution of the externalid usage
> Document SCIM support for synchronization-related goals between domains focused on:
> Handling returning large result sets through paging, based on [draft-hunt-scim-mv-paging-00]
> Incremental approaches to synchronization
> Support for deletion-related goals including:
> 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:
> Discovery and negotiation of client credentials
> Attribute mapping
> 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)
>  
> _______________________________________________
> scim mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/scim <https://www.ietf.org/mailman/listinfo/scim>

---

From: Danny Mayer <[email-masked]>
Date: Thu, 9 Sep 2021 10:18:46 -0400

I support this charter.  I will be happy to help produce and review 
documents and provide use cases. I can't do any implementations right 
now though I may be able to borrow Phil's sample implementation!

Danny

On 9/8/21 8:21 PM, Nancy Cam-Winget (ncamwing) 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.
>
> 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:
>
>       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
>       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
>       o Handling returning large result sets through paging, based on
>         [draft-hunt-scim-mv-paging-00]
>       o Incremental approaches to synchronization
>       o Handling Deletes in SCIM Servers that don’t allow Deletes
>         (Soft Deletes) - based on [draft-ansari-scim-soft-delete-00]
>       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)
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Danny Mayer <[email-masked]>
Date: Fri, 10 Sep 2021 13:17:04 -0400

Just to make it clear to everyone on this list, if you wish to move this 
charter forward to start/restart an actual working group it needs to be 
done here on the mailing list. Pam's bi-weekly meeting is not the place 
for it. This is an IETF requirement especially as not everyone can 
attend meetings. So far only Phil and I have responded on the mailing 
list to the proposed charter, so it's now up to everyone else to 
indicate their interest.

Thanks,

Danny

---

From: Mark Wahl <[email-masked]>
Date: Fri, 10 Sep 2021 19:59:21 +0000

I support this charter.  I am also willing to contribute to the revision of the SCIM core protocol and schema specifications to help progress them along the standards track.

Thanks, Mark

From: Nancy Cam-Winget (ncamwing) <[email-masked]>
Sent: Wednesday, September 8, 2021 5:22 PM
To: [email-masked]
Subject: [scim] Call for support on proposed SCIM/SINS (re)charter

Hello SCIM participants,

Charter

---

From: Mike Kiser <[email-masked]>
Date: Fri, 10 Sep 2021 20:07:36 +0000

Nancy -

 Excellent work.

  In favor of this charter, willing to work on revising for fastfed / shared events/signals, and HR / PAM extension (a la Grizzle).

  Looking forward to moving SCIM further down the line.

 -Mike
________________________________
From: scim <[email-masked]> on behalf of Nancy Cam-Winget (ncamwing) <ncamwing=[email-masked]>
Sent: Wednesday, September 8, 2021 19:21
To: [email-masked] <[email-masked]>
Subject: [scim] Call for support on proposed SCIM/SINS (re)charter

Hello SCIM participants,

Charter

One goal for this working group is to shepherd SCIM, currently RFC series 7642<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc7642__;!!MsNKLpFGsw!eTFh5jVfVk7j5EbQi8cR7GP4P6_P3P0XP4CHOXvPG1347jwVSVPPypLTkQ2tqHggOw$>, 7643<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc7643__;!!MsNKLpFGsw!eTFh5jVfVk7j5EbQi8cR7GP4P6_P3P0XP4CHOXvPG1347jwVSVPPypLTkQ2sdvxDOg$>, 7644<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc7644__;!!MsNKLpFGsw!eTFh5jVfVk7j5EbQi8cR7GP4P6_P3P0XP4CHOXvPG1347jwVSVPPypLTkQ09gz3ESg$>, 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.

  *   Enhance the existing schema to support exchanging of HR, Enterprise group and privileged access management (using draft-grizzle-scim-pam<https://urldefense.com/v3/__https://tools.ietf.org/id/draft-grizzle-scim-pam-ext-00.html__;!!MsNKLpFGsw!eTFh5jVfVk7j5EbQi8cR7GP4P6_P3P0XP4CHOXvPG1347jwVSVPPypLTkQ2pUlFhPA$> as a base)

---

From: Erik Gustavson <[email-masked]>
Date: Fri, 10 Sep 2021 13:53:52 -0700

I also support this charter and I'm willing to help produce and review the
resulting documents

On Fri, Sep 10, 2021 at 1:07 PM Mike Kiser <mike.kiser=
[email-masked]> wrote:

> Nancy -
>
>  Excellent work.
>
>   In favor of this charter, willing to work on revising for fastfed /
> shared events/signals, and HR / PAM extension (a la Grizzle).
>
> ------------------------------
> *From:* scim <[email-masked]> on behalf of Nancy Cam-Winget
> (ncamwing) <ncamwing=[email-masked]>
> *Sent:* Wednesday, September 8, 2021 19:21
> *To:* [email-masked] <[email-masked]>
> *Subject:* [scim] Call for support on proposed SCIM/SINS (re)charter
>
>
> Hello SCIM participants,
>
>
>
> As you respond in support for the charter, please also specify if you are
> willing to produce, review and/or implement the resulting documents.
>
> 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc7642__;!!MsNKLpFGsw!eTFh5jVfVk7j5EbQi8cR7GP4P6_P3P0XP4CHOXvPG1347jwVSVPPypLTkQ2tqHggOw$>
> , 7643
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc7643__;!!MsNKLpFGsw!eTFh5jVfVk7j5EbQi8cR7GP4P6_P3P0XP4CHOXvPG1347jwVSVPPypLTkQ2sdvxDOg$>
> , 7644
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc7644__;!!MsNKLpFGsw!eTFh5jVfVk7j5EbQi8cR7GP4P6_P3P0XP4CHOXvPG1347jwVSVPPypLTkQ09gz3ESg$>,
> 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:
>       - Focus on Use cases and implementation patterns
>          - Pull vs. Push based use cases
>          - Events and signals use cases
>          - Deletion use cases
>       - New use cases may be added to the revised RFC
>    - Revision of RFC 7643/44 will include:
>       - Profiling SCIM relationships with other identity-centric
>       protocols such as OAuth 2.0, OpenID Connect, Shared Signals, and Fastfed
>       - Updates to the evolution of the externalid usage
>    - Document SCIM support for synchronization-related goals between
>    domains focused on:
>       - Handling returning large result sets through paging, based on
>       - Incremental approaches to synchronization
>    - Support for deletion-related goals including:
>       - 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:
>       - Discovery and negotiation of client credentials
>       - Attribute mapping
>       - 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://urldefense.com/v3/__https://tools.ietf.org/id/draft-grizzle-scim-pam-ext-00.html__;!!MsNKLpFGsw!eTFh5jVfVk7j5EbQi8cR7GP4P6_P3P0XP4CHOXvPG1347jwVSVPPypLTkQ2pUlFhPA$> as
>    a base)
>
>
>

-- 

Erik Gustavson

[email-masked]

Engineering Manager - Google C&C Core

650-451-1372

---

From: Alice Wang <[email-masked]>
Date: Fri, 10 Sep 2021 14:13:15 -0700

I support this charter.  I could help to review the document and may also work on some sample implementation if needed.

Thanks

Alice

---

From: "Matt Peterson (mpeterso)" <[email-masked]>
Date: Fri, 10 Sep 2021 23:07:27 +0000

I support this charter.  I am willing to work on documentation and create implementations of:

  *   Handling returning large result sets through paging
  *   Incremental approaches to synchronization
  *   privileged access management

--
Matt Peterson
Distinguished Engineer
One Identity, Inc

From: scim <[email-masked]> On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Wednesday, September 8, 2021 6:22 PM
To: [email-masked]
Subject: [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.

Hello SCIM participants,

Charter

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%7C5f3af79e3d004ce0ad3608d97327df2d%7C91c369b51c9e439c989c1867ec606603%7C0%7C0%7C637667437369171715%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ou4b5qSLVSf3mHkeAmRL76dC%2BL90sdYvGf3ou0Cy6Vw%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%7C5f3af79e3d004ce0ad3608d97327df2d%7C91c369b51c9e439c989c1867ec606603%7C0%7C0%7C637667437369181710%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ojwWS82v2RTypt05%2F%2BHlpzNO%2Bdt2OA87hzTh3QicDns%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%7C5f3af79e3d004ce0ad3608d97327df2d%7C91c369b51c9e439c989c1867ec606603%7C0%7C0%7C637667437369191703%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TsHWM0nKei%2B%2B8GkekM9TSV6O%2FQqfGoaZ10Vd1z3dI0w%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.

     *   Handling Deletes in SCIM Servers that don't allow Deletes (Soft Deletes) - based on [draft-ansari-scim-soft-delete-00]

  *   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%7C5f3af79e3d004ce0ad3608d97327df2d%7C91c369b51c9e439c989c1867ec606603%7C0%7C0%7C637667437369191703%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KFBDe8DTPg4O7CRYYNTRsjVW4ZMFm5EjQXqSFZLL0z4%3D&reserved=0> as a base)

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Sat, 11 Sep 2021 00:00:34 +0000

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 <[email-masked]>
Date: Wednesday, September 8, 2021 at 6:34 PM
To: ncamwing <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [scim] Call for support on proposed SCIM/SINS (re)charter

Nancy,

* 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

Phil Hunt
@independentid
[email-masked]<mailto:[email-masked]>

On Sep 8, 2021, at 5:21 PM, Nancy Cam-Winget (ncamwing) <ncamwing=[email-masked]<mailto:ncamwing=[email-masked]>> wrote:

Hello SCIM participants,

Charter

_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scim

---

From: Danny Mayer <[email-masked]>
Date: Fri, 10 Sep 2021 20:10:32 -0400

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?
>
> *From: *Phil Hunt <[email-masked]>
> *Date: *Wednesday, September 8, 2021 at 6:34 PM
> *To: *ncamwing <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [scim] Call for support on proposed SCIM/SINS (re)charter
>
> Nancy,
>
> 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
>
> [email-masked] <mailto:[email-masked]>
>
>
>
>     On Sep 8, 2021, at 5:21 PM, Nancy Cam-Winget (ncamwing)
>     <ncamwing=[email-masked]
>     <mailto:ncamwing=[email-masked]>> wrote:
>
>     Hello SCIM participants,
>
>     discussion, there is a new proposed charter that addresses the
>     points raised at the IETF 111 SINS session.
>
>     As you respond in support for the charter, please also specify if
>     you are willing to produce, review and/or implement the resulting
>     documents.
>
>     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.
>
>     <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.
>
>     extensions to SCIM that have found broad adoption and are ready
>     for standards track. This includes profiles and schemas for
>           o Handling returning large result sets through paging, based
>             on [draft-hunt-scim-mv-paging-00]
>     <https://www.ietf.org/mailman/listinfo/scim>
>
>

---

From: "Matt Peterson (mpeterso)" <[email-masked]>
Date: Mon, 13 Sep 2021 15:02:28 +0000

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 <[email-masked]> On Behalf Of Danny Mayer
Sent: Friday, September 10, 2021 6:11 PM
To: Nancy Cam-Winget (ncamwing) <ncamwing=[email-masked]>; Phil Hunt <[email-masked]>
Cc: [email-masked]
Subject: Re: [scim] Call for support on proposed SCIM/SINS (re)charter

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?

Best, Nancy

From: Phil Hunt <[email-masked]><mailto:[email-masked]>
Date: Wednesday, September 8, 2021 at 6:34 PM
To: ncamwing <[email-masked]><mailto:[email-masked]>
Cc: "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: Re: [scim] Call for support on proposed SCIM/SINS (re)charter

Nancy,

* 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>

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

Hello SCIM participants,

Charter

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.

  1.  Revision of the informational RFC 7642 will:

  1.  Revision of RFC 7643/44 will include:

  1.  Document SCIM support for synchronization-related goals between domains focused on:

  1.  Support for deletion-related goals including:

  1.  Support for advanced automation scenarios such as:

  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)

_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
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

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>

---

From: Danny Mayer <[email-masked]>
Date: Mon, 13 Sep 2021 16:27:10 -0400

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 <[email-masked]> *On Behalf Of * Danny Mayer
> *Sent:* Friday, September 10, 2021 6:11 PM
> *To:* Nancy Cam-Winget (ncamwing) 
> <ncamwing=[email-masked]>; Phil Hunt 
> <[email-masked]>
> *Cc:* [email-masked]
> *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.
>
> Synchronization MAY need pagination but not necessarily. There are 
> other reasons why pagination may be necessary.
>
> Danny
>
>     translation issue for synchronization being more about pagination
>     than paging?
>
>     <mailto:[email-masked]>
>     *To: *ncamwing <[email-masked]> <mailto:[email-masked]>
>     *Cc: *"[email-masked]" <mailto:[email-masked]> <[email-masked]>
>     <mailto:[email-masked]>
>     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!):
>
>     <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)
>
>     <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>
>
>     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.
>
>         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.
>
>         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
>         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. 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,
>             <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)
>
>         <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>
>
>
>
>     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>
>
>

---

From: Craig McClanahan <[email-masked]>
Date: Mon, 13 Sep 2021 14:41:07 -0700

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 <[email-masked]> wrote:

> 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
> 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 <[email-masked]> <[email-masked]> *On Behalf
> Of * Danny Mayer
> *To:* Nancy Cam-Winget (ncamwing) <ncamwing=[email-masked]>
> <[email-masked]> <[email-masked]>
> *Cc:* [email-masked]
> *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.
>
>
>
> 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?
>
>
>
> *To: *ncamwing <[email-masked]> <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]> <[email-masked]> <[email-masked]>
> 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!):
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> On Sep 8, 2021, at 5:21 PM, Nancy Cam-Winget (ncamwing) <
> ncamwing=[email-masked]> wrote:
>
>
>
> Hello SCIM participants,
>
>
>
> <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
>    1. New use cases may be added to the revised RFC
>
>
>    1. Profiling SCIM relationships with other identity-centric protocols
>       such as OAuth 2.0, OpenID Connect, Shared Signals, and Fastfed
>    1. Handling returning large result sets through paging, based on
>    1. Handling Deletes in SCIM Servers that don’t allow Deletes (Soft
>    1. Enhance the existing schema to support exchanging of HR, Enterprise
> scim mailing [email-masked]://www.ietf.org/mailman/listinfo/scim
>

---

From: "Matt Peterson (mpeterso)" <[email-masked]>
Date: Mon, 13 Sep 2021 21:45:18 +0000

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 <[email-masked]>
Sent: Monday, September 13, 2021 2:27 PM
To: Matt Peterson (mpeterso) <[email-masked]>; Nancy Cam-Winget (ncamwing) <[email-masked]>; Phil Hunt <[email-masked]>
Cc: [email-masked]
Subject: Re: [scim] Call for support on proposed SCIM/SINS (re)charter

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

From: scim <[email-masked]><mailto:[email-masked]> On Behalf Of Danny Mayer
Sent: Friday, September 10, 2021 6:11 PM
To: Nancy Cam-Winget (ncamwing) <ncamwing=[email-masked]><mailto:ncamwing=[email-masked]>; Phil Hunt <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [scim] Call for support on proposed SCIM/SINS (re)charter

Danny

Best, Nancy

Nancy,

* 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>

Phil Hunt
@independentid

Hello SCIM participants,

Charter

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.

  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%7Ca46f65d815bb4b0a23a808d976f4e531%7C91c369b51c9e439c989c1867ec606603%7C0%7C0%7C637671616475093372%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=woNtUiY5QKELNZayuM2Qw7gAgl0Pbf7cZ4bSsHOSMPs%3D&reserved=0> as a base)

_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
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

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

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>

---

From: Paul Lanzi <[email-masked]>
Date: Mon, 13 Sep 2021 14:55:21 -0700

I want to add my voice of support to the proposed charter. As with Matt and
Mike, I'm happy to engage specifically on the PAM (aka Grizzle) extension
modification, incorporation, documentation and implementation. Happy to
contribute on other charter elements as well but PAM will be the area when
I can add the most expertise.

Thanks,

--Paul Lanzi
ᐧ

On Thu, Sep 9, 2021 at 7:19 AM Danny Mayer <[email-masked]> wrote:

> documents and provide use cases. I can't do any implementations right now
> though I may be able to borrow Phil's sample implementation!
>
> Danny
> 7642 <https://datatracker.ietf.org/doc/html/rfc7642>, 7643
> 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.
>
>    <https://tools.ietf.org/id/draft-grizzle-scim-pam-ext-00.html> as a
>    base)
>
>
>

---

From: Danny Mayer <[email-masked]>
Date: Mon, 13 Sep 2021 19:53:25 -0400

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 <[email-masked]>
> *Sent:* Monday, September 13, 2021 2:27 PM
> *To:* Matt Peterson (mpeterso) <[email-masked]>; Nancy 
> Cam-Winget (ncamwing) <[email-masked]>; Phil Hunt 
> 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
>
>     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).
>
>     posting to the list the use cases that you are thinking of you’d
>     need pagination for?   Thanks!
>
>     *From:* scim <[email-masked]>
>     <mailto:[email-masked]> *On Behalf Of *Danny Mayer
>     <ncamwing=[email-masked]>
>     <mailto:ncamwing=[email-masked]>; Phil Hunt
>     <[email-masked]> <mailto:[email-masked]>
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     *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.
>
>         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?
>
>         <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>
>         <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
>
>             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.
>
>             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
>
>             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
>             scenarios. The working group will develop additional
>             Proposed Standard RFCs based on outcomes of the following
>             work:
>
>                     identity-centric protocols such as OAuth 2.0,
>                     OpenID Connect, Shared Signals, and Fastfed
>              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]
>              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)
>
>             <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>
>
>
>
>
>         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>
>
>
>
>     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>
>
>

---

From: Phillip Hunt <[email-masked]>
Date: Mon, 13 Sep 2021 17:22:44 -0700

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 <[email-masked]> 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
> 
>> 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”:
>>  
>> Fetch all users and groups for the application side cache so that the application can use this cache to quickly make authorization decisions. ß Pagination
>> Incrementally keep the application-side cache of users and groups up to date with changes being made on the SCIM server.  ß Synchronization
>>  
>> 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.   
>>  
>>  
>> 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! 
>>  
>> * SCIM Events - draft-hunt-idevent-scim  (needs to be updated to reflect the work we did in RFC8417)
>> One goal for this working group is to shepherd SCIM, currently RFC series 7642, 7643, 7644, 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.
>> 
>> Enhance the existing schema to support exchanging of HR, Enterprise group and privileged access management (using draft-grizzle-scim-pam as a base)
>>

---

From: Danny Mayer <[email-masked]>
Date: Tue, 14 Sep 2021 11:53:06 -0400

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:
>> 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
>>
>>> charter, but, like you, I think of them as separate (possibly 
>>> related) topics.  I am interested in both topics.
>>>
>>> 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?
>>>
>>>  “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.
>>>
>>> *To:* Matt Peterson (mpeterso) <[email-masked]>; 
>>> Nancy Cam-Winget (ncamwing) <[email-masked]>; Phil Hunt 
>>> 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 
>>>     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!
>>>
>>>     *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.
>>>
>>>     Synchronization MAY need pagination but not necessarily. There
>>>     are other reasons why pagination may be necessary.
>>>
>>>     Danny
>>>
>>>         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!):
>>>
>>>         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
>>>             Otherwise, do provide feedback in the time window if
>>>             there are concerns or issues you see with the charter below:
>>>
>>>
>>>               Charter
>>>
>>>             managing identities in multi-domain scenarios easier.
>>>             SCIM was last published in 2015 and has seen growing
>>>             adoption.
>>>
>>>             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.
>>>
>>>             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. Handling Deletes in SCIM Servers that don’t
>>>                     allow Deletes (Soft Deletes) - based on
>>>                 HR, Enterprise group and privileged access
>>>                 management (using draft-grizzle-scim-pam

---

From: Phillip Hunt <[email-masked]>
Date: Tue, 14 Sep 2021 10:04:45 -0700

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 <[email-masked]> 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
>

---

From: Danny Mayer <[email-masked]>
Date: Tue, 14 Sep 2021 13:48:29 -0400

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.
>
>> 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
>>
>>>> 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
>>>>
>>>>> Pagination and Synchronization show up under the same bullet in 
>>>>> the charter, but, like you, I think of them as separate (possibly 
>>>>> 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”:
>>>>>
>>>>>     groups up to date with changes being made on the SCIM server.
>>>>>     ß Synchronization
>>>>>
>>>>> 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.
>>>>>
>>>>> there are more out there that are very relevant.  Step one is 
>>>>> making a list of reasons people need pagination.
>>>>>
>>>>> 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
>>>>>
>>>>>     pagination use cases are (besides initial loading of object
>>>>>     set to be synchronized).
>>>>>
>>>>>     attachments unless you recognize the sender and know the
>>>>>     content is safe.
>>>>>
>>>>>         proposed changes to the charter text…..I suspect there
>>>>>         might have been a translation issue for synchronization
>>>>>         being more about pagination than paging?
>>>>>
>>>>>         <mailto:[email-masked]>
>>>>>         *Cc: *"[email-masked]" <mailto:[email-masked]>
>>>>>         <[email-masked]> <mailto:[email-masked]>
>>>>>         updated drafts for this process after some initial
>>>>>         agreement on cases.  Drafts already in the archive (they
>>>>>         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
>>>>>             On Sep 8, 2021, at 5:21 PM, Nancy Cam-Winget
>>>>>             (ncamwing) <ncamwing=[email-masked]
>>>>>             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.
>>>>>
>>>>>             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
>>>>>              6. Enhance the existing schema to support exchanging
>>>>>                 of HR, Enterprise group and privileged access

---

From: Ryan Bradley <[email-masked]>
Date: Tue, 14 Sep 2021 21:19:42 -0700

I am also willing to contribute to revisions of drafts.

Regards,

Ryan Bradley

*he/him/his*

Senior Product Manager

617-852-2120

[email-masked]
 <https://www.okta.com/>

On Fri, Sep 10, 2021 at 12:59 PM Mark Wahl <Mark.Wahl=
[email-masked]> wrote:

> *This message originated outside your organization.*
>
> I support this charter.  I am also willing to contribute to the revision
> of the SCIM core protocol and schema specifications to help progress them
> along the standards track.
>
>
>
> Thanks, Mark
>
>
>
>
>
>
>
> *From:* Nancy Cam-Winget (ncamwing) <[email-masked]>
> *Sent:* Wednesday, September 8, 2021 5:22 PM
> *To:* [email-masked]
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc7642__;!!PwKahg!qQ7xfwq0qJWYcBC7Jr4yT5dcGXyAsrXMWJZRw72Iu5gRbsdGJKcYQvTdELMOscf5$>
> , 7643
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc7643__;!!PwKahg!qQ7xfwq0qJWYcBC7Jr4yT5dcGXyAsrXMWJZRw72Iu5gRbsdGJKcYQvTdEO3NcRKb$>
> , 7644
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc7644__;!!PwKahg!qQ7xfwq0qJWYcBC7Jr4yT5dcGXyAsrXMWJZRw72Iu5gRbsdGJKcYQvTdEJhGmqv8$>,
>    <https://urldefense.com/v3/__https://tools.ietf.org/id/draft-grizzle-scim-pam-ext-00.html__;!!PwKahg!qQ7xfwq0qJWYcBC7Jr4yT5dcGXyAsrXMWJZRw72Iu5gRbsdGJKcYQvTdEB5J92ff$> as
>    a base)
>
>
>