RE: [dipal-discuss] FAQ: what are the basic Assertion functions, and how are they provided?

["Yalcinalp, Umit" <umit.yalcinalp@sap.com>]

> -----Original Message-----
> From: Anne Anderson [mailto:Anne.Anderson@sun.com] 
> Sent: Monday, Dec 19, 2005 5:44 PM
> To: Yalcinalp, Umit
> Cc: Frank McCabe; dipal-discuss@lists.oasis-open.org
> Subject: Re: [dipal-discuss] FAQ: what are the basic 
> Assertion functions, and how are they provided?
> 
> Hi Umit,
> 
> The following are some examples of web services policies with 
> no subject 
> (or where subject identity is not relevant).  Some use subject 
> attributes other than the subject's identity, whereas others do not 
> depend on any characteristics of the subject at all.
> 

Perhaps our concepts of Subject were somewhat different and that was
what I was trying to tease out.  I was getting at Policy Subject as a
"Type", indicating where a specific Policy may apply, such as Endpoint,
vs. Subject instance a specific endpoint, service, etc. I may be too
tainted by WS-Policy ;-)

For example, a reliable messaging policy would specify that it will
apply to (as it is currently specified) to an endpoint. Endpoint does
not designate the specific instance, but where the policy may apply.
This applies to example 1 below. 

My point was that you may not be able to process the policy if you do
not specifically identify the type of Subject that it applies to,
endpoint, message, etc. and hence there is always a set of permissable
Policy Subjects (Types) when a policy is created. This applies to the
examples that you have given below, too. 

The WS-Policy Framework designates a set of Policy Subjects based on
WSDL component model only. I imagine there are probably additional
Policy Subjects that would exist since these set of Subjects are very
WSDL (hence service) centric, but IMO one would always construct
policies with specific set of possible Policy subjects in mind. 

Informational policies (those that do not affect the wire protocol
between a client and a service) are included in this as well, such as
your example (3) below. IMO, for this example the Policy Subject is
still an endpoint as it applies to all the message exchanges that a
service exhibits at that endpoint, regardless of this policy is enforced
at the binding or designed as part of the application (hence part of the
implementation of the interface). 


> 1) A service interface that will respond to any requester; the policy 
> specifies reliable messaging parameters; or a service interface that 
> will respond to any requester so long as they supply a public key by 
> which the response can be encrypted.
> 
> 2) A service interface that will respond to anyone able to present an 
> Attribute certificate associated with the IP address of the source 
> saying the source is a "Gold" level subscriber.
> 
> 3) A service that will respond to any requester so long as 
> its own CPU 
> is less than 50% utilized.
> 
> 4) A service interface where access depends only on the requester's 
> "role" Attribute, or only on the time of day and the subject's "age" 
> Attribute.
> 
> Regards,
> Anne

Hope this explains what I was trying to get at. 

Cheers, 

--umit

> 
> Yalcinalp, Umit wrote:
> >  
> > 
> > 
> >>-----Original Message-----
> >>From: Anne Anderson [mailto:Anne.Anderson@sun.com] 
> >>Sent: Monday, Dec 19, 2005 2:25 PM
> >>To: Frank McCabe
> >>Cc: dipal-discuss@lists.oasis-open.org
> >>Subject: Re: [dipal-discuss] FAQ: what are the basic 
> >>Assertion functions, and how are they provided?
> >>
> >>Hi Frank,
> >>
> >>These are good points.  I think they touch partly on expressivity
> >>requirements for a policy Assertion language and partly on an
> >>appropriate division of functionality between the Assertions and the
> >>policy framework in which Assertions are used.
> >>
> >>For issuer information, I envision this expressed at the policy
> >>framework level (or even the policy metatdata level - the policy
> >>envelope), and not the Assertion level.  An entire policy, 
> >>including all
> >>its Assertions, would be issued by the one issuer identified at the
> >>policy or policy metadata level.  Since we are discussing 
> an Assertion
> >>language to be used within some externally-specified policy 
> framework
> >>language, I did not include this functionality in the list of "basic
> >>functions" for an Assertion itself.
> >>
> >>For subject information, there are at least three 
> approaches.  1) The
> >>identity of the subject is not always relevant for a web services
> >>policy, so I don't think all policies will include a "subject".  
> > 
> > 
> > Hi Anne, 
> > 
> > Could you elaborate on (1) a bit ? I am trying to imagine 
> the situations
> > how a policy subject may not be relevant. I can imagine 
> that a policy
> > may apply to several subjects #Subject >=1, but it is a bit 
> hard for me
> > to imagine situations where the subject is never relevant 
> (i.e. #Subject
> > = 0). I am not sure why a policy will exist if there is no policy
> > subject.
> > 
> > Or did you mean that a policy subject is beyond WSDL component model
> > attachment(if we were to take WS-Policy as an example...) ? 
> > 
> > Thanks, 
> > 
> > --umit
> 
> -- 
> Anne H. Anderson               Anne.Anderson@sun.com
> Sun Microsystems Labs          1-781-442-0928
> Burlington, MA USA
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dipal-discuss-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: 
> dipal-discuss-help@lists.oasis-open.org
> 
>