Share single passwords

AGAlumB

@Bjdavis22: Thanks for your reply! It's always good to have a different perspective. And I enjoyed reading Rick's too, as he's coming from the angle of a team manager (sorry, @rickfillion! :lol: ) making sure everyone he's working with on building the 1Password.com service has what they need to collaborate during development. So I think he makes a good point about auditing and decision making.

I'll go one step further though, and hopefully pose a useful question here: For a while, I've been thinking, "What's the difference between sharing a vault with a single item, and sharing a single item?" (Sort of a rhetorical question for now.) From a technical perspective, it's much clearer because of how 1Password works. I think all of us here in this discussion have touched on different aspect of that, sort of like the old story about the blind men and the elephant: they're all experiencing the same thing, but perceive it differently. For users, it's less clear. (Users should be, I think, "blind" to the technical aspects in the sense that they shouldn't have to care how it works so long as it does — unless they want to, of course.)

So I guess the question I have for you is, how do you conceptualize sharing an individual item could be more convenient for you? Put another way, what's the workflow you imagine for that? Try as I might, it seem to me that it ends up being essentially the same as the sharing options we have now, as far as the work you need to do: You still need to select what you want to share and who you want to share it with, which is pretty much how sharing a vault works today:

1. View vault properties
2. Edit permissions
3. Grant someone access

If we look at sharing an item (beta), it's very similar:

1. View item details
2. Select the share option
3. Choose the recipient

The hypothetical "share item"?

1. View item details
2. Edit permissions
3. Grant someone access

Sort of a hybrid of the two, based on the discussion so far. So it seems to me that it's more a matter of UI: it just happens that we've chosen "vault" as a secure container within 1Password that can be shared. What if there were just a shortcut to "Create new shared vault with this item"? I realize that isn't exactly what people are asking for here...but if we were sneaky about it and simply called it "Share this item with..." (you could select multiple people to grant access), created a new vault behind the scenes with access for the people you chose, and if we hid the "vault" aspect of it in the UI I don't think anyone would be the wiser. At that point, what's the difference? It really seems to come down to presentation for some people, otherwise we already have that feature. ;)

As Rick mentioned, no matter what, you still have to keep track of what is shared with whom, and I find that to be the real challenge regardless of what method is used or how it's presented. I doubt I use either current sharing option as extensively as he does, but I find it is much easier to keep track of and manage a shared vault than a shared item. But that's just me. Interested to hear your take on this. :)

Luca87

Any update on this? Unfortunately we are considering leaving 1password for the lack of this feature. And that's really a pity since we love the product.

AGAlumB

I'm not sure I understand. Did you try the item sharing feature? We'd love to hear from you at business@1password.com if you have specific feedback about your particular workflow. :)

mikecg

Hi Rick,

I am in the same situation as other people in this thread. For example, I have created vaults structured around different teams, ie: (Tech Admin, Developers, Finance). The Developers vault contains all passwords necessary for the dev team. Now I have a contractor who is coming on board, and only needs access to the subset of dev team passwords appropriate for his limited scope of work. I have no way to share those few passwords with him from the vault, unless I create a new vault (very impractical) or send him a copy (which will not sync, and so is difficult to manage).

I really love 1Password, but I don't know how to scale with this rigid sharing system in place.

Ben

Hey @mikecg.

I think what I would probably do in that case is create a "development-contractors" vault (or similar), giving access to everyone in the developers group as well as this contractor. How would you prefer to see it work?

Ben

GeekSpeak411

1Password is more intuitive than lastpass which is a great start, but lacking this feature is a nonstarter as a recommendation as an IT business serving business customers. Having two-way sync of shared items is a must for every single one of our clients using a password manager.

If you have to create invisible child vaults to make this happen within your architecture the so be it, get it done. We shouldn't have to see any of that for it to work. Just attach a child vault to the vault the item currently resides in and keep them synced within the parent account. Share the child vault with the guest user. Boom, you're done.

Ben

Hi @GeekSpeak411

Could you please elaborate a bit about how the currently available tools in 1Password are not meeting these goals? In what way are you currently using vaults that prevents you from having "two-way sync"?

Ben

GeekSpeak411

In LastPass, we are able to put a credential in a shared vault for staff which 1Password also is capable of. When a contractor comes on board however, a specific login that they need can be shared with them independant of the rest of the vault which they are not authorized to access. The contractor may be with the team for months, or a couple years. As the password gets updated by staff, the contractor continues to have the correct login up until the point that their share is removed, at which point only the staff remain to have access. No extra vaults to think about, and no updating a dozen vaults when you update or change a password.

