'Capability Security Model' describes a broad spectrum of Security Models that attach service-authorizations to the entities demanding the service. These service-authorizations are appropriately termed 'capabilities'. This is in opposition to attaching service authorizations to the entity providing the service; for example, an Access Control List that is attached to a directory and indicates 'who' may enter/read/write/etc. does not qualify as a capability.
The practical advantages of a Capability Security Model over its alternative (the main competitor being Access Control Lists) stem from the fact that changing Access Control Lists is, in practice, a very difficult social and political problem: there is rarely a clear indicator of exactly whom should have authority (the capability) to change it, which means it gets delegated to some 'Trusted Computing Base' (e.g. the root hacker), and all change requests end up being bottlenecked through some individual who's had a long day and is nursing a headache. Capabilities, in comparison, offer a great deal more flexibility and reduce maintenance costs: if you have a capability, you can copy it to someone else, so they have the capability too, and it would be very much like you were doing whatever it is they want to do on their behalf... except that you can go home and watch Simpsons while your trusted friend, Fred, does whatever he wanted to do. It has been proven that Capability Security Model and Access Control Lists technically offer the same theoretical granularity when it comes to controlling service access (since they both expand to the same sparse matrix with entities on one axis and services to resources on another), but it is unlikely that it will ever be realized.
That said, the Access Control List approach does offer some advantages. First, in reality, trust is NOT transitive... i.e. if I trust you, and you trust Fred, it doesn't mean that I trust Fred, or that I'd let Fred into my house where he can drink my beer. And if I loaned you my lawnmower, it doesn't mean I'm permitting you to loan it out to everyone else - especially given that I could be liable if some child were hurt. Access Control List allow for direct expression and enforcing non-transitive trust, whereas capabilities do not. However, it can be reasonably argued that Access Control List is promising something impossible: that if you have access to a resource, you can always copy that resource and show it to Fred... or you can even give Fred all the information he needs to masquerade as you and confuse me (e.g. give Fred your passwords, supposing the authenticity tests don't involve study of habit-patterns and biometrics), or you can allow Fred to use you by relaying requests through you. These are all possible. Thus, some people have noted that despite trust not being transitive, attempting to enforce non-transitive trust is difficult or impossible in the face of treachery. So, perhaps, what ACLs offer isn't protection against intentional treachery, but rather protection against treachery of the more accidental sort, and a certain degree of social pressure to avoid mistake (e.g. if giving away a particular capability requires giving away both your Common Access Card and Password which has access to your e-money, most people can be taught and comprehend that this is a bad thing; if it also requires giving one of your eyeballs for an iris scan challenge by the CAC, then most people would be quite resistant to ever trying.)
There actually have been attempts to unify these. The Hybrid Capability Model simply glues both together (you must satisfy ACL and Capability), which neatly gains you both some of the best and some of the very worst of both worlds. Split Capability Model is even worse, requiring the same 'trusted computing block' table as the original ACLs plus requiring that every capability call back into this TCB. SPKI and certificates, however, do offer a fairly simple approach: allow capabilities to be tied to a particular user by requiring they sign with a private key each use of the capability with a time (or any uniquely scoped session identifier verifiable by the capability enforcer - e.g. a transaction ID from a shared transaction manager - to prevent replay attacks). So long as these entities can keep their private key private (which for process-objects only requires trusting the hosts upon which they are running... which does limit mobility a bit) one has the potential to create capabilities that are scoped to exactly one entity... i.e. the equivalent to ACL-granted authority.
How about some specific realistic scenarios that show the alleged drawbacks of ACL's. The accusations against it here are not specific enough to dissect, analyze, and confirm.
Do you have a specific question? Your claim against the accusations is not specific enough to answer.
'The original' Object Capability Model:
A security model (Category Security Model) in which all resources are referenced by "capabilities" that both designate the resource, and authorize access to it. The mechanism by which resources are created ensures that 'names' cannot easily be guessed and are thus 'unforgeable'. Possessing a reference to an object is considered a sufficient indicator of the right to act upon that reference. It is assumed that if you pass a reference to another object, you're giving them full permission to do anything that object is willing to do. Security is enforced by creating 'new' objects that limit the actions (e.g. by throwing exceptions or returning without operation) when the caller attempts a blocked action. It is assumed that you can trust the Object System environment and host computer to not intentionally violate the security system.
This is 'the original' capability security model as described by Dennis And Van Horn. However, the term "capability security" has since been used rather imprecisely, sometimes to describe security models that have little to do with the Dennis And Van Horn model. The new name Object Capability Model has been proposed by some researchers (see Paradigm Regained) in an attempt to reduce this confusion.
Some of the other models that have come to be known as "capability" models are
Capabilities As Rows Model (as in, rows of Lampson's access matrix)
Capabilities As Keys Model (also known as "capabilities as tickets")
Posix Capabilities (The least like any of the others, and purposely named to be confusing. "Linux capabilities" are the same thing.)
Password Capability Model (which includes cryptographic capability protocols and certificates)
Split Capability Model (hard to classify:
in some ways like the Object Capability Model, the Capabilities As Keys Model, and the Access Control List model)
Hybrid Capability Model (access must satisfy both capability and Access Control List rules)
Distributed Object Capability Model (local Object Capability Model systems connected by Password Capability Model protocols)
If you know of others, please add them to this list, and explain their differences from the Object Capability Model.
Is the Wiki Pedia "Capability based security" at en.wikipedia.org 
talking about the same subject?
another link there is en.wikipedia.org
Outside Links: www.cap-lore.com and www.eros-os.org .
Discussion moved into Capability Security Discussion.
For differences between capability and OO programming, see Capability Oriented Programming.
See Rights Amplification, which discusses couple variations on a useful pattern oft found in Capability Security Models.
See also Capability User Interface Anti Cap Quotes.
See original on c2.com