RE: XACML TC Charter Revision - Strawman

["Simon Y. Blackwell" <sblackwell@psoom.com>]

What about explicitly allowing for both, i.e. an open world assumption and a
closed world assumption? This would allow for the users of our specification
to choose the approach that best matched their risk profile. Granted perhaps
more work for the group, but I believe there are strong arguments on both
sides of this issue. It might even be possible to define XACML in a way that
policy specifiers could force a particular behavior based on the nature of
the rules specified.

> -----Original Message-----
> From: bill parducci [mailto:bill@parducci.net]
> Sent: Friday, June 08, 2001 1:21 PM
> To: 'xacml@lists.oasis-open.org'
> Subject: Re: XACML TC Charter Revision - Strawman
> 
> 
> what i am saying is that you cannot GUARANTEE this is the case. if i
> remember correctly, just a few months ago verisign issued a 
> cert for one
> of microsoft's sites to an unauthorized entity -- things like 
> that kinda
> hinder utter faith in the authentication layer alone, don't you think?
> add that to the unavoidable latitude for specific vendors and users
> during implementation of whatever spec comes out of this group and you
> have the *possibility* of compromise.
> 
> if you can make the case that it is impossible for this to happen
> (which, from an academic perspective, is not possible because 
> one cannot
> prove 'non existence'), then the the balance between effort of
> implementation of discrete responses vs. the likelihood of 
> compromise is
> an easy one. otherwise, i suggest that we at least perform 
> due diligence
> in determining what the ramifications of discrete response codes are. 
> 
> i have no interest in one direction or the other, i just want to make
> sure that the issue is raised.
> 
> b
> 
> Hal Lockhart wrote:
> 
> > Excuse me. Are you saying that no means exists whereby a 
> PEP and PDP could
> > mutually authenticate and exchange integrity and 
> confidentiality protected
> > data over an insecure network?
> > 
> > Hal
>