Self-Custodial Public Key Signing for Sensitive Messages

[mattsmithies]

Problem description

Currently, our system requires users to input sensitive private keys or DID keys, as well as offering a new option for Fireblocks. This creates a risk where a Guardian’s email/password-based or traditional web2 approach could be exploited by a rogue actor through brute force attacks or standard registry manipulation. Such an actor could change passwords and access accounts to trigger sensitive actions using these keys.

In practical terms, if a bad actor gains access to an account, such as that of a verifier or VVB, they could fraudulently sign off on the issuance of credits, leading to potential fraud.

As a community, we recognize the necessity of moving towards a self-custodial identity management system that can track identity across different Guardian instances, and more importantly, reduce the risk of potential fraudulent assets.

Envisaging longer-term, beyond the scope of this ticket, consider that a VVB assigned a credential from a registry like Verra should be able to enact authority across multiple systems, Guardian or otherwise. Furthermore, with the revocation of such credentials, there could be downstream effects detectable by every Guardian instance. (We should discuss whether this should be a separate service outside of Guardian or inside.)

The pressing question is: How do we take the first steps towards a world where identity is managed in a more self-custodial fashion, particularly concerning the signing of high-risk credentials in legal and financial contexts?

Currently, Fireblocks operates as a unit, automating signing through their system. We propose providing Fireblocks-like behavior as a custom service/interface, where users can simply provide their public key through a third-party intermediary, potentially mitigating the web2 security issue described above.

When describing a user in this context, it includes "systems" built on top of Guardian to manage the entire process (e.g., DOVU, Tolam) for a user, thus relieving them of the complexities of registration and other processes.

For instance, DOVU has integrated wallets into various systems, one being Magic Link which uses an email-based approach for wallet creation and management, seamlessly integrating with our onboarding platforms. This has downstream implications of supporting signature signing in a "more" self-custodial fashion for parties/individuals in more rural parts of the world, like the deep south.

The application of this would not be limited to a single wallet. It would enable any wallet to sign off on their particular authority at a specific stage within a policy.

Points to Confirm/Discuss

While I don't have a full in-depth understanding of the internals of the Guardian compared to Envision, considering the Hedera did-js-sdk, there is the ability to generate DIDs through a public key.

Would it be possible to add the ability to simply use someone's public key and adopt a similar method/approach to how Fireblocks works, but in a generic fashion?

Alternatively, could the submission of a signature from a particular private key outside of the Guardian simply formulate all the required details as an "interfaceDocumentsSourceBlock" or "requestVcDocumentBlock" POST method?

Additionally, would it be possible to ensure that the signature matches the public key expectation directly on the Guardian, so that it serves as the final line of defense before committing to IPFS/HCS?

There is much to discuss regarding the longer-term understanding of identity management. While I am open to all these discussions, the aim here is to craft the first step forward to unlock and derisk any actor using the Guardian itself.

[mattsmithies]

@AlexIvanHoward @CyndyMo @Neurone @prernaadev01 @anvabr

Please tag others as appropriate.

[prernaadev01]

@mattsmithies Thank you so much for the ticket.

[dubgeis]

@prernaadev01 can you please ensure this is on the prioritization list or incorporated in another ticket that works for @mattsmithies and team

[prernaadev01]

@dubgeis We have already added this in our next phase roadmap prioritization list.