...
The client organisation can trigger a request for an individuals details from a redirection back to the client web site website after a user centric verification is completed by the user, however, this will not capture verifications caused through the admin panel, nor will it capture users who get verified but do not press the “finish” button.
...
The URL will be called as a POST HTTP request with the person’s individual identifier included as a POST parameter. The identifier is also be appended as a URL parameter, for example, if we configure http://www.example.com/notify.html as the notification URL then if the person with userId (verificationId) 123 is verified then the notification URL will be http://www.example.com/notify.html?userId=123. We can, if required, remove the URL parameter.
...
We recommend that when a client organisation receives the notification a call to the getVerificationResult web service method be made to check that the individual is truly verified. This avoids any risk of an attacker faking a call from greenID and tricking the client organisation into believing that a person has been verified.
For a successful notification, greenID by default expects a HTTP 200 response from the URL it calls, otherwise greenID will continue to retry up to 5 times and 30 seconds apart. Optionally we can configure greenID to accept other HTTPS response code as a successful outcome.
Finally, the notification URL is set as a property for a client organisation and can only be configured or changed by greenID staff.
...