In today's meeting, I offered to summarize how "obligations" are treated
in WS-XACML. I tried to provide minimal background for those of you who
have not read the WS-XACML profile.
XACML Assertions
================
An XACML Assertion (either XACMLAuthzAssertion or XACMLPrivacyAssertion)
has a "Requirements" element and a "Capabilities" element. Requirements
state what the asserter requires of the other party; Capabilities state
what the asserter is able and willing to do for the other party if those
Requirements are met. Two XACML Assertions match if every Requirement
in each is satisfied by at least one Capability in the other.
Requirements can take any of the following forms:
A regular XACML Policy or PolicySet
A sequence of XACML Apply elements (with some limitations on form)
Capabilities can take any of the following forms:
A regular XACML Request
A sequence of XACML Apply elements (with some limitations on form),
An XML document (for example a P3P privacy policy)
A sequence of Apply elements in Requirements are logically ANDed
together. A sequence of Apply elements in Capabilities are logically
ORed together. If two parties match their Assertions, the Capabilities
that are needed to satisfy the Requirements of the other party
effectively become requirements on the asserter so in the "matched" form
of an Assertion they are ANDed (this is not made clear in the current
WS-XACML draft).
Obligations in XACML Assertions
===============================
An XACML Policy or PolicySet used in Requirements can include regular
XACML Obligations, just as described in the XACML Core (this is not made
clear in the current WS-XACML draft).
Policies and capabilities stated in the form of a sequence of Apply
elements are intended for use with fairly simply policies, and where
automated matching of consumer and provider policies is needed. When
you are trying to match consumers with compatible providers, it is
necessary to know up front which Obligations the other party is able and
willing to fulfill - the consumer and provider don't really match unless
they are able and willing to satisfy Obligations of the other party.
So there is no special element for "Obligations" when a sequence of
Apply elements is used - an obligation is expressed as a regular XACML
Attribute.
Example
=======
An Internet Ticket Service uses an XACMLPrivacyAssertion to state its
requirements for Personal Identifying Information (PII) and to state the
privacy guarantees (Capabilities) it is able and willing to provide in
return. Here is what the XACMLPrivacyAssertions for such a Ticket
Service and for a potential customer might look like:
XACMLPrivacyAssertion (TicketService)
Requirements
Provide name
Provide street address
Provide credit card number
Capabilities
PURPOSE:PII used internally only for this transaction
RETENTION:PII kept only until transaction completed
RECIPIENT:PII not given to any 3rd party
[These Capabilities are all expressed as a P3P Policy document]
XACMLPrivacyAssertion (customer)
Requirements
RETENTION:PII kept only until transaction completed
RECIPIENT:PII not given to any 3rd party
Capabilities
Provide name
Provide street address
Provide credit card number
Provide telephone number
Note that the customer's "Requirements" are really "obligations" to be
fulfilled by the TicketService. Likewise, the TicketService's
"Capabilities" are really "obligations" that the TicketService is able
and willing to fulfill.
These two Assertions match - every Requirement is satisfied on both
sides. There is one Capability on each side that is not needed for this
interaction, so the "matched" versions of the Assertions to be used by
this TicketService and this customer for this interaction do not include
the "unnecessary" Capabilities. All the remaining Capabilities are
logically ANDed (all must be satisfied) once an agreement match has been
made with a specific other party.
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