RE: [dss] Implicit parameters

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

Nick,

    I tend to agree. This was the point I was trying to make at the
face-to-face, that Pieter has expressed more eloquently. Especially when one
patterns a service (e.g. non-repudiation or notarization) after the DSS
protocol. The ability of the challenger to deny having had control or
knowledge of options can be reduced or eliminated with an approach along the
lines of Pieter's suggestion. Though I think going all the way to WS-Policy
to attain it might be a bit of a challenge.

    I also agree that we have been so wrapped up in the schema that we have
lost sight of the developer's perspective as it pertains to useability and
clarity. Lastly I totally agree with the notion and need to "... allow for
these implicit parameters to be stated more explicitly ...".  

Ed

P.S. The cc: to the list probably won't work.   

-----Original Message-----
From: Pieter Kasselman [mailto:pkasselman@baltimore.com] 
Sent: October 3, 2003 4:57 AM
To: 'Nick Pope'; OASIS DSS TC
Subject: RE: [dss] Implicit parameters

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

Cheers

Pieter

> -----Original Message-----
> From:	Nick Pope [SMTP:pope@secstan.com]
> Sent:	02 October 2003 22:32
> To:	OASIS DSS TC
> Subject:	[dss] Implicit parameters
> 
> Following on from the discussion at the last DSS meeting, views are 
> requested on use of implicit parmaters and other methods for 
> controlling DSS services other than providing each control parameter 
> explicetly.
> 
> There seems to be several mechanisms that can be used with DSS:
> 1) The requirements document mentions use of paramaters being implicit 
> by the URL (see 3.5.9)
> 2) Application profiles can imply use of certain parameters,
> 3) Signature policies (as described by ETSI)can be used to imply 
> certain parameter values
> 4) WS Policies have also been suggested as a mechanism forimplying 
> parameters.
> 
> Are all these methods of implying parameters necessary?  If so in what 
> situations are each method most appropriate?  SHould guidance be 
> included in the DSS spec?
> 
> Nick
> 
> 
> 
> 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_workgro
> up.p
> hp.


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


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
.