W3C home > Mailing lists > Public > public-ws-policy@w3.org > September 2006

Re: Policy expressions with no wire manifestation

From: Anthony Nadalin <drsecure@us.ibm.com>
Date: Wed, 20 Sep 2006 08:28:00 -0500
To: "Sergey Beryozkin" <sergey.beryozkin@iona.com>
Cc: public-ws-policy@w3.org, public-ws-policy-request@w3.org
Message-ID: <OF7B498489.75FAE74A-ON862571EF.0049A134-862571EF.0049F9C1@us.ibm.com>

The requestor might want to express that it needs the end point subject to
support Reference Key Identifiers as defined in WSS 1.0, the end point
subject can make the same requirements
     <sp:MustSupportRefKeyIdentifier />
     <sp:MustSupportRefIssuerSerial />

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122

             <sergey.beryozkin                                          To 
             @iona.com>                Anthony Nadalin/Austin/IBM@IBMUS    
             Sent by:                                                   cc 
             public-ws-policy-         <public-ws-policy@w3.org>,          
             request@w3.org            <public-ws-policy-request@w3.org>   
                                       Re: Policy expressions with no wire 
             09/20/2006 08:19          manifestation                       

Can you please explain when and how a requester would use
<sp:MustSupportRefKeyIdentifier />

Thanks, Sergey Beryozkin
Iona Technologies

 In WS-SecurityPolicy we have an assertion like
 <sp:MustSupportRefKeyIdentifier />, this is not marked as wsp:optional and
 does has no effect on the actual communication, if there is not a
 intersection then it will fail. I don't understand why you think that
 assertions that have no effect on the actual communication need to be
 marked as wsp:optional.

 Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
 Inactive hide details for "Sergey Beryozkin" <sergey.beryozkin@iona.com>
 "Sergey Beryozkin" <sergey.beryozkin@iona.com>

                         ozkin@iona.                                    To 
                         Sent by:           "Sergey Beryozkin" <           
                         public-ws-p        sergey.beryozkin@iona.com>,    
                         olicy-reque        Anthony                        
                         st@w3.org          Nadalin/Austin/IBM@IBMUS       
                         04:35 AM           <public-ws-policy@w3.org>,     
                                            Re: Policy expressions with no 
                                            wire manifestation             

 Hi there

 That was a response in a hurry so I take it back. Before flooding the
 group concalls with trivial issues I'd rather attempt to make my question
 as clear as possible. Note that I may indeed be confused, but if so then
 I'd appreciate an answer which would help.

 Consider this example :

 <TheBestServiceInThisCategory verifiedBy="..."/>

 This is an example of a policy with a single alternative. This alternative
 contains non-optional assertions
 defined by a policy profile spec published a month ago. These assertions
 have no wire manifestations.
 A ws-policy aware (requester) entity whose runtime has not been updated
 yet to recognize <oasis:QOSGuarantee> is about to start communicating with
 the service which advertizes this policy.

 Given the fact that it's likely ws-policy aware requesters will refuse to
 start talking to a service should they fail to support the above policy
 and that the fact whether this requester supports this policy or not will
 have no effect on the actual communication with the service this policy
 attached to, my understanding is that such assertions with no wire
 manifestations SHOULD be marked as wsp:optional :

 <oasis:QOSGuarantee wsp:optional="true">
 <!-- -->

 This means a requester may use this policy for a service selection but
 doesn't need to refuse talking to this service should it fail to recognize
 the policy.

 Does it make sense ?
 What is the group's position on this issue ?


 Sergey Beryozkin
 Iona Technologies

(image/gif attachment: graycol.gif)

(image/gif attachment: pic17771.gif)

(image/gif attachment: ecblank.gif)

(image/gif attachment: 27987122.gif)

(image/gif attachment: 27447894.gif)

Received on Wednesday, 20 September 2006 13:29:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:27 UTC