OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [xacml] PEP Conformance



> 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.

> 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.

> 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).

> 
> 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)


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.

b



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC