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

[Wesley Dunnington <[e-mail]>]

I don't know if its being thrown into the consideration set or not,
especially since Phil was one of the authors of the original draft, but the
use cases that had me excited about the pagination and filtering spec were
its enhanced querying and filtering capabilities, whether used as a
finer-grained synchronization mechanism, or simply as a query mechanism.

I just want to make sure those capabilities aren't being lost in the
synchronization discussion shuffle.

Best
Wes Dunnington

On Mon, Aug 16, 2021 at 2:07 PM Matt Peterson (mpeterso) <Matt.Peterson=
[e-mail]> wrote:

> 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]
>
>
>
>
>
>
>
> On Aug 13, 2021, at 5:36 AM, Pamela Dingle <
> 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]
> 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>
>
>
> _______________________________________________
> scim mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/scim
>


-- 
<https://www.pingidentity.com>[image: Ping Identity]
<https://www.pingidentity.com>
Wesley Dunnington
Senior Director Architecture
 [e-mail]

c: 508-254-5475
Connect with us: [image: Glassdoor logo]
<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
[image:
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter
logo] <https://twitter.com/pingidentity> [image: facebook logo]
<https://www.facebook.com/pingidentitypage> [image: youtube logo]
<https://www.youtube.com/user/PingIdentityTV> [image: Blog logo]
<https://www.pingidentity.com/en/blog.html>
<https://www.google.com/url?q=https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/faqs/en/consumer-attitudes-post-breach-era-3375.pdf?id%3Db6322a80-f285-11e3-ac10-0800200c9a66&source=gmail&ust=1541693608526000&usg=AFQjCNGBl5cPHCUAVKGZ_NnpuFj5PHGSUQ>
<https://www.pingidentity.com/en/events/d/identify-2019.html>
<https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/Misc/en/3464-consumersurvey-execsummary.pdf>
<https://www.pingidentity.com/en/events/e/rsa.html>
<https://www.pingidentity.com/en/events/e/rsa.html>
<https://www.gartner.com/reviews/vendor/write/ping-identity/?utm_content=vlp-write&refVal=vlp-ping-identity-32202&utm_campaign=vendor&utm_source=ping-identity&utm_medium=web&arwol=false>
<https://www.gartner.com/reviews/vendor/write/ping-identity/?utm_content=vlp-write&refVal=vlp-ping-identity-32202&utm_campaign=vendor&utm_source=ping-identity&utm_medium=web&arwol=false>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._