1 person found this helpful
This is a very hard problem to solve for, and I'm not sure there will ever be an answer. The problem is complicated by the fact that most businesses likely have SSO sitting on top of Jive and their own policies and protocols around it. The lawyers could spend months reviewing another company's policies to determine if they'll even trust an identity coming from that company, not to mention the development work involved to support it. Multiply that by X number of companies whose identities you would be willing to entertain federation with. The business world is very different from the consumer world. In the consumer world, if I'm writing a web app today it's largely expected that I'd support federation with FB and Twitter. But in the business world, if I run a private Jive community for a financial services company, would I allow a user to log into my community using their jivespace (this site) account? Of course not, reason #1 being the fact that my username and password requirements are much more stringent than on this site.
In your scenario, I think it's just going to come down to "your place or mine" to decide where the cross-org collaboration takes place, and subsequently, who has to create a new account on whose community.