Add sole control assurance level

[sander]

For some use cases it is important to know to what extent the wallet or agent operates on holder keys under sole control of an authorized end-user. This knowledge can be provided with more or less assurance. Two assurance levels are standardised under Common Criteria in the CEN EN 419241-2:2019 standard on trustworthy systems supporting server signing. The SCAL3 project provides an overview and an extension applicable to wallets.

For example, wallets for eIDAS LoA High authentication or other high-risk transactions will need to provide a high assurance level, while wallets for webshop coupons or intranet authentication may do with lower levels.

I suggest to add a field:

• ID: scal (sole control assurance level)
• Type: 1 | 2 | 3 where:
  • 1 indicates that the wallet/agent authenticates the user before operating on a key (e.g. signing a credential presentation)
  • 2 indicates that the wallet/agent requires multi-factor authentication, and a cryptographic link between the authenticators and the instruction for the key operation
  • 3 indicates that the wallet/agent enables authorised users to verify tamper-evident logs of this cryptographic evidence

[maaikevanleuken]

Maximum level of assurance, not the assurance level for each individual.

Can we place objective trust in the assessor of these levels? We can't work with patents in this publicly available resource.

Interesting related characteristic: holder authentication to wallet.

[sander]

Thanks @maaikevanleuken for taking a look. Responding to your notes:

Maximum level of assurance, not the assurance level for each individual.

Agreed, individual users can configure/break the system to use reduced security.

Can we place objective trust in the assessor of these levels?

I suggest to use the SCAL quality criteria as written in my first post. As with other characteristics, we can go with the supplier’s self-assessment and publications and verify it with our own experiences:

• SCAL1 is easy to recognise, if users notice it doesn’t matter on which device they enter their password
• SCAL3 is easy to recognise, if users can access the tamper-evident logs and verify it with a published spec

Only SCAL2 may be more tricky. For example, I know one solution that has used a TPM assessment from a Register EDP auditor to demonstrate SCAL2 compliance.

We can't work with patents in this publicly available resource.

What is exactly the constraint in this context? The general idea of tamper-evident logs with cryptographic evidence of multi-factor authentication seems hard to claim in a patent. If you want to refer to the SCAL3 docs without any sections that cover patented designs, I can work on separating these.

Interesting related characteristic: holder authentication to wallet.

In my view this is the same characteristics. The SCALs concretise what qualities we could measure to describe holder authentication.