Re: [scim] BoF Review and workshopping the Charter based on SCIM IG call, Aug 4

["Matt Peterson (mpeterso)" <[e-mail]>]

Phil,

I agree.  I think that "client-side caching" (sync) of users and groups is a common use case for pagination because large results are generated not only the initial load of objects but also when trying to detect deletions (especially deletion of group memberships).  There must be a better (more efficient way) of handling this use case than polling with expensive queries.

Like you, I'd really like to get people to post their pagination use cases so that we can categorize them.  I thought about posting to this mailing list with a follow up call for pagination use cases.

But I also, I agree with what Parul said on the the Aug 4 call (from the meeting notes):

Parul: we do need cursor-based pagination, and that is unlikely to go away but it doesn't harm to first define the synchronization world and then look at whether pagination needs to be enhanced...

Parul's suggestion on ordering the tasks is a good one.  It might be useful to get a consensus on "synchronization use case" first.  Then dig into pagination so that we're not trying to talk to both at the same time.

On the topic of synchronization, I think there are two common use cases:


  1.  Constructing and enforcing Application authorization models -  An application (acting as a SCIM client) caches users/groups data from the IdP in order to present "user/group pickers" when presenting screens used to configure the application  authorization rules (RBAC, Policy, or ACL).  Also, when the application enforces authorization, user and group data needs to be immediately available so that authorization decisions can be made quickly.
  2.  Identity Management and Governance systems - implement a canonical identity model" where all accounts and groups are represented.  This model is used to build provisioning rules and calculate separation of duty violations, attestations, and approvals etc.   Management-time evaluation of the model needs to be done efficiently without external calls to the SCIM service provider.

Both of the above use cases, are client-cache use cases -- a "one-way" sync:  a) download the initial results and, b) keep the results up to date with changes that are being made on the SCIM Service provider.

It think it could help us narrow down the list of suitable approaches if we could agree that "one-way" sync (keeping a client-side cache up to date) is our target.

--
Matt

From: scim <[e-mail]> On Behalf Of Phil Hunt
Sent: Friday, August 13, 2021 1:52 PM
To: Pamela Dingle <Pamela.Dingle=[e-mail]>
Cc: [e-mail]
Subject: Re: [scim] BoF Review and workshopping the Charter based on SCIM IG call, Aug 4

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.

Pam,

Thanks for the notes.  Apologies for not making the last meeting.


Paging and Sync Comments:
In my conversations with Matt Peterson we both have the feeling that the request for "stateful" paging of results has to do with clients wanting to do synchronization. The technical need is driven by memory limitations in clients.  Matt, let me know if I am speaking out of turn, but this form of "paging" for synchronization and reconciliation is a "poor-mans" approach.

I would like to ask if there are other use-cases or need people have for stateful paging other than co-ordination and synchronization. If so, stateful paging may be worth pursuing given appropriate caveats.

Given this, Synchronization/Co-ordination needs to be explored at least in case of requirements as a charter item.  In SCIM environments there are many cross-domain scenarios where items are not being replicated. However entity life-cycles need to be co-ordinated.  I would like to see an approach that works on "changes" only rather than pulling full data sets.  This is an information minimization approach and minimizes data transfer.   There are many possible technolgoies we could explore:
* Security Event streams (publish/subscribe or event bus).  A stream can be explicit or contain simple "this resource has changed".
* Usage of pre-conditions to detect resource changes (date and etag)
* Change date query to detect changed resources (kind of an evolution of ldap changelog)
* Reversal of roles.  Service provider acts as client to send changes back
* Others TBD

Schemas:
Regarding Leif's comments, I took him to mean he would ike to see servers not built on hard coded or otherwise fixed schema (e.g. POJOs).  I didn't take him to mean that there was protocol work to be done here.   My recently published i2scim.io<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fi2scim.io%2F&data=04%7C01%7Cmatt.peterson%40quest.com%7C6d5d35b1ff4a47121a2a08d95e93e7e7%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637644811626277847%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=qxy0%2BxCMe4vJ7A3HZ5hmAlEkzczsvq52fOBsRfZ7h%2BY%3D&reserved=0> open source implementation is an example of this.

