RE: assertion classes

"In at least one domain, "obligations" are widely used, such as XACML.
Although the XACML model is much more refined, the overall semantics of
obligations should become clear. The following table provides a
simplified list of assertion classes."

Sorry for pushing the same subject again but I would not separate the
proposed assertion classes into two categories: requester and provider.
One can argue that it is possible to change the second column's title
from "Provider" to "Requester" i.e. the requester's assertions can also:
- "Implement behavior mandated by assertion"
- "Implement behavior mandated by assertion, may publish assertion"
- "Publish assertion"
- "Support behavior mandated by assertion"
etc

The same exercise can be performed with the third column. You can switch
the title from "Requester" to "Provider", and the content below will be
applicable without significant changes.

As Anne Anderson correctly stated in her email
http://lists.oasis-open.org/archives/xacml/200610/msg00015.html,
"...Both clients and services (consumers and providers) may have
Requirements and Capabilities..."

Regards,

Yakov Sverdlov
CA

-----Original Message-----
From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Fabian Ritzmann
Sent: Tuesday, October 10, 2006 1:32 PM
To: public-ws-policy@w3.org
Subject: assertion classes

Hi,

I tried to assemble a few characteristics of different classes of 
assertions in the attached paper. This represents a very simplistic 
view, but I hope it can help to untangle some tarballs and gain more 
clarity in the discussions on optionality, advisory, and local policies 
and assertions.

Fabian

-- 
Fabian Ritzmann
Sun Microsystems, Inc.
Stella Business Park             Phone +358-9-525 562 96
Lars Sonckin kaari 12            Fax   +358-9-525 562 52
02600 Espoo                      Email Fabian.Ritzmann@Sun.COM
Finland

Received on Wednesday, 11 October 2006 12:31:25 UTC