OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]