MHonArc v2.5.0b2 -->


















xacml message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








Subject: RE: [xacml] FW:  SAML AI 0076 - XACML Policy Transport




From: Anne Anderson <Anne.Anderson@Sun.com>
To: "Hal Lockhart" <hlockhar@bea.com>
Date: Wed, 15 Oct 2003 12:04:20 -0400






I think all it would take to define a generic "PolicyStatement"
is something the following:

  <xs:complexType name="PolicyStatementType">
     <xs:complexContent>
       <xs:extension base="saml:StatementAbstractType">
         <xs:sequence>
           <xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute name="PolicyType" type="xs:anyURI"
use="required"/>
       </xs:extension>
     </xs:complexContent>
  </xs:complexType>

Then add

  <element ref="saml:PolicyStatement"/>

to the list of choices for an "AssertionType", and define

  <element name="PolicyStatement" type="PolicyStatementStype">

This give SAML a generic "Policy Statement" syntax.

For XACML use, we then define two "PolicyType" URI's:

 urn:oasis:names:tc:xacml:1.0:policy - content is an XACML Policy
 urn:oasis:names:tc:xacml:1.0:policyset - content is an XACML PolicySet

Other policy languages could define other PolicyType URIs.

We would define <PolicyIdQuery> and <PolicyTargetQuery> similarly.

Would this be more generally useful?  I like the idea of a
standard "Policy Statement" and "Policy Query" included in SAML.

Anne
     
On 15 October, Hal Lockhart writes: RE: [xacml] FW:  SAML AI 0076 - XACML Policy Transport
 > From: "Hal Lockhart" <hlockhar@bea.com>
 > To: <xacml@lists.oasis-open.org>
 > Subject: RE: [xacml] FW:  SAML AI 0076 - XACML Policy Transport
 > Date: Wed, 15 Oct 2003 11:39:07 -0400
 > 
 > On the SAML call yesterday (10/14) the few people who expressed an opinion
 > felt that this was more appropriate to do in XACML. They felt that if we
 > wanted to introduce an abstract "policy" element which could contain any
 > kind of policy, not just XACML and then define the XACML constructs below
 > that, it might make sense to have SAML define abstract policy layer.
 > Otherwise the feeling was this was more appropriate to do in XACML.
 > 
 > Unless somebody feels the abstract policy layer is important, I suggest we
 > simply do it as described below. If at a future time there is a push for an
 > abstract layer, we can adjust accordingly. DOing it in the XACML TC will
 > also make it easier to deal with any interactions with other proposed 2.0
 > changes, such as to Target.
 > 
 > My feeling is that this will have to be a separate profile. Any opinions on
 > this?
 > 
 > Hal
 > 
 > >