[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