Re: [scim] Charter Discussion: Triggers

[Phillip Hunt <[e-mail]>]

 I was heavily involved in these specs. The sET delivery specs aren’t competing (RFCs 8935,8936). The presence of 2 methods may look that way because some cloud providers would not implement polling (eg for firewalled enterprise customers) while others said it was critical. Polling consumes scarce tcp/ip connections and thus costly to scale in some OIDC provider scenarios with large numbers of clients in 100ks or much more. The very rough consensus decision of the WG was to split the draft. 

Still both drafts are almost identical except for push vs poll. Delivery is assured as client receivers are given time to ack transfer success. The ack means the publisher no longer has to retain the event (unlike a changelog). 

The limit of short recovery was a compromise because major providers felt they could not keep events forever for 100ks of clients (eg a single oidc provider and all registered clients).  I don’t believe that is the case in scim scenarios. Scim scrnarios are more balanced.  

In both drafts the client can recover within an unspecified “short” period of time.  I would expect that in scim cases this could be indefinite. 

My belief is this would be easy to implement if you already implemented bulk processing. Unlike bulk endpoint, there are no temporary identifier issues. My implementation prototype simply uses bulk operation messages now. 

Subject identifier is interesting but i think that may be part of a another discussion around external id. Its a huge can of worms if endpoints cannot agree on identifiers. 

Phil

> On Jul 13, 2021, at 8:37 PM, Matt Domsch <[e-mail]> wrote:
> 
> I certainly see value in a standardized mechanism to notify subscribers about changes (C/U/D) to objects that would otherwise only be recognized by polling the whole list of objects periodically.  Both Shared Signals / IETF Subject Identifiers, augmented with SCIM object schema, would be a fine representation method.  There are several competing transport methods (SET Push and/or Shared Signals subscriptions) still to be worked out. These would allow real-time notification of object changes, which is highly desirable.   However, these are still "best effort delivery" methods and events can fail to be generated, fail in transport, or fail to be received, meaning systems wanting to maintain as accurate a synchronization as possible may still periodically, though considerably less frequently, poll for the entire object list again.  Therefore you can't supplant one with the other, both would still be necessary.  For the benefits in the majority of cases though it'd be great to have event-delivered changes.
> -Matt
> 
> On Wed, Jul 7, 2021 at 11:23 AM Phil Hunt <[e-mail]> wrote:
>> In the discussion about cursors, it occured to me that some queries are happening as a form of polling by one or more client entities in order to co-ordinate state of user entries across many clients and domains.
>> 
>> Way back when, the original SCIM WG charter had an item called “triggers”. Triggers were events that could be distributed to registered clients to notify them of events. Some of the cursor use cases could be addressed with async triggers (events) rather than using “polling with cursors”t. 
>> 
>> The triggers concept wasn’t actually abandoned,  The work on events did actually go forward (in the SECEVENT WG) and was published as RFC8417  (aka Security Event Tokens).   OpenID Connect as an example uses SETs to notify parties of a logout in the back channel.  The OpenID Shared Signals group is also defining events, many of which, occur within SCIM servers.
>> —> Would defining SCIM Events go a long way to avoid the need for cursors in at least some cases (e.g. notifying receivers that a resource was deleted or a password updated)?  Should we put this on the table?
>> 
>> —> is this something the group would like to pick up and exploit now that the underlying message format is defined?
>> 
>> On the call today, it was also brought up that the interaction pattern of client initiating against the server may need to evolve/expand. Async SET events may be one possibility. To solve these cases.
>> 
>> Phil Hunt
>> @independentid
>> [e-mail]
>> 
>> 
>> 
>> 
>> _______________________________________________
>> scim mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/scim