RE: Resource sets and resource string semantics

["Edwards, Nigel" <Nigel_Edwards@hp.com>]

I think we are letting the controversy around the protocol 
between the PDP/PEP cloud the issue to which I was trying
to draw attention. It was about assertions across sets
of resources. I believe it will be a common use case when
an Attribute Authority wants to issue an assertion about
a large set of resources (hence the example of everything
on http://wwww.hp.com). A PDP may need to consume such
an assertion to make a decision. Explicitly calling out
all the resources on a large web site clearly does not scale.

I agree hierarchical schemes may not fit all web sites or
all URI schemes. However, in the web today I see hierarchies
used to organize things all the time.

It is quite possible to add support for more complicated set schemes
such as that supported by SPKI. However, my preference right now is to
start with something simple.

Nigel.

> -----Original Message-----
> From: George_Robert_Blakley_III@tivoli.com
> [mailto:George_Robert_Blakley_III@tivoli.com]
> Sent: 15 May 2001 17:25
> To: Platt, Darren
> Cc: 'Philip Hallam-Baker'; 'Edwards, Nigel'; 'Hal Lockhart';
> security-services@lists.oasis-open.org
> Subject: RE: Resource sets and resource string semantics
> 
> 
> All,
> 
> I am generally sympathetic with Darren's position here.  I 
> think passing
> back policy is a complexity which we do not
> absolutely *have* to add to release one of our spec, as we 
> could support
> the "dumb PEP" case without it.
> 
> I think it's particularly naive to assume that the PDP has a 
> policy which
> can be expressed entirely as a hierarchical
> name-based thing.... so wildcards may not fit naturally into the URL
> structure depending on what the policy looks like.
> 
> Figuring out the issues surrounding passing policy back will 
> take us time,
> but there's a middle position.  In aznAPI
> we provided essentially an opaque field through which 
> explanatory or policy
> information could be returned in
> response to an authorization decision request.  We require 
> that the caller
> know what kind of PDP it's talking to
> when it makes this request and hence be able to interpret 
> both the datatype
> and the contents of any
> information returned in this field, thus punting the issue to 
> implementors.
> We could initially take this approach and
> then go back and fill in details of what types & values 
> should be passed
> for interoperable PDP/PEP combinations
> in this field  in a future release of the spec.
> 
> --bob
> 
> Bob Blakley (blakley@tivoli.com, regardless of what the email 
> headers may
> say!)
> Chief Scientist
> Enterprise Solutions Unit
> Tivoli Systems, Inc. (an IBM Company)
> 
> 
> "Platt, Darren" <dplatt@securant.com> on 05/14/2001 08:20:20 PM
> 
> To:   "'Philip Hallam-Baker'" <pbaker@verisign.com>, 
> "'Edwards, Nigel'"
>       <Nigel_Edwards@hp.com>, "'Hal Lockhart'"
>       <hal.lockhart@entegrity.com>, 
> security-services@lists.oasis-open.org
> cc:
> Subject:  RE: Resource sets and resource string semantics
> 
> 
> 
> > PEP: Can Alice access http://www.hp.com/finance/fred.xls
> > PDP: Yes, and Alice can access http://www.hp.com/*
> 
> I don't think we should be passing policy back with the authorization
> decision.
> 
> 
> > Note that another possibility is that the PEP is not a file
> > system. If the
> > access control policy or permissions/whathaveyou are embedded in the
> > resource the PEP may be asking a question of the form 'Does
> > Alice have the
> > Role X' or 'Does Alice have any resources in the set ..../*'
> 
> It is my understanding that the consensus of the TC was that 
> a PDP did not
> know how to make decisions, and would therefore not interact 
> in this way.
> This seems to be a PDP/PEP combination.
> 
> Regards,
> 
> Darren
> 
> 
> 
> 
> > -----Original Message-----
> > From: Philip Hallam-Baker [mailto:pbaker@verisign.com]
> > Sent: Friday, May 04, 2001 12:24 PM
> > To: 'Edwards, Nigel'; 'Hal Lockhart';
> > security-services@lists.oasis-open.org
> > Subject: RE: Resource sets and resource string semantics
> >
> >
> >
> > All resources on the HP web site ???
> >
> > How about http://www.hp.com/*
> >
> > or if we want to avoid any possibility of collision (although * is a
> > reserved URI character):
> >
> > http://www.hp.com/ *
> >
> > Or we could use an XPATH statement - maybe Eve can fill us in???
> >
> > The way I would see the conversation going is:
> >
> > PEP: Can Alice access http://www.hp.com/finance/fred.xls
> > PDP: Yes, and Alice can access http://www.hp.com/*
> >
> > PEP: Can Alice access http://www.hp.com/finance/mary.xls
> > PEP-Cache: Yes
> >
> > I don't like the idea of unconstrained wildcard matching etc.
> > However simple
> > hierarchical partitioning is probably enough for what we
> > need. After all the
> > admin will probably organize directories so that the wildcards match
> > cleanly.
> >
> >
> > Note that another possibility is that the PEP is not a file
> > system. If the
> > access control policy or permissions/whathaveyou are embedded in the
> > resource the PEP may be asking a question of the form 'Does
> > Alice have the
> > Role X' or 'Does Alice have any resources in the set ..../*'
> >
> >    Phill
> >
> > Phillip Hallam-Baker FBCS C.Eng.
> > Principal Scientist
> > VeriSign Inc.
> > pbaker@verisign.com
> > 781 245 6996 x227
> >
> >
> > > -----Original Message-----
> > > From: Edwards, Nigel [mailto:Nigel_Edwards@hp.com]
> > > Sent: Friday, May 04, 2001 2:29 PM
> > > To: 'Hal Lockhart'; Edwards, Nigel;
> > > security-services@lists.oasis-open.org
> > > Subject: RE: Resource sets and resource string semantics
> > >
> > >
> > > Hi Hal,
> > > I should have made it more clear that I am worring about the kind
> > > of interaction that make take place between an Attribute Authority
> > > and a PDP, rather than a PDP and a PEP.
> > >
> > > Sorry about that,
> > > Nigel.
> > >
> > > > -----Original Message-----
> > > > From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
> > > > Sent: 04 May 2001 16:56
> > > > To: 'Edwards, Nigel'; security-services@lists.oasis-open.org
> > > > Subject: RE: Resource sets and resource string semantics
> > > >
> > > >
> > > > Nigel,
> > > >
> > > > > The intent of this assertion is to specify authorizations
> > > associated
> > > > > with Alice's account.
> > > > >
> > > > > Suppose I want to issue an assertion allowing Alice to
> > access all
> > > > > resources on a large web site with a dynamic resource set,
> > > > > e.g. http://www.hp.com/
> > > > >
> > > > > Clearly it is not possible to enumerate the entire
> > > resource set. So
> > > > > how do we handle this case?
> > > > >
> > > > > It occurs to me that some may feel that this sort of
> > > > assertion should
> > > > > be considered by XACML, rather than SAML. I guess one possible
> > > > > resolution is to leave it to XACML.
> > > >
> > > > I don't understand the use case you have in mind. SAML is
> > > not a policy
> > > > provisioning protocol. What sort of request might Alice have
> > > > made to suggest
> > > > to the PEP that she might want to access all of www.hp.com?
> > > > In the normal
> > > > case, there will be thousands of pages she can access and
> > > > thousands she
> > > > cannot. Even with a really general language to express
> > > > resources, e.g. reg
> > > > exp, It's going to be a long list.
> > > >
> > > > It sounds to me that what you really ought to do is operate a
> > > > PDP, which
> > > > receives Attribute Assertions (and perhaps Authorization
> > > > Assertions) and
> > > > makes a decision whether to allow access. A PEP is supposed
> > > > to be quite
> > > > simple.
> > > >
> > > > > A related issue is the semantics of resource strings. I
> > believe we
> > > > > need to define what these are. Suppose one of the
> > > > <Resource> elements
> > > > > contains the following: http://www.hp.com/
> > > > >
> > > > > What are the semantics: the home page or everything under it?
> > > > > In my opinion
> > > > > serious security issues will arise if the asserting party
> > > > and relying
> > > > > party apply different semantics.
> > > >
> > > > Certainly this is something that the specification should
> > > > make unambigious.
> > > >
> > > > Hal
> > > >
> > > > 
> ------------------------------------------------------------------
> > > > To unsubscribe from this elist send a message with the 
> single word
> > > > "unsubscribe" in the body to:
> > > > security-services-request@lists.oasis-open.org
> > > >
> > >
> > > ------------------------------------------------------------------
> > > To unsubscribe from this elist send a message with the single word
> > > "unsubscribe" in the body to:
> > > security-services-request@lists.oasis-open.org
> > >
> >
> >
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to:
> security-services-request@lists.oasis-open.org
> 
>