How to handle implicit contextual "constraints"?

[termontwouter]

(Meta)data like the owner of the target of a request, but also the time of the request, for example, are facts that are always present. They can influence policy decisions and can be crucial to maintain good logs (even if they do not play a role in the specific policy in question).

Conceptually, however, even though some generic policy rules do not care about those facts (e.g. it applies regardless of the owner), UCP models them as needing that info. I'd argue they should not, since we can come up with an endless list of such data that could be relevant. For logs, the authz server can always add that data to the result of the policy engine, without passing it to that engine.

Apart from coupling policy reasoning and auditing logs more loosely, we should therefore decide whether we still pass all that (meta)data to the reasoner, or rather make abstraction from it, and only add it if they really form a necessary constraints for the policy at hand.

[termontwouter]

As feedback on the UMA demo: since ODRL policies should always contain an assigner, the resource owner should always be known during reasoning. This is also an example of the contextual constraints this issue is about.