In the B2B and B2C worlds, there is a subtle difference - mainly verification or approval of the users attempting registration. Many organisations, especially within the financial services arena (I'm thinking retail banking, insurance, asset management, share management etc) all require not only a strong level of authentication (OTP, biometric, MFA) but also a strong level of assurance or verification first.
The above is an example of a basic flow that occurs during a self-registration process. (Note I documented the detailed integration with Facebook is here)
Step 3 is the interesting part. Many organisations may have an internal authoritative source of user information which they want to use to link to any form based data collected at registration time. For example, this maybe a database of policyholders and their names and addresses which has been collected and cleaned over several years, perhaps populated via in branch / in person sales, making it a the most authoritative source. During the registration process, the user may have to submit their account number, policy number, customer registration number or even just a unique identifier created to allow them to register. Basically something they know.
In OpenIDM we can quickly set up a managed/user mapping to the authoritative source, simply to perform linkages if the data entered is accurate and correlates. In the ../conf/sync.json we can create a mapping that only creates links, as opposed to the traditional reconciliation processes of creating and updating users.
The two situations of interest are FOUND and MISSING. For a detailed explanation of what these mean see here.
A link will intimate that the data entered via the form maps to the authoritative source. The mapping criteria is controlled via a JavaScript correlation query that is entered in the main part of the mapping meta-data. The correlation query can be made up of a simple one to one attribute value map, or in v3.0 of OpenIDM, we can use a queryFilter which may be more complex.
When a match occurs, a link is then recorded within the OpenIDM repository, which can then use for identifying a user as being verified. We can simply drop in an onLink script, to update the source user with an attribute called 'verified' which we can populate with a true/false flip dependent on the data entered.
Another option at the FOUND stage, is to enter in a workflow. This workflow could stop the immediate verification script from running, until an assessor or approver, has physically logged into OpenIDM, checked the user details and then approved.
Here we simply replace the link action within the FOUND situation to run a workflow trigger. The trigger file simply calls the BPMN2.0 workflow definition that contains the approval logic. The workfile is created in any BPMN2.0 compliant IDE, to the XML output that sits in the ../workflow folder. When a user now registers, and also correctly maps into the authoritative source, an approver can be notified to perform an additional approval step via the REST API or OpenIDM UI.
Once approved, the user is then updated with a verified attribute, that is flagged as true, which can then be used in further downstream provisioning jobs.
