It might serve as a product instruction manual which is a single
monolithic PDP saying that there is one policy which is the root of that
PDP, which is either a PolicySet or Policy.
If you are pulling out relavant policies out of an LDAP server (only for
example), then where is this "root"?
the composition of the PDP is irrelevant.
"i" don't pull down anything. a PDP--be it one machine or a million--is
distilled to a context. since, by definition, a PDP is queiriable there
is something that externally represents that context. it therefore seems
reasonable that the entity representing that context may also be asked
about its Guiding Principles.
this is of value in my mind because i believe that one of the potentials
for XACML is to provide the basis for auditing security systems. the
ability to determine the version support/employed is of value here.
i also believe that as we explore delegation/distribution that the
ability for a PEP to "shop" for compatible PDPs may also be of use.
finally, if you look at the obligations proposal on the wiki you will
see that we have introduced the concept of hierarchical decision making
to distill obligations into an unambiguous decision, even though the
number of obligations possible is unbounded. this requires the context
to apply an obligation hierarchy. i don't believe that this can be
addressed in a policyset as it stands today.
i am sure that there are other examples that can be of use in this model.
i agree that this information is not applicable in the clean room model
of policy language. however, since we all pretty much agree that XACML
(XML) is not a real-time operational language i suggest that we need to
focus on those aspects that will allow it to improve interoperability.
one of the ways to do this is to create a mechanism that allows
disparate machinery to determine what it is dealing with.