RE: [dss] Implicit parameters

["Edward Shallow" <ed.shallow@rogers.com>]

I agree with Trevor on all points. If I may, some further elaboration on one
point.

As Trevor stated implicit parameters, whether they come from an
implementation of core or an implementation of some specific profile (like
the EPM for example), are chosen as a result of a client engaging with a
particular DSS Service implementation. This DSS Service implementation may
offer core, core and extended profiles, or just extended profiles.

Depending on which dialect of the DSS Service the client engages with
ultimately determines the selection of implicit parameters. Everything else
is explicitly overriden or specified as detailed in the core (or profile)
specification which will mainfest itself as a WSDL or equivalent.

I sort of like the suggestion that a user explicitly state that they would
like to engage with a specific profile and its associated implicit
parameters, aka policy, aka WS-Policy, aka URN, aka WSDL URL, etc ... They
can not later deny that they consciously were aware of the "terms of
engagement" with the DSS Service.

Ed    

-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net] 
Sent: October 3, 2003 6:17 PM
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)

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 


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