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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Obligations in WS-XACML


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]