In-Band Registration

Description

Before a user can authenticate with the FIDO UAF protocol to access an application, FIDO UAF credentials must be created and stored both on the user's device and on the FIDO Server. This operation is called Registration. The security requirements of the application protected by the Nevis Mobile Authentication Solution define the nature of the authentication, which can be, for example, fingerprint, PIN/password, face recognition, or a combination of several authentication mechanisms.

Prerequisites

• The user's mobile client application, which is generating the credentials, has FIDO capabilities. It contains an embedded FIDO Client with access to one or several FIDO Authenticators.
• The user already has existing credentials (a password, for instance) that can be used to authenticate.
• Nevis is configured in such a way that only authenticated clients can register FIDO UAF credentials.
• The Mobile Client Device successfully executes a legacy authentication before starting the registration flow.

Example

1. The user launches the e-banking application on the mobile device. The e-banking application detects that there are no credentials and asks the user to start a registration.
2. The mobile client application sends a request to register new FIDO credentials.
3. Nevis detects that the mobile client application is not authenticated and now tries to register. Nevis asks the user to authenticate. This authentication must follow the security policy required to register new FIDO credentials (a password).
4. The user authenticates providing a password. Nevis allows the mobile client application to perform the registration.
5. The mobile client application sends a request to Nevis to do the registration.
6. Nevis responds by describing the authentication methods (fingerprint) allowed by the e-banking server application, which is protected by the Nevis Mobile Authentication Solution.
7. The user authenticates using an authenticator that complies with the requirements of the e-banking server application. New FIDO credentials are created on the client device.
8. The credentials are sent to Nevis.
9. The e-banking application stores the credentials and notifies the mobile client application about the successful registration.

Technical Flow

The technical flow in the following figure explains the component interaction in detail. The step numbers in the next figure do not correlate with the simplified example above.

The following table describes the steps in the previous figure. The numbers in the table correlate with the step numbers in the previous figure.

Step nr.	Description	Endpoint	References
1.	The Relying Party mobile authentication sends a GetUAFRequest to the Registration Request Service endpoint defined in nevisProxy.During this step, the mobile client accesses the same endpoint as in the legacy authentication step, but now with an existing authentication.The legacy authentication step takes places before all other steps described in this table. You find the legacy authentication flow at the top of the previous figure. It does not have a number.The GetUAFRequest must be created with the operation set to "Reg".	https://<nevisProxy-host>:<nevisProxy-port>/nevisfido/uaf/1.1/request/registration This endpoint is an example of mapping nevisProxy to the nevisFIDO Registration Request Service endpoint.	nevisFIDO Reference Guide:- "Registration Request Service"FIDO Specification:- "GetUAFRequest"
2.	nevisProxy includes the SecToken and the UserId into the forwarded request.The inclusion of the SecToken ensures that nevisFIDO will receive the user information in a secure way. It also allows nevisFIDO to verify that an authentication has already been successfully completed. This information is necessary to initiate the FIDO registration.The UserId is delegated to generate a correctly formatted authorization header.	-	nevisProxy Reference Guide: - DelegationFilternevisFIDO Reference Guide:- "SecToken Username Provider"
3.	nevisProxy forwards the GetUAFRequest to nevisFIDO.	https://<nevisFIDO-host>:<nevisFIDO-port>/nevisfido/uaf/1.1/request/registration	nevisFIDO Reference Guide:- "Registration Request Service"FIDO Specification:- "GetUAFRequest"
4.	The signature of the SecToken is verified by nevisFIDO, which thus ensures that a previous authentication has happened.nevisFIDO extracts the username from the Context of the GetUAFRequest. The username can be the user's extId or the loginId from nevisIDM - this is configurable.		nevisFIDO Reference Guide:- "SecToken Username Provider"
5.	nevisFIDO responds with a ReturnUAFRequest containing the generated RegistrationRequest. The RegistrationRequest contains policies that specify the requirements for the authenticators to be registered.nevisProxy forwards the ReturnUAFRequest to the Relying Party mobile application.	-	nevisFIDO Reference Guide:- "Response BodyFIDO Specification:- ReturnUAFRequest
6.	The Relying Party mobile application triggers a request to fetch the trusted facets.The information accessible at the Facets Service endpoint helps FIDO clients to identify whether the application the user wants to access is an authorized facet of the protected application (for example, whether the e-banking app on the user's mobile phone is an authorized facet of the e-banking application).	https://<nevisProxy-host>:<nevisProxy-port>/nevisfido/uaf/1.1/facets This endpoint is an example of mapping nevisProxy to the nevisFIDO Facets Service endpoint (https://<nevisFIDO host>:<nevisFIDO port>/nevisfido/uaf/1.1/facets)
7.	nevisProxy forwards the trusted facets request to nevisFIDO.	https://<nevisFIDO-host>:<nevisFIDO port>/nevisfido/uaf/1.1/facets	nevisFIDO Reference Guide:- "Facets Service"FIDO Spec:- Facets
8.	nevisFIDO returns the trusted facets it maintains. nevisProxy forwards them to the FIDO client.	-	nevisFIDO Reference Guide:- "Response Body"FIDO Specification:- TrustedFacets
9.	The user authenticates in the device according to the policy that is provided in the RegistrationRequest.	-	-
10.	The FIDO UAF Authenticator generates the assertion that is proof of the authentication the user has completed in the previous step ".
11.	The Relying Party mobile app sends a SendUAFResponse to the Registration Response Service endpoint defined in nevisProxy.The SendUAFResponse contains a RegistrationResponse.The RegistrationResponse contains the assertion, and thus the public key of the generated key material.	https://<nevisProxy-host>:<nevisProxy-port>/nevisfido/uaf/1.1/request/registration This endpoint is an example of mapping nevisProxy to the nevisFIDO Registration Response Service endpoint.	FIDO Specification:- SendUAFResponse
12.	nevisProxy forwards the SendUAFResponse to nevisFIDO.	https://<nevisFIDO-host>:<nevisFIDO-port>/nevisfido/uaf/1.1/request/registration	nevisFIDO Reference Guide:- "Registration Response Service"
13.	nevisFIDO creates a FIDO credential containing the received public key. nevisFIDO stores the FIDO credential in nevisIDM, such that it is related to the relevant username.	-	-
14.	nevisFIDO returns the ServerResponse to the Relying Party mobile application through nevisProxy. The ServerResponse contains information regarding whether the registration was successful. nevisFIDO concludes the operation. At this point, the Nevis Mobile Authentication Solution considers the registration as completed.	-	nevisFIDO Reference Guide:- "Response Body"FIDO Specification:- FIDO UAF ServerResponse

Configuration Snippets

You will find example configuration snippets for all involved components in Nevis Component Configuration Examples.