RE: [dss] Implicit parameters

[Pieter Kasselman <pkasselman@baltimore.com>]

Hi Trevor, comments in-line

> -----Original Message-----
> From:	Trevor Perrin [SMTP:trevp@trevp.net]
> Sent:	04 October 2003 00:17
> To:	Pieter Kasselman; 'Nick Pope'; OASIS DSS TC
> Subject:	RE: [dss] Implicit parameters
> 
> At 10:57 AM 10/3/2003 +0100, Pieter Kasselman wrote:
> 
> >Hi Nick, thanks for raising this.
> >
> >Expressing implicit parameters in so many diverse ways may lead to
> confusion
> >and will place a burden on us to define which parameters are defined
> where.
> >Once we start doing that we may get trapped in a situation where we try
> to
> >enumerate all possible (implicit) parameters, and are bound to miss a
> few.
> >Options 1 and 2 appear very rigid, while option 3 might be error prone
> >(implying certain signature policies depending on the parameter values
> will
> >require careful mapping and specification).
> >
> >Rather than doing this, it may be easier to allow for a flexible way in
> >which implicit parameters are expressed. One option may be to allow the
> >inclusion WS-Policy or WS-Security policy information in the messages,
> >provided that they are suitable for this purpose. There may be other
> >alternatives as well (e.g allowing reference to implicit parameters
> through
> >a URN may be sufficient). I do not think we need to specify how these
> >implicit parameters are expressed, at least in the first release of DSS,
> but
> >I do think it is useful to allow for these implicit parameters to be
> stated
> >more explicitly and to allow for a mechanism through which they may be
> >discovered (e.g. WS-Policy).
> 
> The term "implicit parameters" is confusing.  I'll explain what I mean by 
> it, and we'll see how this matches up to your and Nick's understanding.
> 
> I meant that:
>   (a) different servers might have different defaults (for which key to 
> use, or what type of signature to produce)
>   (b) different servers might differ in ways that the client can't control
> 
> (maybe the server doesn't allow the client to specify which key to use)
> 
	[Pieter Kasselman]  There is also discovery - a client may need to
know what implicit choices were made (e.g. to determine why the result is
different from separate servers/services).

> So sometimes, the client will get different behavior when sending the same
> 
> request to different servers.
> 
> Now, if a client *wants* to control the server's behavior, in case (a),
> the 
> client just sends a value and overrides the default.
> 
> In case (b), we have a problem: the client needs to control something he 
> doesn't have the option to control.  But maybe the solution isn't to add 
> control over "implicit parameters", but simply to make some "implicit 
> parameters" *explicit*.
> 
> In other words, if there's something the client needs to control, and he 
> can't do it, then we've failed - we need to figure out what clients need
> to 
> do, and add *explicit* support for that in our protocols (or leave 
> extensibility for profiles to add it).
> 
> I guess I think "Expressing implicit parameters" is a 
> contradiction-in-terms.  We have *explicit* parameters, and anything left 
> over is by definition implicit, and hopefully we have the wisdom to make 
> the right things explicit.
> 
> Do you agree?  If so, and if we have too much stuff implicit, could you 
> suggest what else to make explicit?  Do we really need to add a new 
> technology like the WS- things you mention? (I hope not - that just looks 
> like a lot to digest)..
> 
	[Pieter Kasselman]  By providing a mechanism for parameter
selection/parameter inspection we do not have to focus on which parameters
are implicit or explicit or worry that for a certain type of service in a
certain jurisdiction we are failing to communicate a vital parameter because
we can not explicitly communicate that parameter. We may still allow certain
parameters to be set explicitly elsewhere in the protocol, but we have a
flexible mechanism for specifying additional parameters. WS-Policy, is just
one way to express this, and we may simply opt for a URN or a similar
pointer. 

> Trevor 
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster of
> the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.p
> hp.
> 
> 
> 
> This footnote confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.


-----------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any 
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com