2️⃣ Enrollment
Enrollment is the process of registering a new user by connecting their facial biometrics to a Keyless account. During this process, a full and unobstructed view of the user's face is required.
val configuration = BiomEnrollConfig()
Keyless.enroll(
configuration = configuration,
onCompletion = { result ->
when (result) {
is Keyless.KeylessResult.Success -> Log.d("KeylessSDK ", "Enroll success - userId ${result.value.keylessId}")
is Keyless.KeylessResult.Failure -> Log.d("KeylessSDK ", "Enroll failure - error code ${result.error.code}")
}
}
)
Enrollment configuration
You can configure the enrollment process with optional parameters in your BiomEnrollConfig()
instance or using the builder pattern methods from the EnrollmentConfiguration
builder.
public data class BiomEnrollConfig(
public val cameraDelaySeconds: Int = 2,
public val customSecret: String?,
public val jwtSigningInfo: JwtSigningInfo?,
public val livenessConfiguration: LivenessSettings.LivenessConfiguration = PASSIVE_STANDALONE_HIGH,
public val livenessEnvironmentAware: Boolean = true,
public val operationInfo: OperationInfo?,
public val shouldRetrieveTemporaryState: Boolean = false,
public val shouldRetrieveEnrollmentFrame: Boolean = false,
public val temporaryState: String?,
public val showSuccessFeedback: Boolean = true,
public val showInstructionsScreen: Boolean = true,
public val showFailureFeedback: Boolean = true
)
Enrollment success result
Depending on the builder methods you enable, Keyless will populate the corresponding fields in the EnrollmentSuccess
result reported below.
data class EnrollmentSuccess(Delaying the Keyless evaluation/decision
By default, our biometric decision making process initiates immediately on the camera being invoked and the camera preview showing. We believe this offers the maximum level of security in that an attacker is given no additional preparation time in front of the camera view, while at the same time we have looked to optimise the experience for genuine users i.e. delivering both approve and reject decisions in a way that feels natural and understandable to users.
However, we recognise that our customers, and their users, have different contexts and preferences and therefore the cameraDelaySeconds configuration is available to specify the delay (in seconds) between when the camera preview appears, and when the liveness processing starts. In effect, no decision, whether
Please note we advise careful consideration when implementing this feature for two reasons:
i) While this allows users to frame themselves and have longer to understand what is happening, is also time for any attackers to also optimise their framing.
ii) Implementing will ultimately mean that the "happy path" flow for all users is extended. If the delay is set for too long, some customers have noted that there is also the potential for some users to become frustrated and cancel/drop the flow.
We're happy to engage further in what the best trade-offs may be for customers, given our wide-ranging experience of assisting customers in live implementations.
val keylessId: String,
val customSecret: String = "",
val signedJwt: String? = null,
val enrollmentFrame: Bitmap? = null,
val temporaryState: String? = null
) : KeylessSdkSuccess()
Delaying the Keyless evaluation/decision
By default, our biometric decision making process initiates immediately on the camera being invoked and the camera preview showing. We believe this offers the maximum level of security in that an attacker is given no additional preparation time in front of the camera view, while at the same time we have looked to optimise the experience for genuine users i.e. delivering both approve and reject decisions in a way that feels natural and understandable to users.
However, we recognise that our customers, and their users, have different contexts and preferences and therefore the cameraDelaySeconds
configuration is available to specify the delay (in seconds) between when the camera preview appears, and when the liveness processing starts. In effect, no decision, whether
Please note we advise careful consideration when implementing this feature for two reasons: i) While this allows users to frame themselves and have longer to understand what is happening, is also time for any attackers to also optimise their framing. ii) Implementing will ultimately mean that the "happy path" flow for all users is extended. If the delay is set for too long, some customers have noted that there is also the potential for some users to become frustrated and cancel/drop the flow. We're happy to engage further in what the best trade-offs may be for customers, given our wide-ranging experience of assisting customers in live implementations.
Custom secret
During enrollment you can specify a custom secret to be saved and encrypted along with the user's biometric data using savingSecret
paramter. The custom secret can be anything you can save as an ASCII string, such as a secret that you have provided to the app from the backend, the seed of an OTP protocol, or anything else.
JWT Signing info
You can specify a payload to be added to a JWT signed by Keyless with the jwtSigningInfo
parameter, more in JWT signing.
Liveness Settings
Using livenessConfiguration
you can configure the liveness security level during enrollment. The possible liveness configuration are under LivenessSettings.LivenessConfiguration
:
PASSIVE_STANDALONE_MEDIUM
PASSIVE_STANDALONE_HIGH //recommended configuration
PASSIVE_STANDALONE_HIGHEST
You can also specify a livenessEnvironmentAware
that is by default se to true
to enhance liveness detection. This parameters helps to ensure the user is in a suitable setting for verification.
More details on liveness in the dedicated liveness settings section.
Operation info
The parameter operationInfo
specifies a customizable unique operation identifier and associated payload stored on the Keyless backend if the enrollment succeeds. Use this to add an extra level of confirmation in your operations.
Details on how to query our backend for stored operations are available on Operations API.
Temporary State
Keyless users can be enrolled via IDV-Bridge, Identity Verification Bridge. As a result of IDV-Bridge enrollment you receive a temporary state useful to register users in your app without undergoing the full enrollment flow.
Use the temporaryState
parameter to register users from a temporary state obtained through IDV-Bridge.
You can also use a temporary state to recover an account of an existing user who lost access to the account. Follow the guide on account recovery.
Enrollment Frame
Integrators can specify whether or not to retrieve an enrollment frame, acquired during the user’s selfie capture during the enrollment or account recovery flow. You can achieve this by setting shouldReturnEnrollmentFrame
to true
on the BiomEnrollmentConfig
(defaults to false
). If the enrollment succeeds, you can retrieve the frame from the returned EnrollmentSuccess
, via enrollmentFrame
.
Enrollment circuits
To speed up enrollment you can use the numberOfEnrollmentCircuits
to upload less than the default of five circuits upon enrollment. The remainder (50 - numberOfEnrollmentCircuits
) are uploaded asynchronously.
Last updated
Was this helpful?