Add SOG-IS and FIPS/NIST compliance

[sander]

For some use cases it is important to know if the core functions and interfaces are secured using approved cryptography standards. Common lists are the SOG-IS Agreed Cryptographic Mechanisms for the EU and the FIPS-Approved and NIST-Recommended lists for the USA.

For example, trust frameworks under public governance require this to enable standardisation, evaluation, and certification. This enables more efficient public tendering and supervision.

I suggest to add fields:

• ID:
  • cryptoComplianceSogIs13: All core functions and interface cryptography is on SOG-IS list 1.3
  • cryptoComplianceNist140cr2: All core functions and interface cryptography is on SP 800-140Cr2
  • maybe more
• Type: Yes | No

[cre8]

We need to discuss what to "be compliant" means. When my wallet supports multiple profiles, but one out of 10 is not on the NIST compliant list, my whole wallet would not be compliant.

We should discuss compliance in the future

• do all features to be compliant
• is it okay if there is at least one option compliant

[sander]

Agreed @cre8. My proposal for “core functions and interface” from the original post would be:

• pick a critical use case for wallets, e.g. issuing a credential and presenting attributes to a verifier
• identify the core cryptographic assets, e.g. the issuer key, the credential holder key, the verifier key
• identify the core cryptographic algorithms, e.g. signing the credential, connecting to the verifier, verifying the presentation
• check if these assets and algorithms are on the lists or not

If the answer is positive for at least one type of credential in the wallet/agent, we could consider it compliant, since for example government users could choose to only use this type. Solutions should not be punished from supporting additional types, e.g. more privacy-preserving or meeting a particular sector’s standards, as long as it does not compromise the security and privacy of the one compliant type.