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

[Phillip Hunt <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 
> I don't know what scenarios would require more than one ID for the scim protocol. You are not logging into the system, it's a REST service call, and only one system should be performing management on that system. What's the use case for more than one application making scim protocol calls?
> 
> Danny
> 
>> On 9/13/21 8:22 PM, Phillip Hunt wrote:
>> 
>> Ahem. Maybe just change the maximum results limit for privileged clients that need it?
>> 
>> Maybe this is a best practice item?
>> 
>> Phil
>> 
>>> On Sep 13, 2021, at 4:53 PM, Danny Mayer <[e-mail]> wrote:
>>> 
>>> 
>>> The experience I've had in doing pagination mostly (but not exclusively) involved HR systems which had a 1000 per response limit but were not related to usage of scim. However any API call that returns a list can be subject to a limit by the scim server, most likely in order to preserve resources and not to tax the memory.
>>> 
>>> Danny
>>> 
>>> On 9/13/21 5:45 PM, Matt Peterson (mpeterso) wrote:
>>>> I agree.  
>>>>  
>>>> Pagination and Synchronization show up under the same bullet in the charter, but, like you, I think of them as separate (possibly related) topics.  I am interested in both topics. 
>>>>  
>>>> As proof, I’m hoping to get feedback from anyone that has additional pagination use case besides the “use of pagination for initial load of synchronized objects”:
>>>>  
>>>> 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
>>>>  
>>>> 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]> On Behalf Of Danny Mayer
>>>> Sent: Friday, September 10, 2021 6:11 PM
>>>> To: Nancy Cam-Winget (ncamwing) <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.
>>>>  
>>>> 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  (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
>>>> [e-mail]
>>>>  
>>>>  
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Sep 8, 2021, at 5:21 PM, Nancy Cam-Winget (ncamwing) <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, 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.
>>>> 
>>>> 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 as a base)
>>>>  
>>>> Best, Nancy (as one of the BoF chairs)
>>>>  
>>>> _______________________________________________
>>>> scim mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/scim
>>>>  
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> scim mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/scim
>>>> 
>>>> 
>>>> _______________________________________________
>>>> scim mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/scim
>>>> 
>>>> 
>>>> _______________________________________________
>>>> scim mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/scim
>> 
>> 
>> _______________________________________________
>> scim mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/scim