[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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 > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC