Reviewing this thread again, I think it may be that I am
talking about resource attributes not referred to in the
active policy set, while others appear to be addressing
"extra" user attributes.
I am suggesting that it it only "extra" resource attributes
that should cause a DENY decision by default.
I agree that ideally this situation would never arise.
1. The custodian of the protected resource is likely
responsible for applying resource tags, based on sensitivity
or other characteristics of the data or service. If a tag has
been applied for which the PDP does not have a policy, then it
is likely that some rule that the resources owner expected to
be in place has somehow not been invoked, and thus the
expected protection on which the owner relies is not there.
Safest to DENY while seeing what happened.
2. I think this situation is in fact likely to arise in a
multi-organizational environment where coordination between
active policy sets and user provisioning and resource marking
activity would be harder to coordinate. It would also be more
likely to arise if data from various sources were combined for
analysis. Again, if coordination has failed for any reason,
it's better to DENY be default.
3. Finally, there doesn't seem to be much downside to
making this "deny if not recognized" the default. If an
expected access is denied, the requester is going to be
motivated to get to the bottom of the problem.