Overview of Web Services Profile of XACML (WS-XACML), WD 5

[Anne Anderson - Sun Microsystems <Anne.Anderson@sun.com>]

Colleagues,

My thinking evolved considerably during the development of the draft I 
posted yesterday.  Some major changes since I posted my earlier 
suggestions about this profile (Issue#47) on the XACML mailing list are:

- There is no XACMLPolicyAssertion.  An XACMLAuthzAssertion now covers 
the functionality of both types of Assertions.  This solves a problem in 
matching Assertions, since the two types previously could express the 
same type of assertion information.

- A WS-Policy alternative may contain only one XACMLAuthzAssertion - 
previously, I had envisioned multiple "Apply" elements in separate 
XACMLAuthzAssertions.  Instead, the single XACMLAuthzAssertion may 
contain multiple "Apply" element, a Policy, a PolicySet, or a Request. 
This also addresses the problem of matching XACMLAuthzAssertions between 
two WS-Policy instances.

- An XACMLAuthzAssertion contains two parts: Requirements and Capabilities.
   o Requirements are constraints the other party must satisfy; they 
correspond to XACML policies, although they may also be represented by a 
sequence of "Apply" elements (equivalent to a Condition containing an 
"AND" of the sequence of "Apply" elements).
   o Capabilities are information a party is able and willing to provide 
to satisfy requirements of another party; they correspond to XACML 
requests, although they also may be represented by a sequence of "Apply" 
elements ("I am willing and able to provide any value from this set for 
the Attribute 'role'").

- XACMLAuthzAssertions from two WS-Policy alternatives match if the 
Requirements of each are satisfied by the Capabilities of the other. 
The reason for the asymmetry is to fit the XACML model: a client may 
present many more Attributes in its Request than the service needs to 
satisfy its policy.

- Both clients and services (consumers and providers) may have 
Requirements and Capabilities.  Client Requirements are especially 
important for privacy policies ("you must delete any personal 
information I provide within 30 days").

- Obligations must be represented as constraints on Attributes that 
represent the Obligation, like any other Attribute constraint.  A party 
will include a value or constraint function in its Capabilities for the 
Obligations it is able and willing to fulfill.  A party will include a 
constraint function in its Requirements for Obligations it requires the 
other party to fulfill.  Again, this is important for privacy policies 
in particular.

- There is no longer an XACMLAuthzCredential.  I realized the existing 
SAML Assertion containing an XACMLAuthzDecisionStatementType instance 
serves that purpose, so I simply described this use.

- I added a section on some ways a client might provide Attributes to 
the service in a SOAP Security header as part of the Web Services 
message.  These are not new formats, just descriptions of the use of 
SAML Attribute Assertions or XACMLAuthzDecisionRequests for this purpose.

Regards,
Anne
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692