Re: assertion classes

Sverdlov, Yakov wrote:
> "... 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.
>   

No, I do not. I used those terms to explain my intentions in the absence 
of suitable terminology defined by WS-Policy.

Fabian


> -----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, 18 October 2006 01:46:04 UTC