RE: XACML TC Charter Revision - Strawman

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

I agree with Hal's partitioning. However, like a couple of other folks who
have voiced opinions, I think we should leave it up to the policy creators
to specify if a policy can be exposed upon denial.

> -----Original Message-----
> From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
> Sent: Monday, June 11, 2001 1:02 PM
> To: 'Simon Y. Blackwell'; 'xacml@lists.oasis-open.org'
> Subject: RE: XACML TC Charter Revision - Strawman
> 
> 
> Just so we are clear, I think the issue we are discussing is 
> whether a PDP
> should share information about the basis for an authorization 
> decision, in
> addition to they actual decision. It seems clear that the 
> actual decision
> will be made known to both the PDP and the subject. If that 
> is not what we
> are debating, would someone please tell me.
> 
> I think this problem needs to be partitioned into at least 4 
> cells. First,
> there is the case of access allowed and access denied. I can 
> imagine why
> someone might not want to share the reasons for denial, but 
> it is harder to
> understand in the case of access allowed.
> 
> Second, the question can be divided between informing the PEP 
> and informing
> other parties, in particular the subject. Again informing the 
> PEP, which is
> a trusted party, seems harmless. When access is allowed, this 
> is the case
> where some SAML people want this information for future audit 
> purposes.
> Where access is denied, the PEP may be able to correct the 
> condition, for
> example by letting the subject re-authenticate by a different method.
> 
> Informing the subject is not a SAML requirement and I can't 
> think of any
> valid reason for it. However, to argue we can't tell the PEP 
> because the
> information might leak seems a little like saying "we have to 
> execute people
> because we are too incompetent to keep them in prison."
> 
> In summary here are the four cells as I see them:
> 
>                         Allowed                                Denied
> --------------------------------------------------------------
> --------------
> ----------
>                  |                         |
> Inform PEP       |   SAML Requirement      |     Useful if 
> condition can be
> changed
>                  |                         |
> --------------------------------------------------------------
> --------------
> ----------
>                  |                         |
> Inform Subject   |      Harmless           |             
> Possibly Risky
>                  |                         |
> --------------------------------------------------------------
> --------------
> -----------
> 
> Hal
> 
> > -----Original Message-----
> > From: Simon Y. Blackwell [mailto:sblackwell@psoom.com]
> > Sent: Saturday, June 09, 2001 12:22 AM
> > To: 'xacml@lists.oasis-open.org'
> > Subject: RE: XACML TC Charter Revision - Strawman
> > 
> > 
> > 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
> > > 
> > 
>