The "Job of Provisioning" (abstract technical definition): Keeping identity information state consistent across all components of the institutional IT ecosystem
Guideline: Build provisioning models using compositions of Enterprise Integration Patterns (EIP): http://www.eaipatterns.com/
"Event-driven" and "messaging" are high level, abstract EIP constructs that help structure discussions of provisioning capabilities
They do NOT commit one to a particular technical infrastructure such as ESB, JMS, though those are among the candidate solutions
(RobC: Is this a good place to note (or do we even need to note) anything about the concepts of near-real-time consistency versus time-average consistency, which in turn lead us to think more in terms of "event-driven" and "messaging" than in terms of "file-transfer" and "batch"? Or to note that even with near-real-time consistency as a goal, we recognize the need to plan for bulk synchronization as a option in the event of catstrophe recovery or simple initialization in a pre-existing environment?)
Principle: Standards at the core, customization at the edges
E.g., Core: Canonical data models; SCIM as the rising new protocol to serve provisioning needs
E.g., Edge: Connectors that speak SCIM on one side and speak app-specific APIs on the other; flow goes both into and out of app
Scope: Re-label Provisioning as "App and Data Integration Services"
This brings into scope the feeds from source systems to person registries
in addition to traditional view of provisioning FROM the person registry to "consumer" systems
(RobC: I think this is good, also, in that it reinforces the idea that provisioning isn't necessarily just "attribute synchronization" -- at the "application integration" rather than "data integration" end of the scale, things like provisioning of access control information associated with identity (eg., FERPA privacy controls for students) or more complex entities like group memberships may (although not necessarily) fall in-scope)
[OSIdM4HEteam:Extensible] person/agent identity information schemas
including mappings to/from canonical data models, e.g., SCIM, LDAP, RDBMS)
Connector building, collecting, reposing, support for downloading
Detailed recommended solutions to a defined set of common provisioning tasks
based on compositions of EAI patterns
including source system of record feeds to the person registry
as well as classic provisioning cases
including optional rules engine to externalize identity business processes including identity life-cycle management
Reference implementations of recommended solutions in Kuali Rice AND in Apache ServiceMix
(RobC: Might we want to go so far as to plan for reference implementations provisioning in both the outbound (registry-to-target) and inbound (source-to-registry) direction, here? If there's interest, at least, in sharing code or strategy between data flows on the inbound and outbound sides of the registry, it might be helpful for developers looking to extend the reference tools to have reference implementations in both directions)