Your question amounts to picking the right abstraction level for your service's interface. Every real-world system has different requirements, but as a general rule I strongly prefer service interfaces having a high level view. That is, the second approach you describe, not the first.
However, this is just a guideline and to make a sound choice you will need to be able to justify it with more than "some guy said it was better this way" or "it's the usual approach".
So let's dig down to the relevant issues here.
Coupling
Your design should allow the service implementation and its clients to be loosely coupled. The client should not need to know how the service is implemented, or how it stores (often, even how it represents) its data. It should be possible to (greatly) change the implementation of the service without needing to rebuild or modify the clients. The use of the word "Entity" in your description seems to imply that the objects exposed via the service interface correspond exactly to the entities into which the application's data has been decomposed. If so this may indicate that there is tight coupling between the client interface and the service implementation. Sometimes this is allowable though, where the service itself uses data definitions defined in its own interface (this can help with decomposition, which I will mention again later).
Think about how you would roll out a change to the data structures used in the interface; that is, if the data structures carried across your service interface need to change, must you perform a big-bang change (awkward!) or can your service design accomodate clients some of which expect the new representation and some the old? (interface versioning is a common way to allow this)
Decomposition
The service's interface design should generally allow enough flexibility that the service implementation can be split up in order to allow part of the service implementation to migrate to a different design. For example, it should be possible for the maintenance of people's attributes to be moved out of the old service implementation and into an LDAP database. While I suppose this is always possible, I mean that the design should work in such a way that the clients don't necessarily need to care that this happened, and that the implementation of only a reasonable amount of the service's interfaces should need to be changed to allow this. Phrasing this differently, this kind of refactoring should not require changes to be made in unrelated parts of the service implementation.
Indirection
Your service's level of abstraction should be chosen in such a way that it will interact in an easy-to-explain way with layered systems. For example, it should be straightforward to create a caching service which front-ends this service and caches data to reduce load on the back-end. Likewise with modifications to the authorisation scheme. Equally, it should be reasonably simple to create a mock back-end (often only offering a subset of interfaces) to facilitate testing of clients. Likewise, artificial clients for load-testing.
Other Issues
There are other issues to bear in mind for some systems which aren't always important, but can make life very hard if you don't think of them ahead of time. A big one here is the question of how to shard the service. That is, split the existing system into several parts, each of which deals with some of the data objects in the system. For example if your system accepts email, you may need to split it into multiple backends, each accepting email for a subset of users (e.g. "a"-"f" on shard 1, "g"-"p" on shard 2, "q"-"t" on shard 3, "u"-"z" on shard 4, "Â"-"Ͱ" on shard 5, and so on). In order to allow the clients to remain unchanged, this kind of change would also usually be accompanied by the introduction of a proxy layer, whose only job is to forward requests to the relevant backend (it should be possible to deploy as many proxies as are needed to cope with the load; their task is not computationally hard and it shouldn't require hitting a disk to identify the right backend).