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

Received on Wednesday, 10 January 2007 18:44:24 UTC