Page 48 - Implementation of Secure Authentication Technologies for Digital Financial Services

Figure 32 – Registration process of FIDO

The enrolment steps are:
⓪ Application Requests Registration - The application makes the initial registration request after completing identity
proofing / KYC and within the same session or trusted environment.
① Server Sends Challenge, User Info, and Relying Party Info - The server sends a challenge, user information, and
relying party information to the Relying Party Application. The Relying Party Application can be a mobile, web,
native, or other application and its implementation is outside of the scope of the FIDO specifications. The proto-
col for communicating with the server is not specified and is also outside of the scope of FIDO. Typically, server
communications would be REST over TLS, but they could also be SOAP, RFC 2549 or nearly any other protocol
provided that the communication channel is secure. The parameters received from the server will be passed to the
client to create credentials, typically with little or no modification..
② Client Calls authenticatorMakeCredential on Authenticator via CTAP - Internally, the client will validate the param-
eters and fill in any defaults, which become the clientData. One of the most important parameters is the origin,
which is recorded as part of the clientData so that the origin can be verified by the server later. The parameters to
the credentialCreate call are passed to the authenticator, along with a SHA-256 hash of the clientData (only a hash
is sent because the link to the authenticator may be a low-bandwidth NFC or Bluetooth link and the authenticator
is just going to sign over the hash to ensure that it isn't tampered with).
③ Authenticator Creates New Key Pair and Attestation - Before doing anything, the authenticator will typically ask
for some form of user verification. This could be entering a PIN, using a fingerprint, doing an iris scan, etc. to prove
that the user is present and consenting to the registration. After the user verification, the authenticator will create a
new asymmetric key pair and safely store the private key for future reference. The public key will become part of the
attestation, which the authenticator will sign over with a private key that was burned into the authenticator during
its manufacturing process and that has a certificate chain that can be validated back to a root of trust.
④ Authenticator Returns Data to Client - The new public key, a globally unique credential id, and other attestation
data are returned to the client where they become the attestationObject.
⑤ Client Creates Final Data, Application sends response to Server – The authenticatorMakeCredential call returns
a PublicKeyCredential, which has a rawId that is the globally unique credential id along with a response that is
the authenticator’s attestation response containing the clientData and the attestationObject. The PublicKeyCre-
dential is sent back to the server using any desired formatting and protocol.

46 Implementation of Secure Authentication Technologies for Digital Financial Services