Q1. What is the problem that you are trying to solve?
Organizations and teams often need to share secrets (passwords, credentials) with users or systems outside their Passbolt instance (e.g., partners, suppliers, external consultants). Today, this typically happens via email or other insecure channels, which undermines the end-to-end encryption guarantees of Passbolt.
Q2. Who is impacted?
– Internal users who receive secrets from external parties.
– External users/organizations who need to securely deliver secrets.
– Administrators of Passbolt instances who must manage secure sharing workflows and audit external links.
Q3. Why is it important and/or urgent?
Allowing secure cross-instance sharing is a major workflow requirement in modern organizations (MSPs, consultants, multi-tenant setups). Without it, users revert to insecure practices (email, spreadsheets, chat). This creates risk of credential leakage, audit failures, and undermines the trust in Passbolt as a secure enterprise grade secret manager.
Q4. What is your proposed solution?
As a sender in Passbolt I want to share a secret to an email address in another organisation’s Passbolt instance, so that:
-
The external recipient doesn’t have to be manually provisioned as a user in my Passbolt instance.
-
Passbolt automatically discovers the remote instance endpoint via DNS SRV.
-
A valid HTTPS/TLS certificate issued by a public CA authenticates the remote endpoint.
-
The remote instance serves public keys via WKD over the authenticated HTTPS endpoint.
-
The secret is encrypted end-to-end using the discovered public key of the recipient, and delivered via the usual Passbolt mechanism.
-
If any of the discovery/authentication steps fail (SRV missing, certificate invalid, WKD key missing/mismatched), the sharing attempt is blocked.
-
Instance admins retain control: external-sharing toggle per instance, audit logs for external shares, ability to whitelist/blacklist domains.
Q5. Community support
People can vote for this idea to show traction:
Must have: this is critical for me to have this
Should have: this is important for me to have this
Could have: this could be nice to have
Won’t have: we should not schedule this (explain why)