Proposal: Share an existing Login item as a structured temporary Send link

[joeeeeey]

Summary

I would like to propose a narrowly scoped web-vault feature: create a temporary,
structured sharing link directly from an existing Login item, while reusing the
current encrypted Text Send transport and all existing Send access controls.

This is related to Password Sharing Features?
and Possibility of internal exchange of login data,
but it is intentionally not a proposal for live item sharing, recipient vault
membership, or organization-less synchronization. It is an immutable snapshot for
an external link, similar to preparing a Text Send, without manually copying each
credential field.

Before implementing this, I would like maintainer feedback on whether the direction
fits Vaultwarden and where the client changes should live.

Problem

Today, a user who wants to share an existing credential by link has to:

1. Open the Login item.
2. Copy the username, password, URI, and any custom fields manually.
3. Create a Text Send and assemble those values into unstructured text.
4. Explain the field meanings to the recipient.

The existing Send security and lifecycle controls are useful, but the manual
conversion loses field semantics and makes accidental omission or over-sharing more
likely.

The proposed user flow is:

1. Choose Share link from an existing Login item.
2. Explicitly select the fields allowed to leave the vault.
3. Configure the existing Send restrictions.
4. Create the link.
5. Render a valid structured payload as credential fields on the public Send page.

The screenshots below are a design proposal, not implemented functionality.

Proposed sender entry point.

Proposed field selection and sensitivity disclosure.

Proposed access settings using existing Send controls.

Proposed structured recipient view on desktop.

Proposed structured recipient view on mobile.

Proposed v1 architecture

No Vaultwarden server, API, or database schema change is required for v1.

decrypted CipherView in the sender client
  -> explicit allowed-field selection
  -> versioned StructuredItemShareV1 JSON
  -> existing encrypted Text Send
  -> existing Send API and database
  -> public web client decrypts the Text Send
       valid v1 payload -> structured credential renderer
       otherwise        -> existing Text Send renderer

The server continues to store only the current encrypted Send fields and does not
interpret credential values or the structured envelope.

An abbreviated payload would look like this:

{
  "schema": "vaultwarden.item-share",
  "version": 1,
  "itemType": "login",
  "snapshotCreatedAt": "2026-07-15T10:00:00.000Z",
  "fields": [
    {
      "id": "username-1",
      "kind": "username",
      "label": "Username",
      "value": "user@example.invalid",
      "sensitive": false,
      "copyable": true
    },
    {
      "id": "password-1",
      "kind": "password",
      "label": "Password",
      "value": "not-a-real-secret",
      "sensitive": true,
      "copyable": true
    }
  ]
}

Suggested v1 limits:

• Login items only.
• UTF-8 JSON object, maximum 64 KiB.
• 1 to 32 fields with unique IDs.
• Known field kinds only: username, password, url, text, and hidden.
• Values are always rendered as text, never HTML.
• URL actions are enabled only for parsed http: or https: URLs.
• Any malformed, oversized, unknown, or unsupported payload uses the legacy Text
  Send renderer without throwing.

Field and permission boundaries

Default selected fields:

• username;
• password, only when viewPassword permits it;
• first Login URI;
• visible custom text fields.

Explicitly available but not selected by default:

• notes;
• additional Login URIs;
• custom hidden fields, only when the sender can view passwords.

Excluded from v1:

• TOTP seeds and current codes;
• passkeys/FIDO2 credentials;
• attachments;
• password history;
• source cipher, folder, collection, organization, and user IDs;
• Card, Identity, Secure Note, and SSH Key items.

Sensitive snapshot creation should use the existing user-verification or item
re-prompt path. Canceling or failing verification must create no Send.

DisableSend, SendOptions, viewPassword, password-gated access, deletion and
expiration dates, disabled state, and maximum access count remain authoritative.
This feature does not allow a Vaultwarden administrator to decrypt another user's
personal vault.

It does make externalization easier for a user who already has both field access and
Send access. Organizations that prohibit external sharing should continue to
enforce DisableSend.

Lifecycle and defaults

The link contains a one-time snapshot:

• Editing or rotating the source item does not update the Send.
• Deleting the source item does not revoke the Send.
• Deleting, disabling, expiring, or exhausting the Send makes the link unavailable
  through existing behavior.

Suggested defaults are one day, one view, and sensitive values hidden. The recipient
view should display snapshot time and expiration so the non-synchronized lifecycle
is explicit.

Compatibility limitation

The main v1 risk is cross-client behavior. An unmodified client can treat the
payload as an ordinary hidden Text Send and reveal raw JSON. Setting
SendView.text.hidden = true reduces accidental exposure, but does not make this a
good experience outside the modified public web client.

I do not want to hide this limitation. Maintainer guidance is needed on whether:

• web-vault-only support is acceptable for a first version;
• a different backwards-compatible representation is required; or
• this should wait for an upstream Bitwarden client feature.

Likely implementation areas

Using the current Vaultwarden web-vault fork, the change appears to be concentrated
in:

• libs/vault/src/vault-item-dialog/
  for the sender entry point;
• a focused serializer/parser module with unit tests;
• apps/web/src/app/tools/send/send-access/
  for the structured recipient renderer and legacy fallback;
• the existing
  SendService
  and Send form configuration, without changing their encryption or policy roles.

Required tests would cover the allowlist, permission gates, exclusion of TOTP and
passkey data, verification cancellation, strict parser limits, text-only rendering,
safe URL protocols, legacy fallback, existing Send lifecycle states, keyboard
operation, and desktop/mobile reflow.

Questions for maintainers

1. Is this snapshot-over-Send approach within Vaultwarden's intended scope, or is it
   too large a client deviation?
2. If the direction is acceptable, should the implementation target
   vaultwarden/vw_web_builds, dani-garcia/bw_web_builds, or first be proposed to
   upstream Bitwarden clients?
3. Is raw JSON in unmodified clients an acceptable v1 compatibility boundary, or
   should the payload format provide a readable legacy representation?
4. Would maintainers be willing to review a focused PR after the payload and
   repository ownership are agreed here?

I can prepare the implementation and tests after receiving direction on these
questions.

[BlackDex]

Looks like a nice mockup, but this project does not develop or maintain any client, including the web-vault.

https://github.com/dani-garcia/vaultwarden/wiki/FAQs#i-have-a-feature-request-for-the-web-vault-or-any-other-client

[joeeeeey]

Thanks for clarifying, and for pointing me to the FAQ. I understand that Vaultwarden intentionally does not develop or maintain client-side features, including web-vault-only additions, so I will not open an implementation PR in this project.

Our immediate use case is an enterprise deployment that relies only on the web vault, but I understand that this would still be a downstream client customization rather than a Vaultwarden server feature. I will evaluate proposing it upstream to Bitwarden or maintaining it explicitly as an internal downstream customization.

[pamperer562580892423]

@joeeeeey By chance I saw this comment from BW in a related community PR - seems to me like they are working on something similar: bitwarden/clients#20575 (comment)