This functionality could be replicated in the 1Password ecosystem with a nested “child” vault. When the parent item is updated, the child item could be updated automatically. No user in their right mind wants to create non-synced duplicates for the same account across dozens of vaults. If the password gets updated for any reason, everyone needs to have that updated information. And when it is time for someone to no longer have access, it needs to be simple to remove that persons access by removing the share. Then you can change the password so that person can no longer log in with the credentials they had, and have that updated password is synced to everyone who continues to be authorized.

A specific example: There are times when a lower level employee such as a paralegal needs to file documents that are above their access level let’s say on a legal drive. Their attorney needs the ability to grant them access to that specific account they will be working with and nothing else for the course of that project, let’s say it will take a week. Now lets say that 2 days after that access was granted (In 1Password this means creating a trunkated share), IT is scheduled to routinely update that password.

Here’s what plays out with 1Password: The password gets updated, the boss automatically gets the updated password since they are in that vault, and the employee is now locked out of that folder, and cannot do their work, wasting their time and therefore money the business is paying them to do nothing. They go to their boss, their boss got an updated password automatically so they have no idea why their employee didn’t also get updated so assumes the password manager is broken. They then waste time and therefore money calling IT thinking something is broken, and IT has to explain how the item can only be synced to a single vault and instead has to be reshared to the employee tasked with their project possibly creating a duplicate for the employee who will never know which one is the new one and which is the old one. This benign problem has now involved at LEAST three people, two of which are very expensive people, and all of whom already have full workloads. Add on to this the fact that competitors such as LastPass would have avoided this issue entirely and you’ve now lost an hour the attorney should have been billing, you’ve gotten them billed an hour from IT, and you’ve wasted an hour of the paralegal being unable to access their work. That’s hundreds of dollars right there folks and that’s just one time happening.

Your solution is instead of having this be a one step process, they currently need to instead go through the following steps:
1) Create a new vault with some indentifying name for this week-long project
2) add EVERYONE who has access to the legal vault such as partners who need access to that login IT staff who maintain the systems, as well as the paralegal who needs access manually to this new vault. DON’T forget ANYONE or they will be unable to do work, which costs money.
3) Move the password to this new vault, it will be the only password in this vault.
4) when the project is complete, move the password back to the original vault
5) delete the vault created for the project and forget it existed

Now multiply this process across 5+ paralegals working 50+ projects over a short period of time in addition to contractors, and you have an absolute rats nest of a system. In addition you have now added many hundreds of dollars of wasted money on non-production labor and therefore multiplied the real cost of 1Password by exactly that much. And no one understands what is truly going on outside of IT, and therefore no one is truly satisfied with the system.

LastPass on the other hand works exactly as they expect, with vault access for permanently priviledged staff, and item level sharing for limited access that can be removed at any time independant of the other items in the vault. This process requires no thought, wastes no time, and costs no money, and since the organization is static folks eventually get a feel for where everything is and get comfortable. Whereas 1Password with it’s rediculous single-password vaults constantly changing means things are never in the same place two weeks in a row and no one ever really knows what is going on with it. It’s a total non-starter.

GeekSpeak411

Essentially what brenty posted in September is exactly what needs to happen, there needs to be an invisivble vault created behind the scenes that gets updated with the parent vault. We’ll call this child vault a “share”. There may be a single share, there may be multiple for a single item. The password should remain in it’s properly filed parent vault, and this whole process should be completely invisible to the end user and done behind the scenes.

Keep in mind that with even 3 partners creating vaults and sharing in your multitude of methods available currently (shared vaults, and truncated shares) it is literally impossible to know within 1Password who all has been given access to things, and therefore impossible for IT to even manually notify the right folks when something gets updated unless we waste time talking to each person individually and hoping they don’t forget anyone. That’s an hour right there, and that single password change has now cost a couple hundred bucks in an attempt to change it gracefully without anyone having downtime.

GabeBrady

I'll be reaching out to business@1password.com about this issue.

We like everyone else in this thread are facing the same security issues with 1Password: namely, it is very difficult to adhere to the 'on a need to know basis' security principle with 1Password. It's access to a whole vault for the user or no access at all.

