Aha! More fodder for discussion:
Why? Why must identity information be synchronized before the user performs the first authentication? If a new employee has been provisioned an account at an IdP, why shouldn’t that person be able to arrive at a Relying Party, and at that time have the IdP advise the Relying Party that (1) the user is valid, and (2) the user should be provisioned into the system? I don’t see why my example from earlier can’t work in reverse — you batch update your incoming staff updates, but if they attempt to access the system before the batch job is accomplished, the IdP bundles a specific real-time provisioning request into the authentication, and the user is set up and granted access.
To me, real-time back-end data synchronization is needed between silos. Once you have a single Identity authority with a reach across administrative domains, and once you are doing more than testing possession of a shared secret, you have alternatives. Perhaps not in every case – but in some cases, perhaps many cases. Imaginative exploration of these new usage models are what makes this technology so much fun!