## 3 Materials and Methods
### The FIDO2 Blockchain Framework
#### 3.1.1 FIDO2 Blockchain Register Phase  
Figure 4 depicts the registration architecture of the FIDO2 blockchain. During the registration process, the user sends a registration request to the smart contract. The smart contract sends a challenge to the authenticator. Upon receiving the challenge, the authenticator prompts the user for biometric verification and generates a new pair of keys. The authenticator signs the challenge using the private key and returns the signed challenge and public key to the smart contract for verification and storage. In this study, the ECDSA based on elliptic curve cryptography is utilized for generating new asymmetric keys. This key consists of a private key and its corresponding public key, which can be used for performing digital signatures and other related operations. Step 1. Registration request:  
When a user wants to register with the validator, the client-side initiates a registration request. During the registration process, the user's wallet address (userWalletAddress) is passed to the smart contract. Step 2. Generating PublicKeyCredentialCreationOptions:  
Upon receiving the registration request from the client-side, the smart contract generates a challenge and creates an empty object called PublicKeyCredentialCreationOptions. This object is then returned to the browser. PublicKeyCredentialCreationOptions contains information about the user, contract, and the required credential type. The User Info section  
Figure 3: Blockchain. contains relevant data about the user's account. The UserAccount within User Info can be associated with the credential by the verifier, allowing for the verification of the user's identity in future authentication attempts using the same UserAccount and verifier. The Contract Info section contains information about the organization or service responsible for registering and authenticating users. Step 3. Generating clientData:  
When the browser receives the relevant information, it verifies whether the Contract Address in the Contract Info matches the origin. If the verification is successful, then the browser generates clientData, which is a data structure containing the origin, challenge, and type, as shown in Table 6. After generating the clientData, it is hashed. The Contract Info, User Info, and clientDataHash are then passed to the verifier. Step 4. Verifying user identity:  
The authenticator will perform biometric authentication or other verification methods on the user. Once the verification is successful, the authenticator will generate a new pair of asymmetric keys. The private key is stored within the authenticator, while the public key becomes part of the attestation. The private key is then used to sign the clientDataHash and attestation. \begin{table}
\begin{tabular}{l l} \hline \hline challenge & A random value passed from the browser. \\ origin & Verification of whether the origin string matches the Contract Address. \\ type & Verification of whether the string matches “webauthn.create”. \\ \hline \hline \end{tabular}
\end{table} 
Table 6: The parameter list for clientData in FIDO2 blockchain register. Figure 4: Proposed FIDO2 blockchain register architecture diagram. Step 5. Returning attestationObject and clientData to the browser and parsing attestationObject:  
After the PublicKey, CredentialID, aaguid, and signature are generated, they are combined to form the attestationObject. The clientDataHash and attestationObject are then sent to the browser. The attestationObject is structured according to the information provided in Table 7.  
Step 6. Generating PublicKeyCredential:  
The browser parses the attestationObject received, extracting attStmt and authData. It then generates the PublicKeyCredential object and returns it to the smart contract for verification. During the registration phase, PublicKeyCredential is created using the \"publicKey\" option, allowing for the creation of a new Credential. Step 7.