Maybe future work, but we want to ultimately be able to respond with message(s), and a status and code here like webhooks do. The response back to the client request (the one being validated for admission) should use the status and code.

This brings up a question I didn't fully cover in the KEP:

When multiple policy definition validations deny admission, which status and code are returned? The alternatives I'm aware of:

1. Agree on an order of precedent of http response codes, use the "most severe" code
2. Use the code of whatever policy fails first

If we go with (2) we need to make sure we validate policies (and bindings) in a consistent order. But I would love to see (1) work, I just haven't thought it through carefully enough to know if there is a sane ordering.

Since we only return one status/code back, do we include all validation failures in messages?

I was assuming if, for any reason, any validation is a Deny, then the response code is unconditionally 409 Conflict. Should policy definitions be able to control the HTTP status code? Are there other codes that one might choose?

Re: returning multiple errors. I believe we can return a JSON-formatted error string with some metadata like web hooks do. In this case we can return an JSON array with an entry for each validation that failed where the requestor can look for more information.

Since we only return one status/code back, do we include all validation failures in messages?