DEVELOPMENT.md

Development

This document gives some pointers on where to start when modifying the library for your needs.

The starting point for a user is the fido.h, which includes most of the functionality exposed to the user.

When developing new features, you may orient on the libfido2, which heavily inspired this project.

Adding a new command

For our project, we only needed a small subset of the overall available commands in CTAP 2.1 and therefore only implemented those. Nevertheless, the structure when adding a new command is fairly simple.

1. The flow starts with a function called like your commmand, fido_dev_get_assert.
2. This function can perform some input validation and finally call a wait function, fido_dev_get_assert_wait.
3. The wait function first calls the corresponding tx function to send the command to the authenticator (fido_dev_get_assert_tx) and the rx function afterward to receive the response (fido_dev_get_assert_rx).
4. The receiving function will then parse the CBOR encoded data and write the result into a stack-allocatable structure.

Adding extensions and alike

As this library is designed without heap allocations and with as few copy operations as possible, we currently do not pass the extensions received from the authenticator in the authenticatorGetInfo command to the user directly. Instead, we parse the extensions received from the authenticator into a bitfield. To enable the parsing of a new extension, add the corresponding bitfield definition in info.h, the string version at the top of the info.c and the parsing to the cbor_info_decode_extensions function.

The procedure for adding parsing support of other cryptographic algorithms, transports, etc. is similar.