It's essentially a problem of granularity: if granular access control (note: I am not referring to permissions, in this context, take permissions to refer to what is adjustable using custom Groups within 1Password for Bunisess, i.e. the capacity to restrict certain groups of users to only being able to take certain actions) to specific passwords is required then, within the current 1Password conceptual model, one logically arrives at — create 1 Vault per Password. This means that individual passwords may then be associated with individual users. This is, in theory, a great workaround, however, the UI is not built to support it. It also means that one looses the convenience of adding a user to a whole group of passwords simultaneously (great for on-boarding a new team member quickly).

I am not a cryptography expert so forgive my simplistic solutions but it seems like password data blocks (i.e. a username, password, notes, additional fields etc. etc.) need to be treated cryptographically like a vault with another class of groupings being possible on top of that (analogous to the current 'vaults').

This would mean that the data model would essentially consist of two classes of objects:

1. 'Password' data blocks that are encrypted as vaults are now
2. 'User' identities

These fundamental units should then be able to be grouped. For example:

1. A group of 'Passwords' would be a 'Vault'.

2. A group of 'Users' could be a 'Team'.

Once these superstructures are added further relationships could be developed. Just 2 examples:

1. An individual 'User' could be added to a 'Vault' but not be a member of a 'Team'. This would be great of a Contractor.

2. An individual 'User' could be a member of a 'Team' which could have access to a 'Vault' but access to a single 'Password' within that 'Vault' could be switched off for that 'User' (via a dialogue when adding that 'User' to a 'Vault' for example which displayed a list of 'Passwords' in that 'Vault' with check-marks). This would be great for restricting access to 'pay per use' service that the 'marketing automation person' should not use during short term project that is kept within the 'dev vault'.

This structure would also address the issue of syncing. If 'Passwords' were an individual data block then they could be unique within a 1Password account. To make a 'Password' appear in multiple 'Vaults', one could simply select, from the 'Password' screen, the 'Vaults' in which that 'Password' appeared. Only one 'Password' object per account means no more sync issues.

Another enterprise benefit would be being able to filter and report by 'Password'. This would be a report which basically showed a list of 'Users' associated with a given 'Password'. This would be very helpful when auditing access.

Another enterprise consideration is that really, in an ideal world a product such as 1Password actually shouldn't need to exist (we don't live in an ideal world so I'm verrrry thankful 1Password does exist). Ideally, from a security standpoint, users would have individual accounts for each service they use, administered from within the administration section of a given service or tool. However, the internet is far from reaching a standard for user account administration so many systems either only allow 'Users' or have a very limited 'Admin' --> 'User' structure instead of 'Owner', 'Billing Manager', 'Admin', 'Team Member' etc.

This avoids centralised administration of passwords entirely.

Add federated identity services to this mix which can map permissions structures onto services and you have the ultimate in enterprise security (see Expensify's SSO integrations, including a SAML implementation, they're brilliant).

Of course, not every service has ideal access structures or integrates with federated identity services so 1Password fills a very real design gap, however, it needs to realise that it operates within a broader paradigm and must conform to the access control process within an enterprise. This means giving enterprise customers a data structure that is flexible enough to allow them to map their policies onto 1Password at scale.

Luckily we are a small start-up of 30 people, we can work around the current inflexibility, however, despite loving the product, as we grow we will be moving away from 1Password due to the lack of flexibility in the data structure.

If this is indeed an engineering problem, please put your best people on it.

If this is just a communication problem and I'm just not understanding something fundamental then please point me to an article that explains an alternative way of working that achieves the same goal by different means.

Throwing your hands up and saying... 'but, but, but it's too hard!' is super lame. No-one ever changed the world by saying a problem is too hard and walking away.

If the problem is really technically impossible, which I doubt, please at least release a paper explaining where you've gotten to so that so that other smart minds can work on the problem.

If this is just the fact that a fundamental, ground up architecture change is required, then you better get writing/spending because I'm thinking this issue might even be enough for another start-up to wedge it's way into the market offering this feature alone, by the time you get around to it. Most of this thread would buy such a product... and at enterprise scale too providing plenty of cash to muscle in on your consumer business.

I really hope this doesn't happen. I love 1Password.

I don't really need a response, I'm just adding my voice to the crowd and sharing some of the work we've done internally to identify our 'ideal solution'.

AGAlumB

