Probably the best example of data common across services is address books. Most communications service have at least one, and they are not all common (that is, outlook has one; Netscape has another; aol has another;...). Most users don't want to have n of them - too hard to maintain or update. So, what you might want is a "single" data store from the end users perspective.
There are several issues. At the root are schema issues (commonly called the information model). What this involves (and we had to do) is defining a commonly accepted description of whatever is being modeled. Then you need a (standard) way to accept specialized forms or information. The X.500 effort addresses some of this and LDAP's adoption of much of X.500 moves in this direction.
The second issue is transactional access and control. How you solve this depends on types of concurrency control required and data consistency requirements. For example, LDAP has some nice features, but ACID transactions are not one of them.
The next issue is distribution of the data. You can postulate a single data center or a set of remote centers. This problem is much easier for managing concurrency issues if the data are centralized. However, for some services, latency is an issue. Particularly if there is a large WAN involved and the user of the data (the service) has some time constraint on its activity, one generally wants the data as close to the server as possible. Caches are a common approach. However, this creates a potential data consistency issue. That is, who can do inserts or updates and how are changes propagated across the enterprise?
For security, I don't understand the question. By security, I assume you mean authentication, authorization and privacy. A nice use of these stores is to create a "single" login (authentication) so you can roam within the enterprise. How you do it, such as userid/passwords or certificates, is application dependent. The store should handle both. The store should contain lists of tasks and tokens defining privileges (authorization). Common items to relational data bases are read, write, and update privileges by cell, row, or table. However, applications will also want something similar, such as which features (functions) are enabled.
Finally, privacy insures that no one else who isn't authorized can see what you are doing. So you encrypt typically. Often that is handled by the data comm protocol directly and one doesn't do much other than use it (http vs. https for example). Other schemes get more complicated.
Third parties are either application developers and the security required depends on how you want to bundle applications together. At one extreme, each application is an island and the data should be kept distinct. At the other extreme, they are bundled. That data may be shared or not. In all cases, one probably wants some kind of audit trails of change.