# Axiomatics Feedback on Partial Evaluation

## Related documents
- [Partial Evaluation Draft](https://hackmd.io/@oidf-wg-authzen/HkLiZVdb1l)
- [Decisions for partial evaluation API](https://hackmd.io/@oidf-wg-authzen/Syg0dHYsYyl?)

## Notes

1. Mixes use of JSON objects and object arrays, which may introduce unnecessary complexity on the client that needs to process the response
1. In UC1-3, field decision in the response has a JSON object for value, but in UC4 it has an array.
2. In the response, decision.partial is sometimes a JSON object, sometimes a JSON array
2. The literals in the returned filter expression seem to be of the form <attribute> <op> <constant>.
1. What if the filter requires applying a function to two or more attributes?
2. What about function composition in the filter literals? E.g. how to express a condition such as lowercase(attribute_role) == “supervisor”?
3. What about constant values that are not strings or numbers? Multi-valued attributes?
3. There is no negation in the grammar for filter expressions, which seems to assume that all negations can be pushed down to the literals. This would force the function set to always be closed by negations (e.g. function LIKE requires the presence of some function NOT_LIKE).
4. What is the point of decision.type in UC3?
5. Except in “alternative 2 for UC1”, there is no type information on the attribute and the operator. This is probably OK, assuming that there is no overloading of operators and that the type of constants can be safely inferred.
6. In the draft, if an attribute is not given a value in the request, it’s assumed to be “undefined”. This might be too restrictive for engines like ADS, which can retrieve additional attribute values beyond those in the request. This limitation could necessitate extra mechanisms to ascertain if an attribute should be "undefined."
7. The use of a single string to identify attributes raises concerns about compatibility with AuthZEN's data model. Specifically, if both resource and action properties share an identical identifier, disambiguation would necessitate additional context to ascertain the attribute's category.
8. The examples demonstrate that action category constraints are presented separately from the filter expression. These constraints are formatted as a list of action name values. This format assumes that it is possible to efficiently extract a small number of combinations of these name values and their corresponding filters. However, tools like CAQ might necessitate as many internal evaluation calls as there are potential action name values.