RE: [dss] Implicit parameters

[Trevor Perrin <trevp@trevp.net>]

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)

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)..

Trevor