It seems the ACL design is targeted at providing security for object instances, which is great if you need very detailed authorization. However, it seems that the API limits one from applying the ACL concept to other Use Cases. Namely the following:
1. ACL at the Class level (Authorization requirements not based on context or instances)
2. ACL at the field level
This would require the ACL class to be a bit more abstract. Instead of referring to an ObjectIdentity, maybe it could be a more generic "ResourceIdentity" with a name and a simple identity. Additionally, it seems a ResourceIdentityRetrievalStrategy would be added, which ObjectIdentityRetrievalStrategyImpl would implement.
Class and Field level security tags for the font-end might look like:
This would be equally useful with the back-end ACL features as well. One more example might be to use Class-level security when a mixed collection of Objects sharing a common supertype are returned. A post collection filter could be used to remove those Classes for which the user is not authorized to view.
It's quite possible that I'm missing the alternative approach to addressing my Use Cases. In order to use the ACL concept for my Use Cases, I would need to supplant the existing ACL class (since extending it would not be very clean) with my own which is quite a bit of work and a little risky.