@GeekSpeak411: First of all thanks for taking the time to share your thoughts. I also appreciate you reading my comments above, and am glad they resonated with you. But I think as a result we may be trying to hand-wave this challenge away when really doing the under-the-hood stuff and UI to make something like this happen is no small task. Possibility is important, but execution matters a great deal. Hopefully we'll be able to do more in this area in the future. But for now it's entirely possible for each of us to share items with others on an ongoing basis so they get any changes to them, by way of sharing a vault that contains said item(s). I agree that it could be made easier to do so, but whether we think of it in terms of the target item or the containing vault the result is the same. And the way it works currently, while certainly not ideal for all every use case or preference, has the very real benefit of existing and being usable by anyone. ;)

As an aside, I do think that notifications are an interesting idea. That could easily get out of hand of course, so it's something that would need further consideration. But currently in the desktop apps sorting by date modified allows us to see what has changed recently. And I find myself sticking with that view more and more since it kind of gives me a "recent" list. Anyway, great discussion. :)

AGAlumB

@GabeBrady: Indeed, you're right that the UI could do more to help in this area, as far as making it clearer who has access to what without having to go to the web interface. We've added some functionality to the apps already that once was limited to the web app, and we'll continue to do more like that over time. It's really helpful to know that you'd find it useful. It's easier to justify working on features that people will actually use. :chuffed:

However, as mentioned above, you can totally share only certain items with certain individuals already. It just works in terms of putting those items you want to share with, say, only Johnny, into a vault that only he has access to. The only difference is that you're sharing the vault which contains the item intended for them. If you just change the word "vault" to "item" in your mind, it serves the same function. :)

1) An individual 'User' could be added to a 'Vault' but not be a member of a 'Team'. This would be great of a Contractor.

That's what guests are for. It is necessary to invite someone to setup an actual account in the team in order for all of the necessary keys to be exchanged, so that encrypted data can be decrypted by them in the vault(s) they have access to. Otherwise you would need to manually encrypt data, outside of 1Password, and then give them the keys to decrypt it via a secure channel. Most people are not comfortable doing this. That's why 1Password exists, to make this sort of thing seamless. Otherwise, if you really really only want to share a single piece of information securely, you could use GPG, S/MIME, etc.; you don't need 1Password. The sharing mechanisms we've built require a one-time setup to share a vault with a specific person, but after that you can continue to share additional items with them in that same vault. It's setup this way to both maintain security and also remove the burden of key management from users. That's not to say there isn't room for improvement, but we're only going to make changes that allow us to increase convenience without sacrificing security.

2) An individual 'User' could be a member of a 'Team' which could have access to a 'Vault' but access to a single 'Password' within that 'Vault' could be switched off for that 'User' (via a dialogue when adding that 'User' to a 'Vault' for example which displayed a list of 'Passwords' in that 'Vault' with check-marks). This would be great for restricting access to 'pay per use' service that the 'marketing automation person' should not use during short term project that is kept within the 'dev vault'.

I don't see the difference here, except a preference for the term "password" over "vault". The contents of a vault are encrypted with that vault's keyset, so pretending that Johnny can only decrypt certain items in it would be security theater, though I can appreciate the impulse. If you adjust the thought process to making only a certain vault accessible to Johnny, you get the result you want, with the added benefit of not needing to setup a separate share to give him access to a second item, and so on.

You make some really interesting points about data structures, but again, I think you're focusing only on passwords. 1Password deals with many more kinds of data beyond just passwords, so it really can't work the way you're proposing -- at least without stripping out a ton of functionality that millions of people use already.

But you're dead on that scaling can be a challenge. Fortunately we're getting great feedback every day from large companies that are using 1Password -- and that's part of where our SCIM implementation is growing from, to allow seamless provisioning, with more to come.

Throwing your hands up and saying... 'but, but, but it's too hard!' is super lame. No-one ever changed the world by saying a problem is too hard and walking away.

Yeah, no one is doing that. I don't know where this is coming from. ;)

I don't really need a response, I'm just adding my voice to the crowd and sharing some of the work we've done internally to identify our 'ideal solution'.

Seriously though, I'm really glad to hear that you've already reached out to your business rep, to discuss more details specific to your start-up's situation. We'd love to grow with you over time as you grow. We're not going to throw the baby out with the bathwater when millions of people depend on 1Password today, but I'm sure that there are changes we can make that will make 1Password a better fit for you and others in similar situations without making it worse for everyone else. Thanks so much for your passion! :)

dg_harrison

I too am having an issue with password sharing between individuals. As I see it right now 1Password really doesn't allow "sharing" of passwords, it only allows "copying" aka duplicating passwords between Vaults, or moving using the "Move to Vault" option.

