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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-core message

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


Subject: RE: Requirement for Isolated Request for Authorization Atributes



OK maybe I should have said 'appears to be out of scope but attempting to
prevent a user from making such an assertion will require specific effort'.


Phillip Hallam-Baker
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: Darren Platt [mailto:dplatt@securant.com]
> Sent: Tuesday, March 13, 2001 5:42 PM
> To: Philip Hallam-Baker; 'Orchard, David'; Evan Prodromou
> Cc: Hal Lockhart; security-use@lists.oasis-open.org;
> security-core@lists.oasis-open.org
> Subject: RE: Requirement for Isolated Request for Authorization
> Atributes
> 
> 
> I do not believe this is currently considered in scope (by 
> the requirements
> group anyway), nor should it be:
> 
> > "Any party with the rights identifier PQR is authorized to 
> access the file
> > xyz.html"
> > 		Appears to be in scope but is very definitely a policy
> > statement
> 
> 
> > -----Original Message-----
> > From: Philip Hallam-Baker [mailto:pbaker@verisign.com]
> > Sent: Tuesday, March 13, 2001 7:48 AM
> > To: 'Orchard, David'; Evan Prodromou
> > Cc: Hal Lockhart; 'security-use@lists.oasis-open.org';
> > 'security-core@lists.oasis-open.org'
> > Subject: RE: Requirement for Isolated Request for Authorization
> > Atributes
> >
> >
> > Subject: RE: Requirement for Isolated Request for Authorization
> > Atributes
> >
> >
> > > From: Orchard, David [mailto:dorchard@jamcracker.com]
> >
> > > Pardon my gross ignorance, but is requesting 
> authorization attributes
> > > roughly equivalent to requesting policies?  So would it be
> > > that SAML defines
> > > a carrier for whatever XACL defines for ACLs?
> > >
> > > Dave
> >
> > There is a point at which the one can become the other. Trying to
> > make hard
> > and fast definitions as to the category of a particular 
> assertion may be a
> > mistake since in many cases the distinction lies in the level of
> > abstraction
> > rather than an objective issue.
> >
> > Take it by cases,
> >
> > "Alice is authorized to access the file xyz.html"
> > 		In scope
> > "Alice has the rights identifier PQR"
> > 		In scope (although see discussion on roles)
> > "Any party with the rights identifier PQR is authorized to 
> access the file
> > xyz.html"
> > 		Appears to be in scope but is very definitely a policy
> > statement
> > "Access to the file PQR is governed by this ACL"
> > 		Out of scope, where we don't want to go...
> >
> >
> > The distinction then becomes even more blurred if one considers
> > that a more
> > likely ACL statement would be
> > "Holdership of this rights identifier is governed by this ACL"
> >
> > This follows from a repeated suggestion by Butler Lampson 
> that ACLs should
> > not be bound to resources since in almost every case an ACL is
> > shared across
> > many resources.
> >
> >
> > I am using the term rights identifier here since the term 
> is empircally
> > defined in the VMS O/S. I have seen the term role used in 
> two contexts,
> > first as a marketeese term for 'rights identifier', second 
> as a rights
> > identifier that can be enabled or disabled at will by the 
> user, in most
> > cases on presentation of additional authentication data.
> >
> >
> > Rather than state 'we don't want to define policy' I think 
> we should state
> > 'we don't want to define a policy language'. I believe that 
> that statement
> > makes clear the implementation complexity threshold we do not
> > want to cross.
> >
> > However it does again point to the need for a re-usable assertion
> > framework
> > since it would be very useful if the wrapper of an ACL 
> could be parsed by
> > the same parser as an SAML assertion.
> >
> > For example from a discussion document I just sent to the 
> core list as an
> > example of what we don't want to do but the type of data a PDP
> > might require
> > as input [I will forward the document to the full list as 
> soon as I have
> > gone through the use case draft to work out the correspondences]
> >
> > <TASS-ACL>
> >    <AssertionID>http://policy.carol.test/assertion/
> >    <Issuer>URN:dns-date:policy.carol.test:2001-03-03:1204
> >    <ValidityInterval>
> >       <NotBefore>
> >       <NotOnOrAfter>
> >    <Resources>
> >       <string>http://store.carol.test/finance
> >    <ACL>
> >       <ACE>
> >          <Subject>
> >
> > <Right>URN:dns-date:www.bizexchange.test:2001-01-04:right:finance
> >          <Permit>RWED
> >       <ACE>
> >          <Deny>ED
> >          <Subject>
> >             
> <Right>URN:dns-date:www.bizexchange.test:2001-01-04:right:ops
> >          <Permit>R
> >       <ACE>
> >          ...
> >
> > Phillip Hallam-Baker
> > Principal Scientist
> > VeriSign Inc.
> > pbaker@verisign.com
> > 781 245 6996 x227
> >
> >
> >
> > >
> > > > -----Original Message-----
> > > > From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
> > > > Sent: Monday, March 12, 2001 7:19 AM
> > > > To: 'security-use@lists.oasis-open.org';
> > > > 'security-core@lists.oasis-open.org'
> > > > Subject: Requirement for Isolated Request for Authorization
> > > Atributes
> > > >
> > > >
> > > > In last week's Core Assertions concall there was some
> > > > discussion about the
> > > > idea of requesting Authorization Attributes for a user who is
> > > > not currently
> > > > logged in. I have a recollection of someone on a Use Case
> > > > concall a few
> > > > weeks ago saying this was an important requirement.
> > > > Unfortunately I do not
> > > > remember who it was. It was pointed out that the current use
> > > > cases do not
> > > > contain this element.
> > > >
> > > > Obviously a request of this type could be used as a performance
> > > > optimization, but does someone have another scenario in mind?
> > > > I hope no one
> > > > is planning to use SAML for provisioning. Based on current
> > > > thinking, I don't
> > > > think this will work.
> > > >
> > > > As I was writing this, I realized that perhaps what was
> > > intended was a
> > > > business transaction scenario, for example: UC-2-08:ebXML,
> > > > currently in the
> > > > issues list. In this case, the PDP may retrieve the
> > > > Authorization Attributes
> > > > after having received an ebXML message from the user.
> > > >
> > > > Are there any other use cases which involve the request of
> > > > Authorization
> > > > Attributes when an Authentication Assertion has not
> > > > previously been issued?
> > > >
> > > > Hal
> > > >
> > > >
> > > >
> > > > 
> ------------------------------------------------------------------
> > > > To unsubscribe from this elist send a message with the 
> single word
> > > > "unsubscribe" in the body to:
> > > > security-use-request@lists.oasis-open.org
> > > >
> > >
> > > ------------------------------------------------------------------
> > > To unsubscribe from this elist send a message with the single word
> > > "unsubscribe" in the body to:
> > > security-use-request@lists.oasis-open.org
> > >
> >
> >
> 

Phillip Hallam-Baker (E-mail).vcf



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


Powered by eList eXpress LLC