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


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


Powered by eList eXpress LLC