It is another way to call a "user", hence why I used the word indentity instead.

No its not. There's all sorts of stuff you can do with capabilities that are really awkward to even think about with users. Like, when a database starts, you can hand it the capabilities it needs to access a specific directory, listen on a specific port and append (but not read) a specific log file.

User based security is usually done by the folder being owned by the database, or an ACL or something. But with capabilities, you don't need to make a database user or set any flags on the folder, or make sure the database's configuration matches the filesystem permissions. The capability is basically a pre baked file handle that can be used directly. And capabilities can do lots more stuff! They can be more fine grained - eg, "Whatsapp can only access these specific photos in my camera roll". And a program can pass a subset of its capabilities to a child process.

Capabilites have ownership, ownership requires belonging to something, all the way up to booting the OS.

Capabilities can just be variables. Variables all belong to something, all the way up to the OS. Would you say variables are a type of user permission? Obviously not. Variables are more versatile than that. So are capabilities.

This is what uid and gid are used for in Linux respectively. There is only a concept of "user" and "group" when you add a Unix-like operating system in top such as GNU or Alpine.