Re: [xacml] PEP Conformance

[Polar Humenn <polar@syr.edu>]

On Wed, 9 Oct 2002, bill parducci wrote:

>
> > As far as multiple PEP-PDP relationships, I don't think you can say
> > anything to make it work in a consistent manner, so why really bother.
>
> then to take this back to my initial point, this implies that a large
> portion of SAML that is a waste of time. there is no reason why you
> would create a messaging protocol where the physical implementation of
> the message is disregarded.

Bill, I really don't understand this point? You are saying SAML is a waste
of time because the messages are disregarded? Who is disregarding
messages? In what situation are messages disregarded?

>
> > Consumed yes, in a SOAP sense. It got a valid response from a valid
> > request.  But as the test says, there is a previous agreement between the
> > TP and the IUT such that the result is expected for the request.
> >
> > It says nothing about what the TP does in regard to receiving the
> > AuthzQueryResponse, other than "validating" a response that is considered
> > valid by Test specification.
>
> oh come, on. so what you are saying is that if one gets a 200 response
> at the http level there is conformance? a SOAP ack? that says nothing
> about interoperabilty at the layer being tested.

No in this case, you have to get a SOAP SAML AuthzQueryResponse with the
"Permit", "Deny", "Interdeterminate" response that is previous agreed to
by the TP and the IUT for the particular SOAL SALM AuthzQuery.

Note, this is the SOAP SAML conformance case, of where the IT and IUT do
not have a language like XACML to rely on for access decisions. They just
have to have previous agreed upon results to test adherence to the SOAP
SAML bindings, and getting the proper resposne back for the specified
request. That is this conformance is.

> > True, but the "result" is emitted by a PDP implementing a SOAP binding.
> > Making sure they return the same results for the same configuration, same
> > inputs (XACML policy being considered an input). It says nothing, and
> > rightfully so, how an application should behave that uses such a SOAP
> > request/response.
>
> i disagree. it says that the consumption of this information must be
> validated. the ONLY way to do this at message level is for the
> receiver to indicate how it *interprets* the message (i.e. what it
> would do with it).

I can validate a X.509 certificate by giving it to an OSCP server and
getting an okay response. That doesn't tell me what I should do with it.

> > This is my application choice. My application is to deny you access to the
> > real resource, yet give you access to a false, or an alternate resource
> > instead, with no discernible way for you to figure out that you have been
> > denied.
>
> 1. by not granting access to the requested object you *are* issuing a
> DENY; secondary actions are of your own choosing
>
> 2. if you take said action because you didn't understand the
> obligation you are in compliance (whether you like it or not :o)

Yeah, but you'd never be able to tell, because of the way my application
operates.  So you cant run a conformance test on my application and call
it XACML PEP compliant. :(

Like I said before, I don't mind having an interpretation of denying
access based on non-understandable obligations, it's the multiple PDP
situation that clutters up the semantic interpretation.

> finally, i would like to point out that these issues have been
> discussed in some detail at F2Fs in the past and the current wording
> is the culmination of an agreement that was struck by the group some
> time ago. given the late hour at which the conversation is taking
> place i suggest that you propose a concrete alternative to the current
> text, schema, etc. so that we can get closure on this. short of that i
> would like to suggest that we call a vote on the list to see if enough
> people share your concern such that this topic is revisted.

As long as I can get a determinate consistently computed result for inputs
run against an instance of an XACML policy, e.g. 2+2=4, I am happy, the
specification for XACML is complete. I can ignore the other stuff.

I'm only trying to point out where the specification is vague, and has
holes, and requirements that can never be enforced, therefore is just
fluff that will be ignored. At this point I don't really care what you say
in it. The public commenters will decide.