Técnicamente, una Capability es un objeto inalterable que combina una referencia a un recurso con un conjunto de derechos o permisos sobre ese recurso. A diferencia de las Access Control Lists (ACLs) o Role-Based Access Control (RBAC), donde los permisos se asocian a un sujeto (usuario o rol), en un sistema basado en Capabilities, los permisos se asocian al objeto (la Capability misma). El poseedor de una Capability puede invocar la operación permitida sin necesidad de una verificación adicional de identidad o rol, ya que la Capability es la prueba de autorización. Esto permite un control de acceso descentralizado y una delegación de permisos más flexible y segura.
Las Capabilities se implementan en el mundo real en varios contextos. En sistemas operativos tipo Unix, las 'POSIX Capabilities' permiten dividir los privilegios del superusuario (root) en unidades más pequeñas, como CAP_NET_BIND_SERVICE para enlazar a puertos privilegiados o CAP_SYS_ADMIN para realizar operaciones de administración del sistema. Esto permite que programas específicos ejecuten solo las operaciones privilegiadas que necesitan, sin requerir todos los permisos de root. Otro ejemplo son los sistemas de archivos distribuidos como 'Tahoe-LAFS' o 'IPFS' (en su concepto de 'Content-addressed capabilities'), donde las claves criptográficas actúan como Capabilities, otorgando acceso de lectura o escritura a datos específicos. En el ámbito de los microservicios, 'Macaroons' son un tipo de Capability que permite la delegación de permisos con restricciones atenuables (caveats), ideal para APIs distribuidas.
Para un Arquitecto de Sistemas, las Capabilities son fundamentales para diseñar sistemas con el 'principio de mínimo privilegio' y una seguridad robusta. Permiten una delegación de autoridad fina y segura, reduciendo la superficie de ataque al evitar que los componentes acumulen privilegios innecesarios. Al desacoplar la autorización de la identidad, facilitan arquitecturas distribuidas donde los servicios pueden interactuar con permisos específicos sin depender de un servicio de autenticación centralizado para cada operación. Sin embargo, su gestión introduce la complejidad de la revocación (¿cómo invalidar una Capability ya emitida?) y la propagación segura. La elección entre un modelo basado en Capabilities y uno basado en ACL/RBAC implica un trade-off entre la flexibilidad y descentralización de la autorización (Capabilities) frente a la gestión centralizada y la auditoría más sencilla (ACL/RBAC).