Developers

OIDC Configuration

General Information

The in-browser feature is activated through OIDC scopes that can either be statically configured in the user portal, or passed programmatically during the initial authorize call by the Relying Party (RP). For information about how to get started with the OIDC Bridge, visit OIDC configuration

Activation of the Feature

An OIDC authentication will typically start with the(RP) constructing a request for a login redirect url for the OIDC bridge. For example: This will yield a redirect url that is forwarded to the client and will bring them to the following login page:

screen

To activate the “Verify with iProov” in the browser, add one of the following scopes:

  • faceauth_dynamic_only : Face verification on the webpage only, using Dynamic Liveness
  • faceauth_express_only : Face verification on the webpage only, using Express Liveness
  • faceauth_dynamic : Face verification with Dynamic Liveness, the end user can between using the iProov ID app or on the web page
  • faceauth_express : Face verification with Express Liveness, the end user can choose between using the iProov ID app or on the web page

Retries

By default, every login request using the web-based verification allows for up to 3 retries. After 3 failed attempts, a deny response will be sent back to the relying party. At this point it is up to the RP themselves to decide whether they want to issue a new login request to this user, granting 3 new attempts, or block the user/IP address from further retries.

Modes of Operation

The in-browser functionality currently supports two modes of operation:

Liveness Only

This is the default and is activated if the login_hint is missing, empty, or contains face:any. The system will then check for liveness of the person without performing any face comparison, i.e. any face will pass provided it’s a real face.

Hosed Biometric Profile

Simply provide a unique user identifier or email address in the login_hint field. The first time the identifier is seen, a biometric profile will be created for that person and stored on the iProov servers (this is an iProov enrolment). The next time a request is made with this login_hint, the system will perform a verification by comparing to the existing profile (iProov enrollment)

Photo Verification

It is also possible to submit a reference photo through the login hint. In this mode, the system will perform liveness similarly to before and ensure the face of the user matches the reference photo provided.

To do so, submit a reference photo as a data-url encoded JPEG in the login hint, i.e. : login_hint=face:data:image/jpeg;base64,/9j/4AAQSkZJRgABAgAAZ…

Output Claims

While using the in-browser feature, only the following OIDC claims are present:

  • sub : the OIDC subject identifier. When used in-browser, this value is unique per session and will never repeat (or authentication with the app, the sub corresponds to the wallet key and will be the same for every login with the same wallet instance.)
  • com.svipe:face_present : a claim confirming that the liveness check was performed containing metadata about the method used, the server that performed the verification, the time of the verification as well as the value of the state field of the OIDC authentication session for which this verification was performed. This assures that a particular verification has been done for a specific login and cannot be re-used for another login attempt. This claim is primarily designed for audit logging as it contains detailed information on the process that took place but no personal data.
  • com.svipe:validation_portrait_present: these claims contain a datauri-encoded portrait of the user captured during the liveness check. It is to be noted that Dynamic and Express Liveness provide different types of portraits:the first gives a photo cropped around the face of the user, somewhat similar to a passport photo, while Express provides a wide-angle photo. This claim can, for example, be used if the relying party wants to run their own face matching algorithm without sharing the reference photo with iProov.
  • email : for web, if an email was provided in the login_hint, this field will return that same email.

Any other requested claim will be ignored.

Success / Failures

The in-browser feature offers the option to try the face verification 3 times before denying the OIDC request. Cancellation by the user will immediately lead to a redirect back to the RP with a failure. Once the RP receives a failure, it may or may not decide to allow more retries by initiating a completely new login request and redirect. As such, the limiting on the number of times a user can retry is left to the RP. No hard limits on total number of retries are currently enforced on iProov side.

Data Retention

With Hosted Biometric Profile

If a hosted biometric profile is used (no login_hint other than face:* ), data retention follows the retention rules applied to the iProov service provider used for your service. Contact your iProov representative if you need info about your current setup or to request a change.

Without Hosted Biometric Profile

In all other cases, as soon as success or failure response is returned to the RP, anything related to the identification session is removed from the production system. Persistence only exists through audit logs (which are one-way encrypted with a key kept offline, and are never available to the production system). The key pair used to secure the transaction is deleted.