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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-use message

[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