lumoin / verifiable Goto Github PK

https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework.

Link: https://w3c.github.io/did-test-suite/.

See more at https://github.com/Pkcs11Interop/Pkcs11Interop.

Specification and further information: https://c2pa.org/.

Once the library starts to be in usable form, it should also implement Nuget trustedSigners section.

Part of #130.

This is an explicit note to keep in mind FAPI and and related (e.g. CIBA) in general and for IoT in particular.

There are issues in offering PSD2 payments as a service eID 2, zero-knowledge proofs, SSI etc. maybe can mitigate too.

Also interesting are the EU and other sandboxes on Central Bank Digital Currencies (CBDCs). E.g. Norway:
https://github.com/nahmii
https://blog.nahmii.io/norges-bank-cbdc-sandbox-code-now-public-3afb10463731

These use cases are not the core focus of this library, or driving focus at the moment, but important nevertheless.

Using package locking would be a security and slight performance feature. This should be implemented once a good enough solution to lock files across has been determined. The issue is that Nuget package locking uses hash values to check the lock files and that the hash files vay between Windows and other plaforms. The more exact reason is described at described at NuGet/Home#9195.

Part of #130.

https://www.w3.org/TR/vc-jose-cose/
https://www.w3.org/news/2024/w3c-invites-implementations-of-securing-verifiable-credentials-using-jose-and-cose/

Since Tizen is used, it should be explicitly checked what the operating environments it is exposed to mean for Verifiable libraries. The plan is already to delegate cryptographic functionality to either libraries or the platform in discretion of the programmer, but it may be worth seeing what combination works well and test (and pre-provide) that.

A notable case here is (potential) wallet functionality.

Currently there are rough sketch of separate key material and key handling code. In the code this shows as SentitiveMemory, PublicKeyMemory, PrivateKeyMemory and related types.

For the plain key material, the idea:

1. Use type checking as rudimentary safeguard against misusing public/private key material.
2. Have a type that can include context information and information on data layout (e.g. how the key material is stored) with the raw material.
3. Have a well defined type to access the material if it is located actually in a security chip, a separate process space, remote server and so on.
4. Have a baseline to work towards key management functionality.

Some of these will be tested (e.g. TPM/security chip usage), for others such as Pkcs11Interop it may make sense to write an integration example.

Further notes and thoughts

Trying to remove the need to trust cloud providers
Quick update on Pluton and Linux
https://transparency.dev/application/strengthen-discovery-of-encryption-keys/ and at https://ioc.exchange/@matthew_d_green/109513247860625543.

Git Credential Manager Web Account Manager integration: https://github.com/GitCredentialManager/git-credential-manager/blob/main/docs/windows-broker.md, https://github.com/GitCredentialManager/git-credential-manager

https://github.com/ionescu007/tpmtool

NIST SP 800-63 Digital Identity Guidelines (Call for Comments on Initial Public Draft of Revision 4)
[Security and Privacy Controls for Information Systems and Organizations](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final]

And material related to EU Cyber Resiliency Act.

Consider explicitly supply-chain security. For example:https://github.blog/2022-04-07-slsa-3-compliance-with-github-actions/

• https://slsa.dev/
• https://www.openchainproject.org/get-started/conformance (iso.org/standard/81039.html)
• https://github.blog/2022-04-07-slsa-3-compliance-with-github-actions/
• https://github.blog/changelog/2022-05-31-improved-verification-of-historic-git-commit-signatures/

See https://github.blog/2022-05-09-supercharging-github-actions-with-job-summaries/ for further information. Consider https://github.com/test-summary/action.

Further information: https://blog.identity.foundation/cte/.

See at https://github.com/release-drafter/release-drafter. Likely a separate .yml file should be used, such as release-drafter.yml.

https://atproto.com/.

At the moment (in did:key branch) while shaping APIs some API signatures (mostly delegates) that could end up calling asynchronous operations are synchronous. It would make sense to refactor these signatures to expose only ValueTask<T>. Accompanying this, code should add IAsyncDisposable in addition IDisposable. Something to consider either after or during did:key branch.

• Non-browser targers: WASI via https://github.com/stevesandersonms/dotnet-wasi-sdk for non-browser targets (targeting browser via this may need something like https://www.npmjs.com/package/@wasmer/wasi).

• Browser targets without Blazor https://github.com/dotnet/runtimelab/blob/feature/NativeAOT-LLVM/docs/using-nativeaot/compiling.md#webassembly or maybe https://github.com/unoplatform/Uno.Wasm.Bootstrap.

• Blazor.

Here Blazor and WASM without Blazor are more important than WASI.

Some other notes

WebCrypto could mean using RSA (or ECDSA). In this case keyAgreement could mean https://datatracker.ietf.org/doc/html/rfc6101#section-6.1.1.

It may be https://w3c.github.io/webappsec/admin/webappsec-charter-2021.html will define Ed25519 (and X25519) support and browsers implement it quickly. It also appears LibSodium can be compiled to WASM.

Explicit notes:

• There should be possibility, maybe even dynamically selective, to choose either platform or library provided libraries to be used. One scenario: easy testing on some actual platform.
• Adequate testing of WASM and when using platform specific cryptograhic implementations.

See also publishing wasm files, e.g. at https://dev.to/azure/exploring-net-webassembly-with-wasi-and-wasmtime-41l5.

It is not clear what liabilities the newly proposed EU cyber security regulation brings to open source developers in general or small startups developing open source in particular. This is a placeholder issue regarding this topic.