Interpretations #103 and #104 serve to change the assignment statements of FDP_ACF.1 and FDP_IFF.x respectively so that subject and object attributes are associated with their subject or object as follows:
FDP_ACF.1.1 The TSF shall enforce the [assignment: access control SFP] to objects based on the following: [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes]
FDP_IFF.x.1: The TSF shall enforce the [assignment: information flow control SFP] based on the following types of subject and information security attributes: [assignment: list of subjects and information controlled under the indicated SFP, and for each, the security attributes]
First, it is not clear what a named group of SFP-relevant security attributes is in FDP_ACF.1.1. It makes me think of named groups of users, but in this context I dont it really adds anything to the requirement except confusion. The confusion is only increased by the fact that this phrase is absent from FDP_IFF.x.1. I tend to think that similar subject and object security attributes could be used for either requirement and in most cases they are going to be specified generally (e.g., privileges, identity, sensitivity label).
Second, originally neither requirement qualified the security attributes as necessarily being for subjects and objects within he assignments though FDP_IFF.x.1 provides this qualification outside the assignment. Now both assignments make it clear that the security attributes belong to subjects and objects by using very similar language. I tend to think that types of subject and information security attributes should either be in both requirements or in neither just for the sake of consistency.
Third (and finally the real point), while it can be argued that the original version of FDP_ACF.1 supports the notion of making access decisions based on security attributes not associated with subjects or objects, neither the original version of FDP_IFF.x nor either of the interpreted requirements appears to support this notion. The problems I have recently experienced are what if it is not clear whether the security attribute belongs to a subject or an object and what if a security attribute is related to neither?
For example, in a DBMS access may be controlled using a table that is indexed by subject identity and object identity. While it seems pretty obvious where the identities are assigned the access matrix is not clearly associated with either. As I see it, I could just not list the access permissions as an attribute and explain in the rules that the access matrix has to allow the access. Given that some of the rest of the elements seem to indicate that the rules should be based on the security attributes, I tend to think it should be listed somehow. So, I could alternately list it as a security attribute of both. Regardless, while the interpretations claim that they are intended to make the associations between objects/subjects and their attributes clear (though it is not made clear why this is important in an SFR), the interpretations fail to address the case where relevant attributes are not clearly associated with either.
Other examples include things like time of day, available resources etc. that are generally never associated specifically with subjects or objects. I suppose one could argue that the time and the current set of available resources (e.g., CPU, memory, disk space, file handles, network port) is always implicitly associated with everything in the TOE, but I dont think a good requirement should try to associate this global TOE attributes with objects and/or subjects.
Rather, I think the assignments should simply demand the security attributes to be clearly identified the TSS should make it clear where they all come from and to whom, if anyone, they might be associated.