W3C home > Mailing lists > Public > public-ws-policy@w3.org > January 2007

Re: NEW ISSUE 4130: Ignorable assertions must be ignored

From: Anthony Nadalin <drsecure@us.ibm.com>
Date: Wed, 10 Jan 2007 12:29:07 -0600
To: Fabian Ritzmann <Fabian.Ritzmann@Sun.COM>
Cc: Ashok Malhotra <ashok.malhotra@oracle.com>, Fabian.Ritzmann@Sun.COM, public-ws-policy@w3.org, public-ws-policy-request@w3.org, Sergey Beryozkin <sergey.beryozkin@iona.com>
Message-ID: <OF4647E7DF.AB3EE08D-ON8625725F.00653C20-8625725F.00658B18@us.ibm.com>





I think that this is wrong approach if we want to support "informational"
or "ignorable" assertions.

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122


                                                                           
             Fabian Ritzmann                                               
             <Fabian.Ritzmann@                                             
             Sun.COM>                                                   To 
             Sent by:                  Anthony Nadalin/Austin/IBM@IBMUS    
             Fabian.Ritzmann@S                                          cc 
             un.COM                    Sergey Beryozkin                    
                                       <sergey.beryozkin@iona.com>, Ashok  
                                       Malhotra                            
             01/10/2007 11:32          <ashok.malhotra@oracle.com>,        
             AM                        public-ws-policy@w3.org,            
                                       public-ws-policy-request@w3.org     
                                                                   Subject 
                                       Re: NEW ISSUE 4130: Ignorable       
                                       assertions must be ignored          
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Anthony Nadalin wrote:
>
> So with Lax and Strict what is the usecase for ignorable ? as with Lax
> you can make the choice to ignore the fact there is not an intersection
>

Lax only allows to ignore assertions in intersection if they are marked
as Ignorable. Strict does not look at Ignorable at all and works as the
original intersection algorithm.

Fabian