>From the call I am not sure what was meant by "Discoverable schema is only useful for optional attributes".  In the sense that a server should support Users and Groups, there's nothing saying other schemas and resource types can't be defined and optionally registered via IANA.  In that sense, the /ResourceTypes and /Schemas endpoints become very meaningful.

I think there is a higher level problem of interring meaning beyond Attributes types and characteristics as well as resource type definitions that may seem arbitrary. I think this is where the standard process is useful.  Any publication process is going to help act as a reference for implementers to understand purpose and meaning beyond raw data.

Phil Hunt
@independentid
[e-mail]<mailto:[e-mail]>




On Aug 13, 2021, at 5:36 AM, Pamela Dingle <Pamela.Dingle=[e-mail]<mailto:Pamela.Dingle=[e-mail]>> wrote:

Hi all,
Apologies for the lateness of this summary!    This note talks through our discussion last week on our BoF and on next steps, but the real meat here is the decision making that necessarily needs to move to be email-focused.   Please give us your reactions to the topics below.    Additionally,  our summary of the meeeting, links to the meeting, and thoughts and goals moving forward are here:  meetings/2021-08-04.md at main * SCIM-Interest-Group/meetings (github.com)<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSCIM-Interest-Group%2Fmeetings%2Fblob%2Fmain%2F2021%2F2021-08-04.md&data=04%7C01%7Cmatt.peterson%40quest.com%7C6d5d35b1ff4a47121a2a08d95e93e7e7%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637644811626287844%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=NbBTKbHYd8E2X%2BnqvYAfPMUhZzP6pJIRNa4q%2Bbck8pA%3D&reserved=0>. Video of the meeting is available on Youtube: https://youtu.be/msGCsG752PA<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fyoutu.be%2FmsGCsG752PA&data=04%7C01%7Cmatt.peterson%40quest.com%7C6d5d35b1ff4a47121a2a08d95e93e7e7%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637644811626297841%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=q5pABg2LL5A5%2FtK%2B5b2RONXNYJvHbvul%2FmIi6NIzwd0%3D&reserved=0>

Three issues need surfacing to the wider community, based on commentary in the BoF:
Synchronization not a Charter Focus
While we have spoken a lot in our interest group meetings about pagination, comments from Morteza around synchronization sparked a conversation around the relationship between pagination and synchronization -- is it that pagination is so critical because large data set fetches are the only way to do synchronization?   The consensus from the group in the meeting was that yes, there is a relationship here, and while we definitely still think pagination is a critical topic, understanding the nature of our syncronization use cases could shed light on why large data set handling is so critical for many.
Fixed vs. Discoverable Schema
Discussion of Leif's comments in the BoF about lack of flexibility in current schema efforts resulted  the group suggested that we should look at what could be done to better support discoverable schema.  Can we make the discovery mechanism already in the spec more dynamic or more able to be part of a schema negotiation?
Discussion on External ID and Privileged Access
We didn't get a chance to discuss, but are looking for thoughts and discussion from the community.
Moving towards IETF Conformant Comms and Processes
Nancy Cam Winget (one of our BoF chairs) has been advising us on next steps and the discussion began on process.  The group took a shot at running some consensus calls today in the meeting based on the above topics, you can see them below and we want your feedback, but going  chairs. Additionally Nancy was very clear that the critical consensus mechanism needs to be the mailing list - so we will work to make sure those motions are properly followed.
Please give us your thoughts & reactions to these two statements and their impact on the proposed charter:

Consensus call (9/11 within the call):  We will explore synchronization patterns and deliver a document describing what implementers are doing, with one focus being how large data sets are involved as an early deliverable

Consensus call (7/11 within the call) for "investigating discoverable schema as part of our schema milestone" deliverable would be a document containing recommendations delivered to the WG
Cheers,

Pam

_______________________________________________
scim mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/scim<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscim&data=04%7C01%7Cmatt.peterson%40quest.com%7C6d5d35b1ff4a47121a2a08d95e93e7e7%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637644811626307835%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Skaa6SfAZRcFCpVgRW8vQ8DZXTVgrHYXlbB7stowng8%3D&reserved=0>