- 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
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic24676.gif
- image/gif attachment: ecblank.gif
Received on Wednesday, 10 January 2007 19:15:20 UTC