Forum Discussion

tielmanleroux's avatar
tielmanleroux
New Contributor
2 months ago

Feature Request: Optionally allow sharing recipients to edit/update entries

Hi I love 1Password, cannot live without it in my personal and professional life. But one thing I struggle with is helping my customers maintain a safety first demeanor when it comes to sharing secr...
best practices
extended access management
feature request
1P_Dave's avatar
1P_Dave
Icon for Moderator rankModerator
2 months ago

Hello tielmanleroux​! 👋

Thank you for the continued feedback and for following up! Earlier this year we moved to a new community platform and threads that haven't been active in years weren't migrated. Even if a certain community thread wasn't migrated, any filed feature requests from that thread are still filed with our product team internally. 

This feature request is still open with the team but there aren't any updates to share. For the time being, inviting external users as a guest is the best option if you'd like them to share items with you using 1Password: Share with guests in your team

I've added your latest comments to the feature request that's filed with the team as well. 🙂

-Dave

PB-51190077

tielmanleroux's avatar
tielmanleroux
New Contributor
2 months ago

Thanks 1P_Dave​ 

On second thought, I guess this kind of feature could impact your bottom line, as it technically requires less people to have 1PW accounts, and or limits the use of Guest accounts. So if that is a motivating factor for your business then I completely get that.

But, like I said, this is definitely something that I would pay for, and perhaps others as well. And so, on the minute chance that the engineering team have not thought about it much, I present my AI inspired high level design (fully recognizing how presumptuous this may come across)

The goal: let a non-member (the customer) create a temporary, signed, encrypted vault item that only you can decrypt, store it in your service as a staged item, let you open it one time, verify the signature, and then have the service convert it into a normal vault entry re-encrypted under your vault keys — all without exposing plaintext to the server beyond ephemeral local decryption on your client.

High-level design (requirements)

  1. Customer can submit a secret through their browser (no account required).
  2. The secret is encrypted client-side; only the vault owner (you) can decrypt it.
  3. The submission is signed by the customer (browser key) so you can verify authenticity.
  4. The submission is stored on the server as a ciphertext blob (staged item) and kept until you accept it.
  5. When you accept, your client decrypts it locally, verifies signature, then re-encrypts and stores the permanent item in your vault under your vault encryption key.
  6. The staged blob is deleted (or zeroized) once consumed or expired.
  7. Server never sees plaintext; keys never permanently shared.

 

I will stop now :D, thanks for humoring me