RE: Requirement for Isolated Request for Authorization Atributes

[Philip Hallam-Baker <pbaker@verisign.com>]

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