> Inactive hide details for "Sergey Beryozkin"
> <sergey.beryozkin@iona.com>"Sergey Beryozkin" <sergey.beryozkin@iona.com>
>
>
>                         * "Sergey Beryozkin"
>                         <sergey.beryozkin@iona.com> *
>                         Sent by: public-ws-policy-request@w3.org
>
>                         01/08/2007 12:35 PM
>
>
>
> To
>
> "Ashok Malhotra" <ashok.malhotra@oracle.com>, <public-ws-policy@w3.org>
>
> cc
>
>
> Subject
>
> Re: NEW ISSUE 4130: Ignorable assertions must be ignored
>
>
>
>
> Hi
>
> " - ASSERTIONS THAT THE OTHER PARTY SHOULD NEVER SEE
> Such as logging. These are private to my implementation.
> Glen: Such assertions should be removed prior to intersection and
> never exposed to the other party.
> Ashok: They can be included in the policy and always 'ignore' d. "
>
> S.B. Ashok what you're suggesting is exactly what we were trying to
> pursue with our wsp:local proposal, without success :-). We wanted a
> standard attribute which can be used to mark private assertions (would
> be useful for writing generic tools, etc), furthermore we were
> agreeing that such assertions must be stripped of, but ignored by
> requesteres if leaked (inadvertently or due to some constraints).
> Now that we have wsp:ignorable I don't see a way of getting back...So
> I agree with Glen.
>
> As was noted before, you can now use a lax mode if you want your
> provider assertions be ignored. Otherwise, why to expose assertions
> which need to be always ignored ? Assertions are for requesters.
>
> "
> - ASSERTIONS THAT CANNOT BE MATCHED BY MACHINE
> A: I think these are useful to include in policies for advertising.
> For example, legal or privacy policies. Users cannot match on these
> but will look at them and decide whether to use a particular service
> or not based on their contents.
> These too must be always 'ignore' d during intersection.
> G: Such assertions should not be included in policies but, rather,
> included in some other metadata bucket.
> A: But we have not defined any other metadata buckets. "
>
> S.B. I agree that these are useful to include in policies for
> advertising. Two options :
> * Make these assertions as "ignorable" and use the lax mode to handle
> such policies. This will require a smart requester UI tool which will
> offer users a chance to vote on "ignorable" provider assertions which
> have not been understood during the intersection.
> * As Tom noted, you can use a strict mode too. This will require
> requesteres though to be aware of these assertions in advance.
>
> "- ASSERTIONS THAT THE OTHER PARTY MAY BE ABLE TO MATCH
> G: If he can match the assertions, great! If not, he should be able to
> proceed even if he cannot match. This is the rationale for lax and
> strict matching.
> A: I accept this usecase but that's not what I was thinking of."
>
> So if you agree with Glen here then I'm not qute sure what exactly is
> your scenario...
>
> Thanks, Sergey
>
>
>
>
> Glen Daniels and I had a chat about 'ignorable'.
>
> It turns out, not surprisingly, that we had different usecases in mind
> and different ideas as to how they should be handled.
>
> Here is a summary of our positions. Please respond if you have views on
> them.
>
> Glen, please correct me if I have misrepresented your positions.
>
> - ASSERTIONS THAT THE OTHER PARTY SHOULD NEVER SEE
> Such as logging. These are private to my implementation.
> Glen: Such assertions should be removed prior to intersection and
> never exposed to the other party.
> Ashok: They can be included in the policy and always 'ignore' d.
>
> - ASSERTIONS THAT CANNOT BE MATCHED BY MACHINE
> A: I think these are useful to include in policies for advertising.
> For example, legal or privacy policies. Users cannot match on these
> but will look at them and decide whether to use a particular service
> or not based on their contents.
> These too must be always 'ignore' d during intersection.
> G: Such assertions should not be included in policies but, rather,
> included in some other metadata bucket.
> A: But we have not defined any other metadata buckets.
>
> - ASSERTIONS THAT THE OTHER PARTY MAY BE ABLE TO MATCH
> G: If he can match the assertions, great! If not, he should be able to
> proceed even if he cannot match. This is the rationale for lax and
> strict matching.
> A: I accept this usecase but that's not what I was thinking of.
>
> All the best, Ashok
>
> > -----Original Message-----
> > From: public-ws-policy-request@w3.org
> <mailto:public-ws-policy-request@w3.org> [mailto:public-ws-policy-
> > request@w3.org <mailto:request@w3.org> ] On Behalf Of Ashok Malhotra
> > Sent: Tuesday, January 02, 2007 6:37 AM
> > To: public-ws-policy@w3.org <mailto:public-ws-policy@w3.org>
> > Subject: NEW ISSUE 4130: Ignorable assertions must be ignored
> >
> >
> >
> >
> > Title
> >
> > Ignorable assertion must be ignored
> >
> > Description
> >
> > At the last f2f meeting the WS-Policy WG agreed to add an attribute
> called
> > 'ignorable' to the WS-Policy assertion syntax. We think this is a
> step in
> > the right direction. The WG, however, blunted the effect of this change
> > by
> > allowing the ignorable attribute to be ignored during policy
> intersection
> > by
> > allowing two intersection modes one of which honors the ignorable
> > attribute and the other which ignores it.
> >
> > We argue this creates a problem as the parties attempting to agree on a
> > policy alternative may use different forms of the intersection
algorithm
> > and come up with different solutions. A standard that allows such
> > variation is not very useful.
> >
> > We suggest that the policy intersection algorithm be changed so that
> > assertions marked ignorable are always ignored.
> >
> > Justification
> >
> > See above.
> >
> > Target
> >
> > WS-Policy Framework
> >
> > Proposal
> >
> > 1. In section 4.5 Policy Intersection, add a third bullet after the
> first
> > two bullets that says:
> > o Assertions with ignorable = 'true' are ignored in during policy
> > intersection.
> >
> > 2. Remove the first bullet, including its sub-bullets from the
> second set
> > of 2 bullets.
> >
> > 3. Add an ignorable assertion to the following example.
> >
> >
> >
> >
>


--
Fabian Ritzmann
Sun Microsystems, Inc.
Stella Business Park             Phone +358-9-525 562 96
Lars Sonckin kaari 12            Fax   +358-9-525 562 52
02600 Espoo                      Email Fabian.Ritzmann@Sun.COM
Finland






graycol.gif
(image/gif attachment: graycol.gif)

pic24676.gif
(image/gif attachment: pic24676.gif)

ecblank.gif
(image/gif attachment: ecblank.gif)

Received on Wednesday, 10 January 2007 19:15:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:45 GMT