docs: extract specific method from general intro, add UAF method

README.md

@@ -47,67 +47,10 @@ If anyone suspects compromise or corruption, they can easily investigate and mak
 
 This empowers users with cryptographic proof.
 
-## Two ways to achieve SCAL3
+## Three ways to achieve SCAL3
 
-1. Using the [SECDSA](https://eprint.iacr.org/2021/910) [technology](https://www.cs.ru.nl/E.Verheul/presentations/SECDSA%20Assissted%20Wallet%200.31.pdf). This technology is based on algorithms that were invented in 2021 and patented by Eric Verheul. Users verify evidence by applying homomorphic encryption.
-2. The method presented below. With this SCAL3 solution, users verify evidence using open standard ECDSA and ECSDSA signature verification.
+1. Using the [SCAL3 with UAF](docs/schemes/uaf.md) scheme. This involves using a dedicated multi-factor cryptographic device, such as a FIDO security key supporting UAF.
+2. Using the [SECDSA](https://eprint.iacr.org/2021/910) [technology](https://www.cs.ru.nl/E.Verheul/presentations/SECDSA%20Assissted%20Wallet%200.31.pdf). This technology is based on algorithms that were invented in 2021 and patented by Eric Verheul. Users verify evidence by applying homomorphic encryption.
+3. Using the [SCAL3 with Thresholds](docs/schemes/thresholds.md) scheme. With this patent pending solution, users verify evidence using open standard ECDSA and ECSDSA signature verification.
 
-In 2023, [Cleverbase](https://cleverbase.com/en/) experimented with both solutions. In 2024, the [Vidua](https://vidua.nl/english/) identity wallet is rolling out solution 2 to its users. By enabling verification using open standards, this method makes it easy for users to verify the tamper-evident logs.
-
-## How it works
-
-> [!NOTE]
-> Patent NL2037022 pending. For inquiries, [contact Cleverbase](mailto:[email protected]).
-
-Upon enrolment, the central system provider issues a certificate with two authentication factors:
-
-- 🔑 Something you have: an ECDSA key bound to a device.
-- 💭 Something you know or are: a PIN code or biometry-protected data.
-
-The second factor is protected using [Shamir’s secret sharing](https://dl.acm.org/doi/10.1145/359168.359176) technique. The certificate enables verification by protecting:
-
-- 🫱 A secret share encrypted using the second authentication factor.
-- 🫲 A secret share encrypted with a user-specific key only known to the provider.
-- 🤝 A verification key enabling ECSDSA signature verification using both secret shares.
-
-Subscribers generate instructions and providers prove them using an innovative method combining:
-
-- Multi-party computation of signatures proving the second factor
-- Digital signatures proving possession of the enrolled device
-- Digital signatures binding the two authentication factors
-
-Using the certificate, anyone can verify a proof of multi-factor authentication using open standards from the [SOG-IS Agreed Cryptographic Mechanisms v1.3](https://www.sogis.eu/uk/supporting_doc_en.html).
-
-## Technical details
-
-### Tamper-evident log record format
-
-Each tamper-evident log record is based on an ephemeral ECDSA key pair `(binding_sk, binding_vk)` generated on the user’s device. It contains an ECSDSA signature proving the second authentication factor using [FROST](https://eprint.iacr.org/2020/852) two-round threshold signing.
-
-```
-<message> || <user_sig> || <checksum> || <device_sig> || <binding_sig>
-```
-
-- `message`: `<binding_vk> || <log metadata> || <instruction>`
-- `user_sig`: `ecsdsa(<message>)` represented as `c || z`
-- `checksum`: `sha256(<user signature share>)`
-- `device_sig`: `ecdsa(<c> || <checksum>)` created with `device_sk`
-- `binding_sig`: `ecdsa(<device_sig>)` created with `binding_sk`
-
-### Authentication protocol
-
-1. Provider commits in FROST.
-2. Provider shares its commitments with Subscriber in a challenge.
-3. Subscriber commits in FROST, completing the first FROST round.
-4. Subscriber generates `(binding_sk, binding_vk)`.
-5. Subscriber forms the `message` to sign.
-6. Subscriber signs in FROST to create `c` and `user signature share`.
-7. Subscriber computes the hash digest `checksum`.
-7. Subscriber creates the device signature `device_sig`.
-8. Subscriber creates the binding signature `binding_sig`.
-9. Subscriber destroys `binding_sk`.
-10. Subscriber responds to Provider with the results.
-11. Provider validates the input and verifies the signatures.
-12. Provider signs in FROST, completing the second FROST round.
-13. Provider aggregates the `user_sig` in FROST.
-14. Provider writes the record to the tamper-evident log.
+In 2023, [Cleverbase](https://cleverbase.com/en/) experimented with all three solutions. In 2024, the [Vidua](https://vidua.nl/english/) identity wallet is rolling out solution 3 to its users. By enabling verification using open standards, this method makes it easy for users to verify the tamper-evident logs.

docs/schemes/thresholds.md

@@ -0,0 +1,66 @@
+# SCAL3 with Thresholds
+
+**Author:** [Sander Dijkhuis](mailto:[email protected]) ([Cleverbase](https://cleverbase.com/en/)) \
+**License:** [Creative Commons Attribution-NonCommercial 4.0 International](https://creativecommons.org/licenses/by-nc/4.0/)
+
+This document introduces the SCAL3 with Thresholds scheme, a scheme to meet the [SCAL3 requirements](../../README.md) based on threshold signing between the subscriber and the provider. With this solution, users verify evidence using open standard ECDSA and ECSDSA signature verification.
+
+> [!NOTE]
+> Patent NL2037022 pending. For inquiries, [contact Cleverbase](mailto:[email protected]).
+
+For a prototype with more in-depth documentation, see the [scal3 crate docs](https://docs.rs/scal3/latest/scal3/).
+
+## How it works
+
+Upon enrolment, the central system provider issues a certificate with two authentication factors:
+
+- 🔑 Something you have: an ECDSA key bound to a device.
+- 💭 Something you know or are: a PIN code or biometry-protected data.
+
+The second factor is protected using [Shamir’s secret sharing](https://dl.acm.org/doi/10.1145/359168.359176) technique. The certificate enables verification by protecting:
+
+- 🫱 A secret share encrypted using the second authentication factor.
+- 🫲 A secret share encrypted with a user-specific key only known to the provider.
+- 🤝 A verification key enabling ECSDSA signature verification using both secret shares.
+
+Subscribers generate instructions and providers prove them using an innovative method combining:
+
+- Multi-party computation of signatures proving the second factor
+- Digital signatures proving possession of the enrolled device
+- Digital signatures binding the two authentication factors
+
+Using the certificate, anyone can verify a proof of multi-factor authentication using open standards from the [SOG-IS Agreed Cryptographic Mechanisms v1.3](https://www.sogis.eu/uk/supporting_doc_en.html).
+
+## Technical details
+
+### Tamper-evident log record format
+
+Each tamper-evident log record is based on an ephemeral ECDSA key pair `(binding_sk, binding_vk)` generated on the user’s device. It contains an ECSDSA signature proving the second authentication factor using [FROST](https://eprint.iacr.org/2020/852) two-round threshold signing.
+
+```
+<message> || <user_sig> || <checksum> || <device_sig> || <binding_sig>
+```
+
+- `message`: `<binding_vk> || <log metadata> || <instruction>`
+- `user_sig`: `ecsdsa(<message>)` represented as `c || z`
+- `checksum`: `sha256(<user signature share>)`
+- `device_sig`: `ecdsa(<c> || <checksum>)` created with `device_sk`
+- `binding_sig`: `ecdsa(<device_sig>)` created with `binding_sk`
+
+### Authentication protocol
+
+1. Provider commits in FROST.
+2. Provider shares its commitments with Subscriber in a challenge.
+3. Subscriber commits in FROST, completing the first FROST round.
+4. Subscriber generates `(binding_sk, binding_vk)`.
+5. Subscriber forms the `message` to sign.
+6. Subscriber signs in FROST to create `c` and `user signature share`.
+7. Subscriber computes the hash digest `checksum`.
+7. Subscriber creates the device signature `device_sig`.
+8. Subscriber creates the binding signature `binding_sig`.
+9. Subscriber destroys `binding_sk`.
+10. Subscriber responds to Provider with the results.
+11. Provider validates the input and verifies the signatures.
+12. Provider signs in FROST, completing the second FROST round.
+13. Provider aggregates the `user_sig` in FROST.
+14. Provider writes the record to the tamper-evident log.

docs/schemes/uaf.md

@@ -0,0 +1,56 @@
+# SCAL3 with UAF
+
+**Author:** [Sander Dijkhuis](mailto:[email protected]) ([Cleverbase](https://cleverbase.com/en/)) \
+**License:** [Creative Commons Attribution 4.0 International](https://creativecommons.org/licenses/by/4.0/)
+
+This document introduces the SCAL3 with UAF scheme, a scheme to meet the [SCAL3 requirements](../../README.md) based on the [FIDO Universal Authentication Framework](https://fidoalliance.org/specifications-overview/). With this solution, subscribers can deploy a FIDO UAF authenticator, such as a [YubiKey](https://en.wikipedia.org/wiki/YubiKey), as a [Multi-Factor Cryptographic Device](https://pages.nist.gov/800-63-3/sp800-63b.html#mfcd).
+
+To map terminology from the [SCAL3 introduction](../../README.md):
+
+- **device**: a UAF authenticator
+- **subscriber**: user interacting with the device using a CTAP2 client, enrolling with a local authentication mechanism such as PIN verification
+- **tamper-evident log**: a transparency log or *tlog*
+- **central system**: typically is a HSM-backed service for managing encryption and/or signing keys for the subscriber
+
+## Technical details
+
+### Log record format
+
+Each tlog record is based on an authenticator assertion based on client data. This specification assumes that the authenticator signs using an ECDSA key pair that was attested to the provider during enrollment.
+
+```
+<number> || <timestamp> || <nonce> || <authenticator> || <signature> || <instruction>
+```
+
+- `number`: log sequence number, maintained between subscriber and provider (4 bytes, see below)
+- `timestamp`: timestamp generated by the provider (8 bytes)
+- `nonce`: random challenge number to be used once, generated by the provider (8 bytes)
+- `authenticator`: authenticator data as per CTAP2
+- `signature`: authenticator assertion `ecdsa(<authenticator> || sha256(<client_data>))` as per CTAP2
+  - `client_data`: `<key> || <timestamp> || <nonce> || <instruction>`
+- `instruction`: HSM-backed key management instruction, generated by the subscriber
+
+### Log sequence number
+
+The 4-byte log sequence `number` is a big-endian encoded strictly increasing number starting at 0 upon enrollment of a subscriber.
+
+Using these numbers, the subscriber and provider can verify integrity of the protected tlog.
+
+Optionally, the numbers may be encrypted in such a way that the subscriber can share records without disclosing the amount of previously recorded instructions.
+
+### Authentication protocol
+
+1. Provider determines `key` and `timestamp`.
+2. Provider generates `nonce`.
+3. Provider shares `key`, `timestamp` and `nonce` with Subscriber in a challenge.
+4. Subscriber determines `instruction` and `client_data`.
+5. Subscriber creates `authenticator` and `signature` using their authenticator.
+6. Subscriber responds to Provider with the results.
+7. Provider validates the input and verifies the signatures.
+8. Provider writes the record to the protected tlog.
+
+After successful authentication and subsequent authorization, Provider executes `instruction` and returns the result.
+
+## Acknowledgements
+
+The usage of a log sequence number shared between the subscriber and provider is inspired by the [NL Wallet Solution Architecture v1.0.3 draft](https://edi.pleio.nl/files/view/dc585f22-ca66-4892-87c5-c7bdb2dd69b4/nlw-solution-architecture-sad-v1.pdf) by [MinBZK](https://github.com/MinBZK).