openvtc-service: add secure key storage backend

[stormer78]

Summary

openvtc-service currently requires DID private key material (Ed25519/X25519) to be provided as plaintext JWK secrets directly in the JSON config file (openvtc-service/conf/config.json). These secrets are loaded at startup and injected into the TDK's SecretsResolver for signing and decrypting DIDComm messages.

This is in contrast to openvtc-cli2 / openvtc-lib, which support secure key management backends:

• BIP32 derivation from a seed stored in the OS Secure Store
• VTA-managed keys fetched remotely from the Verifiable Trust Authority

The service has no equivalent — it relies entirely on pre-provisioned plaintext secrets in the config file.

Proposed Work

Integrate the service with a secure key storage backend (VTA, OS Secure Store, or similar) so that plaintext private key material no longer needs to be present in config files. This would align openvtc-service with the security model already established in openvtc-cli2.

Relevant Files

• openvtc-service/src/config.rs — current Config struct with secrets: Vec<Secret>
• openvtc-service/src/main.rs — where config.secrets is injected into the TDK
• openvtc-lib/src/config/mod.rs — CLI2's regenerate_persona_keys() as reference for BIP32/VTA key backends

Context

Related to #18 and #19. The guard proposed in #19 to reject plaintext key material in the config would actually break the service in its current form, since the service depends on those plaintext secrets to function. This work is a prerequisite for safely enforcing that guard.

[sameerchore]

@stormer78 I would like to work on this please assign to me as I am started figuring out to resolve this issue ,happy to work on this if it's still open issue .

[stormer78]

It is more tracking for myself, the vtc-service is just a stub for now, it doesn't do anything.

[sameerchore]

It is more tracking for myself, the vtc-service is just a stub for now, it doesn't do anything.

Got it ,I’ll keep an eye on this as the service evolves. Meanwhile, I’d be happy to contribute to other areas where help is needed.

[stormer78]

Confirmed as real future work, not in scope for v0.2.0 (PR #58). Leaving open as a v0.3 tracker.

For v0.2.0, the path-translation note is:

• openvtc-service/src/config.rs — still the right pointer (file unchanged through the rename).
• openvtc-service/src/main.rs — still right.
• openvtc-lib/src/config/mod.rs — now lives at openvtc-core/src/config/mod.rs after the workspace rename in chore: release v0.2.0 #58. regenerate_persona_keys is still the right reference.

For the implementation: the cleanest path will probably be lifting openvtc-core::config::Config::create() and the BIP32/VTA backend selection logic from openvtc-core/src/config/keys.rs::regenerate_persona_keys (which now uses secrets_resolver() post-tdk-0.7), then having the service either:

• consume an already-provisioned ~/.config/openvtc/ profile via Config::load() (matching the CLI), or
• accept VTA backend config via env vars + lazy-fetch keys at sign-time (matching did-git-sign's shape).

Related #18 + #19 are already CLOSED. The plaintext-key-rejection guard from #19 will still need this work as a prerequisite before it can be enabled for the service.