♻️ use the library solidity's native type

Refacto the contract to use the solidity's native type. This will allow
more compatibility with other contracts of the ecosystem.

Author: imqdee

script/DeployWebAuthn256r1.s.sol

@@ -2,29 +2,29 @@
 pragma solidity >=0.8.19 <0.9.0;
 
 import { BaseScript } from "./BaseScript.s.sol";
-import { WebAuthn256r1 } from "../src/WebAuthn256r1.sol";
+import { WebAuthnWrapper } from "test/WebAuthnWrapper.sol";
 
 /// @notice This script deploys the ECDSA256r1 library
-contract MyScript is BaseScript {
+contract DeployScript is BaseScript {
     function run() external broadcast returns (address addr) {
         // deploy the library contract and return the address
-        addr = address(new WebAuthn256r1());
+        addr = address(new WebAuthnWrapper());
     }
 }
 
 /*
 
     ℹ️ HOW TO USE THIS SCRIPT USING A LEDGER:
-    forge script script/DeployWebAuthn.s.sol:MyScript --rpc-url <RPC_URL> --ledger --sender <ACCOUNT_ADDRESS> \
+    forge script script/DeployWebAuthn256r1.s.sol:DeployScript --rpc-url <RPC_URL> --ledger --sender <ACCOUNT_ADDRESS> \
     [--broadcast]
 
 
     ℹ️ HOW TO USE THIS SCRIPT WITH AN ARBITRARY PRIVATE KEY (NOT RECOMMENDED):
-    PRIVATE_KEY=<PRIVATE_KEY> forge script script/DeployWebAuthn.s.sol:MyScript --rpc-url <RPC_URL> [--broadcast]
+PRIVATE_KEY=<PRIVATE_KEY> forge script script/DeployWebAuthn256r1.s.sol:DeployScript --rpc-url <RPC_URL> [--broadcast]
 
 
     ℹ️ HOW TO USE THIS SCRIPT ON ANVIL IN DEFAULT MODE:
-    forge script script/DeployWebAuthn.s.sol:MyScript --rpc-url http://127.0.0.1:8545 --broadcast --sender \
+    forge script script/DeployWebAuthn256r1.s.sol:DeployScript --rpc-url http://127.0.0.1:8545 --broadcast --sender \
     0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 --mnemonics "test test test test test test test test test test test junk"
 
 

src/WebAuthn256r1.sol

@@ -2,12 +2,114 @@
 pragma solidity >=0.8.19 <0.9.0;
 
 import { ECDSA256r1 } from "../lib/secp256r1-verify/src/ECDSA256r1.sol";
-import { WebAuthnBase } from "./WebAuthnBase.sol";
+import { Base64 } from "../lib/solady/src/utils/Base64.sol";
 
 /// @title WebAuthn256r1
 /// @notice A library to verify ECDSA signature though WebAuthn on the secp256r1 curve
 /// @custom:experimental This is an experimental library.
-contract WebAuthn256r1 is WebAuthnBase {
+library WebAuthn256r1 {
+    error InvalidAuthenticatorData();
+    error InvalidClientData();
+    error InvalidChallenge();
+
+    /// @notice Validate the webauthn data and generate the signature message needed to recover
+    /// @param authenticatorDataFlagMask This is a bit mask that will be used to validate the flag in the
+    ///                                  authenticator data. The flag is located at byte 32 of the authenticator
+    ///                                  data and is used to indicate, among other things, wheter the user's
+    ///                                  presence/verification ceremonies have been performed.
+    ///                                  This argument is not expected to be exposed to the end user, it is the
+    ///                                  responsibility of the caller to enforce the value of the flag for their flows.
+    ///
+    ///                                  Here are some flags you may want to use depending on your needs.
+    ///                                  - 0x01: User presence (UP) is required. If the UP flag is not set, revert
+    ///                                  - 0x04: User verification (UV) is required. If the UV flag is not set, revert
+    ///                                  - 0x05: UV and UP are both accepted. If none of them is set, revert
+    ///
+    //                                  Read more about UP here: https://www.w3.org/TR/webauthn-2/#test-of-user-presence
+    //                                  Read more about UV here: https://www.w3.org/TR/webauthn-2/#user-verification
+    /// @param authenticatorData The authenticator data structure encodes contextual bindings made by the authenticator.
+    ///                          Described here: https://www.w3.org/TR/webauthn-2/#authenticator-data
+    /// @param clientData      This is the client data that was signed. The client data represents the
+    ///                        contextual bindings of both the WebAuthn Relying Party and the client.
+    ///                        Described here: https://www.w3.org/TR/webauthn-2/#client-data
+    /// @param clientChallenge This is the challenge that was sent to the client to sign. It is
+    ///                        part of the client data. In a classic non-EVM flow, this challenge
+    ///                        is generated by the server and sent to the client to avoid replay
+    ///                        attack. In our context, as we already have the nonce for this purpose
+    ///                        we use this field to pass the arbitrary execution order.
+    ///                        This value is expected to not be encoded in Base64, the encoding is done
+    ///                        during the verification.
+    /// @param clientChallengeOffset The offset of the client challenge in the client data
+    /// @return message The signature message needed to recover
+    /// @dev 1. The signature counter is not checked in this implementation because
+    ///         we already have the nonce on-chain to prevent the anti-replay attack.
+    ///         The counter is 4-bytes long and it is located at bytes 33 of the authenticator data.
+    ///      2. The RP.ID is not checked in this implementation as it is impossible to generate
+    ///         the same keys for different RP.IDs with a well formed authenticator. The hash of the id
+    ///         is 32-bytes long and it is located at bytes 0 of the authenticator data.
+    ///      3. The length of the authenticator data is not fixed. It is at least 37 bytes
+    ///         (rpIdHash (32) + flags (1) + counter (4)) but it can be longer if there is an
+    ///         attested credential data and/or some extensions data. As we do not consider
+    ///         the counter in this implementation, we only require the authenticator data to be
+    ///         at least 32 bytes long in order to save some calldata gas.
+    ///      4. You may probably ask why we encode the challenge in base64 on-chain instead of
+    ///         of sending it already encoded to save some gas. This library is opinionated and
+    ///         it assumes that it is used in the context of Account Abstraction. In this context,
+    ///         valuable informations required to proceed the transaction will be stored in the
+    ///         challenge meaning we need the challenge in clear to use it later in the flow.
+    ///         That's why we decided to add an extra encoding step during the validation.
+    ///      5. It is assumed this is not the responsibility of this contract to check the value
+    ///         of the `alg` parameter. It is expected this contract will be extended by another
+    ///         contract that will redirect the message produced by this contract to the right
+    ///         recovery function.
+    ///      6. Both extension data and attested credential data are out of scope of this implementation.
+    ///      7. It is not the responsibility of this contract to validate the attestation statement formats
+    ///
+    ///         This contract is based on the level 2 of the WebAuthn specification.
+    ///         and until proven otherwise compliant with the level 3 of the specification.
+    function generateMessage(
+        bytes1 authenticatorDataFlagMask,
+        bytes calldata authenticatorData,
+        bytes calldata clientData,
+        bytes calldata clientChallenge,
+        uint256 clientChallengeOffset
+    )
+        internal
+        pure
+        returns (bytes32 message)
+    {
+        unchecked {
+            // Let the caller check the value of the flag in the authenticator data
+            // @dev: we don't need to manually check the length of the authenticator data
+            //       here as the EVM will automatically revert if the length is lower than 32
+            if ((authenticatorData[32] & authenticatorDataFlagMask) == 0) {
+                revert InvalidAuthenticatorData();
+            }
+
+            // Ensure the client challenge is not null
+            if (clientChallenge.length == 0) revert InvalidChallenge();
+
+            // Encode the client challenge in base64 and explicitly convert it to bytes
+            bytes memory challengeEncoded = bytes(Base64.encode(clientChallenge, true, true));
+
+            // Extract the challenge from the client data and hash it
+            // @dev: we don't need to check the overflow here as the EVM will automatically revert if
+            //       `clientChallengeOffset + challengeEncoded.length` overflow. This is because we will
+            //       try to access a chunk of memory by passing an end index lower than the start index
+            bytes32 challengeHashed =
+                keccak256(clientData[clientChallengeOffset:(clientChallengeOffset + challengeEncoded.length)]);
+
+            // Hash the encoded challenge and check both challenges are equal
+            if (keccak256(challengeEncoded) != challengeHashed) {
+                revert InvalidClientData();
+            }
+
+            // Craft the signature message by hashing the client data, then concatenating
+            // it to the authenticator data without padding, before hashing the result
+            message = sha256(abi.encodePacked(authenticatorData, sha256(clientData)));
+        }
+    }
+
     /// @notice Verify ECDSA signature though WebAuthn on the secp256r1 curve
     function verify(
         bytes1 authenticatorDataFlagMask,
@@ -20,7 +122,7 @@ contract WebAuthn256r1 is WebAuthnBase {
         uint256 qx,
         uint256 qy
     )
-        external
+        internal
         returns (bool)
     {
         unchecked {