RE: policy stuffing

Actually what I think the client should do in this case is ONLY forward
the UseKeyWith that describes what it wants to do AND NOTHING ELSE.

The use key with data is not authenticated so there is no reason that
the validate service should have the slightest interest in the
information.

So if the client wants to do S/MIME it simply strips out all the
usekeywiths returned in locate and forwards the usekeywith for S/MIME.

The validate service may be interested in the policy info but it will
have to get the data from a trusted source so the request can't be it.

		Phill

> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie]
> Sent: Wednesday, December 04, 2002 10:06 AM
> To: Hallam-Baker, Phillip
> Cc: Daniel Ash; Just.Mike@tbs-sct.gc.ca; reagle@w3.org; 
> www-xkms@w3.org
> Subject: Re: policy stuffing
> 
> 
> 
> 
> > > In that case, I still have to ask whether valid(p1,p2)=>valid(p1)
> > > and regardless of whether that's a "yes" or "no", what goes in
> > > the spec?
> > 
> > OK, I believe the answer is yes.
> 
> So its wrong/a bad idea to define & use p1, p2 & p3 as follows:
> 
> p1: key is generated according to rules a,b,c
> p2: key is good for €1000
> p3: key is good for $1000
> 
> where a responder is configured (howsoever) with the following
> logic:
> 
> if (p1) {
> 	if (p2 || p3) status=notYetInvalid;
> } else {
> 	status=Invalid;
> }
> 
> Does that sufficiently illustrate the quagmire of exposing policy 
> arithmetic? I'm sure equally daft examples could be given if
> you'd said "no" above.
> 
> But, I don't think we need take this further for now (unless someone
> else wants to chime in), until we've text that captures this thread.
> 
> Stephen.
> 
> 
> -- 
> ____________________________________________________________
> Stephen Farrell         				   
> Baltimore Technologies,   tel: (direct line) +353 1 881 6716
> 39 Parkgate Street,                     fax: +353 1 881 7000
> Dublin 8.                mailto:stephen.farrell@baltimore.ie
> Ireland                             http://www.baltimore.com
>