Currently, sharing of data is limited to Kolab users on the same deployment from the same authorization realm. Often people want/need to share with users that are external to the Kolab deployment. This should be made possible.
Sharing data such as files and calendars has five known targets;
# Other Kolab users and groups of Kolab users (on the local deployment / within the same authz. realm),
# Known third parties with a local account (not a Kolab account, in the same authz. realm),
# Users and groups of users outside of one's own authz. realm (but still Kolab users, possibly within the same deployment),
# Users that can be authenticated through third party provided authentication mechanisms (OpenID/Facebook/Twitter/Google/SAML/...),
# Public and Anonymous
Options 2-5 should be made available under the following conditions;
* Send the target a (one-time) link with a hard-to-guess hash of sorts, but;
It cannot be assured that the target is also the (only) recipient of the one-time link.
It cannot be assured that the hard-to-guess link is not guessed.
* Send a username and/or combination of username/password and/or a password along with a link, but;
It cannot be assured the password is not shared.
The idea is therefore that sharing happens with targets that are known accounts of the target with third party providers of said account. A target is unlikely to share their Twitter/Google/Facebook/SAML/... account credentials with a third party.
2) we can do, but we have no interface for known local users to navigate/view/amend shared contents.
This would work on the premises that an uid=doe,ou=Contacts, inetorgperson can authenticate to LDAP, could be made to be allowed to authenticate to IMAP and could be authorized to IMAP folders.
3) and 4) would work based on token exchange, with 3) being special in that we would also have the provider under control and could make it more safe / assured if necessary, possibly integrating interfaces on the consumer side so that the consumer does not need to hit the provider's interface.
5) not unlike 2-4) requires an interface, with the special circumstance that it has an SASL nomer of "anonymous", and this is in fact a valid SASL authentication mechanism in and by itself.