Policy placeholder in XKMS

Is a logical binding of policy with Service URI the only way to bind policy
to a VALIDATE response(see below)?  I understand the content of policies is
out of scope, and that we want to move away from human viewable policies,
but its seem that a more concrete placeholder for policy information would
be very useful.

While evaluating potential profiles of XKMS for Identrus, I had imaged two
different types of policies with respect to XKMS: One that is bound to a
key, and another that is bound to a transaction... or one represented in Key
Bindings, and the other somewhere else.  This delineation could also be
viewed as signer policy and relying policy.

It seems we're shying away from dealing with policies all together, in order
to avoid all the legal/NR debate.  I agree that debate should be elsewhere,
however, managing policies seems to me as the most import link between the
business and technical aspects of an application.  I would argue that a more
comprehensive, and granular policy system is required for large scale PKI.  

I do agree that policy management is mostly out of scope for XKMS, however,
If we don't provide a clean placeholder for policy Identifiers (not viewable
policy) to be bound to keys/transactions, then we're excluding the option
for application to effectively manage them.

Does anyone share this, or a similar, view regarding a policy placeholder?
This might also be a nice option to give contextual definition to VALIDATE.


From the minutes in our last F2F: 
	Issue 1: Will policy URI be explicit or implicit in requests?
			Resolution: Issue is application context specific,
URI should be bound to the service URI. Clarification should be made in the
spec vice the requirements. Policy should not be confused with legal issues.
Policy is a set of XKMS rules as far as XKMS is concerned. If policy
changes, XKMS not responsible. Policy issue is out of scope. 


-dan