RE: assertion classes

"... the provider owns the policy..."
The specification does not define the policy ownership - correctly in my
opinion.

"...The requester and provider are not categories, they are actors.
There 
can be many more actors, but I wanted to keep this as simple as possible

for now..."
The specification does not define the "actor" category either.

Are you proposing to introduce "actor" and "ownership" in the spec? If
yes, I do not support this.

Regards,

Yakov Sverdlov
CA


-----Original Message-----
From: Fabian.Ritzmann@Sun.COM [mailto:Fabian.Ritzmann@Sun.COM] 
Sent: Wednesday, October 11, 2006 10:51 AM
To: Sverdlov, Yakov
Cc: public-ws-policy@w3.org
Subject: Re: assertion classes

Sverdlov, Yakov wrote:
> Sorry for pushing the same subject again but I would not separate the
> proposed assertion classes into two categories: requester and
provider.
>   

The requester and provider are not categories, they are actors. There 
can be many more actors, but I wanted to keep this as simple as possible

for now.

> 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..."
>   

In the table in the document, the provider owns the policy. The 
requester retrieves the policy. This document does not consider whether 
the requester has a policy of its own or whether assertions need to be 
merged or intersected. If a requester would e.g. "publish an assertion",

it would have either changed its role and become a provider or this 
would be a new class of assertions.

But your remarks make me wonder if there would be use cases where it 
would be necessary to convey which actor owns a policy inside the policy

itself. In simple cases that information can be derived from the context

(a client should know from what web service it read a policy), but it 
might now always be so straight-forward with multiple actors.

Fabian


> -----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
>
>

Received on Wednesday, 11 October 2006 15:28:09 UTC