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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dipal-discuss message

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


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


Hi Umit,

Thanks for the clarification.  I am too tainted by XACML ;-), where the
"Subject" of a policy is an entity involved in making, transmitting, or
receiving the results of an access request.  It seems like the XACML
concept of "Resource" is closer to the WS-Policy concept of "Subject":
the entity or object that is being protected or is being accessed.

I will try to use Subject in the WS-Policy sense from here on.

In my mental model of a policy, there are various layers:

Vocabulary: the set of policy variables and their possible values
Assertion: binds a variable to one or more values
Policy: Boolean combinations of Assertions
Binding: binds a Policy instance to a service endpoint

I don't think it makes sense to try to bind a Subject to an individual
Assertion, but only to a Policy as a whole.  In my mental model, it is
the "Binding" layer (e.g. WS-PolicyAttachment, WSPL <Target>) where a
policy is bound to a particular Subject in the WS-Policy sense.

Since DIPAL is proposed as a language for expressing Assertions, I don't
think the functionality of binding to a Subject in the WS-Policy sense
would be included in this language.

Are there other views?

Regards,
Anne

-

Yalcinalp, Umit wrote On 12/20/05 12:03,:
>  
> 
> 
>>-----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
>>
>>

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