In my companies use of 1Password, when a user creates a password in a Vault and needs to "share it" to another team member that does not have access to the first Vault, they copy the password to the secondary Vault using the "Copy to Vault" option. This creates a problem in that there are then two totally separate copies of the same login in two different Vaults.

For a visual example see below: If a team member in "Department 1" needs to share "password1" to another team member in "Division 1" (meaning a team member not in Department 1), they would use the "Copy to Vault" option and make a copy of "password1" into the "Division 1" Vault. At that moment they are creating an independent copy of "password1" in the "Division 1" Vault, signified by "password1-1". Say a user in "Department 1" down the road updates "password1" the copy of that password which was copied to "Division 1" (password1-1) is then rendered useless, in that it's an old copy of "password1". In order to support the current model the user would have to update the both "password1" and "password1-1" which is cumbersome and creates an "out of sync" situation.

Department 1
password1
password2
password3

Division 1
password1-1
password4
password5
password6

Ideally, if users were sharing passwords just between Vaults it would be an actual share, meaning the same password would be listed in two Vaults, if it was updated in one Vault, it would update in the other Vault. With such an arrangement, you can have team members operate in either their Department or their Division, some team's Departments have much more access related to their positions, so would have many more passwords, the Division wouldn't need access to those passwords, but there are logins that would be shared logins available in both the Department and Division Vaults as a single instance of the password.

AGAlumB

In your example, I guess my question is, why not just move that item to the shared vault instead of creating an additional copy?

But to the larger point, as mentioned previously, in order for someone to be able to access the item in the first vault, they would need to have the "keys" to decrypt that vault. So while we could certainly do some security theater and allow you to share "a single item" from that vault, behind the scenes that would only be enforced by policy, since the recipient would necessarily need to have the keys which would allow them to access anything else I that vault. In order to do otherwise, a new vault would need to be created with that item, with the keys shared with only the people who should have access to it. Certainly we could probably find ways to make that process more seamless to the user, but it's important that anything like that we do be done with security first, not give the user the impression that something is secure if it is not.

mrpaul

Just jumping into this conversation now. My use case is I need to give passwords to people, and I never need (or want) access to that password again. My guess is most people sharing passwords who do not want to create a new vault likely are in this situation. It seems like this could be relatively easily solved in 1Password if you added a public/private key pair for each user. I could share the password by encrypting it with the public key, and only the owner of the private key could decrypt it. 1Password could do this all behind the scenes, and the private key could be encrypted with the user's password, ensuring that even 1Password could not decrypt the shared password until the user logs in. I'm envisioning a flow like this:

SETUP

• the next time a user logs in, 1P creates a public/private key pair, encrypts the private key w their password, and stores it. It also stores the public key in a 1P centralized store of public keys. Whether or not you actually make any of this visible to the user is open to debate - I can see pros and cons of each.

SHARING

• I create a password, and select an option to share, and select the user.
• 1P encrypts the password with the users public key, and stores it

RECEIVING

• user logs in, and
  • is notified there is a shared password awaiting. They select the vault to store it in, and 1P decrypts with their private key, and re-encrypts and stores in the chosen vault
  • OR, if you don't want user interaction, the key is decrypted with the private key and re-encrytped and placed in their private vault

Lars

@mrpaul - thanks for the suggestion! Indeed, something like this is similar to how it's already done, but with vaults instead of individual items. There's a fair amount of behind-the-scenes intricacy that is never shown to the user simply because how it works isn't really relevant to using 1Password for saving, storing, retrieving and filling Login and Password items - or anything else. Your use case is not unique, but it's also far from common, in our experience: most people who have passwords they want to share with others want to actually share them (in other words, on an ongoing basis), not just create them and pass them off.

We've certainly given some thought to how we could expand things to allow secure sharing within 1Password of individual items (as opposed to vaults, or sharing outside of 1Password, which comes with its own set of drawbacks). But it's not a trivial adjustment, and like nearly everything else we do, whether and when we work on it is driven by a combination of factors: how much developer energy it would take, how many people would benefit from it, how many actively want it, security concerns, and a host of other factors. It's certainly something we've considered (individual item sharing, if not the exact method you propose), but I've nothing to share with you at the moment regarding decisions or progress.

mrpaul

As an alternative, you could essentially automate the steps I'm currently doing, which would make it much easier for non-technical users of 1Password. Here is what I do:
1. Create a vault
2. Create a pw in that vault
3. Add the user to the vault
4. Tell them to get the password
5. Hand-hold them through the process of moving the password to their private vault
6. Delete the vault

Not a great process.

mrpaul

One more follow up - if you were to automate the 6 step process I define above, you would probably want to remove me from the vault after step 3 and make the user the admin for that vault, so the vault deletion was done under their account. That would be a nice little workflow for those of us who have to hand out passwords to others.

So the automated flow might be:
1. I create a password in a vault (perhaps my private vault)
2. I select to move the password
3. I pick the user to whom I'm giving it to (presumably limit to users within an org? Or I enter an email or account, and hopefully I got it right? Definitely some risk here to consider.)
4. 1P builds a hidden vault, assigns the user to that vault (and me if needed) and moves the password to it
5. 1P removes me from the hidden vault if it needed to add me
6. Wait for the user to log in
7. User logs in
8. 1P moves the password from the hidden vault to their private vault
9. 1P deletes the hidden vault

You would probably want to add some notifications too.

AGAlumB

@mrpaul: Certainly there's room for improvement, but it's really not as complicated as you're presenting it. ;)

When I need to share something with a family member, for example, there isn't very little involved, especially for them. Most often they already have access to a suitable shared vault, since sharing a vault only needs to be setup the first time (as opposed to "individual item sharing", which would need to be managed for, well, each individual item). In that case, I just save the item there, and either tell them they have it or just let them find it there when they need it (for example, I saved the garage door code in the Shared vault; it may never be needed, but people sometimes forget things!) They can then access it any time. :sunglasses:

Worst case scenario, I don't already have a vault saved with a specific person, so I create a new one and give them access to it, and save something there. This is completely transparent to them: it just shows up on their devices where they're signed into their 1Password account. The extra step is just for me: setting up the new shared vault. :glasses:

What you're describing above is similar to what we have with the "send a copy" feature in 1Password Business beta, which lets you select a member of your 1Password Business membership plan to (one way) place a copy of an item in their Private vault.

The difference is there aren't any "hidden" vaults, and it doesn't require the extra steps because key exchange has already been done when they accepted the invitation to the company's membership plan. Again, this is a beta feature, and I'm sure this doesn't cover every imaginable use case, but if we get it to the point where we're satisfied with it we'll release it from beta at some point. :)

mrpaul

That sounds perfect! We have a business license - I'll go check out the beta!

AGAlumB

That's great! Let us know if you have any questions or feedback on the feature. :chuffed:

mrpaul

Love it! It is just what we needed. Thanks!

AGAlumB

That's lovely to hear! Thank you! :chuffed: :+1:

[Deleted User]

Hi @brenty,

Could we get an entry added to the activity log where "Send a copy..." is used to send a shared vault item to a user?

I can see from the Usage Report that X user accessed said item but not that they copied it to Y user.

AGAlumB

That's covered under "Item usage":

Item usage is reported any time a team member: [...] Exports, prints, or shares an item

Perhaps we can expand on reports in the future. But it's worth noting that, to be realistic, telling you "this item was shared" gives the impression that others were not, when in fact if the person accessed the item at all (again, covered in the log under "usage") they could of course give it to someone else by copying the information anywhere, inside or outside of 1Password.

sklompextern

Hi @brenty,

The sharing feature within Business is really an awesome option for our company. Is there any info available on when and whether it will be included in future regular releases of the 1Password App for Mac?

Thanks!

AGAlumB

@sklompextern: I'm not sure what you're asking. Can you clarify?

sklompextern

@brenty When will this option “What you're describing above is similar to what we have with the "send a copy" feature in 1Password Business beta, which lets you select a member of your 1Password Business membership plan to (one way) place a copy of an item in their Private vault.” come to the regular 1Password apps? Or did I miss something and should it be there already?

AGAlumB

@sklompextern: Ah, thanks for clarifying. No, you didn't miss anything. This beta feature is available only from the 1Password web interface. As far as when we might have that feature available within the native 1Password apps, like 1Password for Mac, I couldn't say for certain, but I think it's highly unlikely that we would even try to add it to the apps while it's still in beta, since it could be changed substantially or be scrapped entirely.

sklompextern

@brenty Thanks for the info! Since it is mainly for our IT guys to push individual pwds securely to colleagues, I’ll give it a try through the web interface and hope for it to come to the apps also :-)

BR,

Sietse