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] comments on DSS requirements


Comment on comments in-line :)

> -----Original Message-----
> From:	Trevor Perrin [SMTP:trevp@trevp.net]
> Sent:	19 July 2003 23:29
> To:	Nick Pope; Frederick.Hirsch@nokia.com; dss@lists.oasis-open.org
> Subject:	RE: [dss] comments on DSS requirements
> 
	<snip>
> > >
> > >
> > > >----
> > > >3.7.4
> > > >
> > > >We mention policy a lot and that can mean different things. Do we
> mean a
> > > >URI and the rest is out of scope,
> > >
> > > We now have "Implicit Parameters" (3.5.6 and 3.7.8), which are
> > > things that
> > > are selected just by which URI you access.  We aren't calling
> > > these things
> > > policies anymore, cause that was confusing.
> >
> >I am not sure whether we are throwing away too much by just ignoring
> >"policies".  I think that we do need to have the concept of something
> that
> >defines the rules under which the signature is created / verified.
> 
> According to the doc, there's an "Application Profile", and which 
> application profile is used is determined implicitly by which URI you 
> access the server at.
> 
> So if the "Application Profile" defines all these rules (for example, EPM 
> could be an application profile, as would eNotary), and the URI determines
> 
> the application profile, is that sufficient?
> 
	[Pieter Kasselman]  By moving away from the explicit idea of a
policy we are loosing flexibility in the system. The use of application
profile is only a partial solution, for instance, a profiled service may
offer multiple policies under which signatures can be generated/validated.
Thus by co-locating the application with the policy we are preventing the
application from offering multiple policies under which signatures are
generated/verified. 

	Including an element in the request/response message that allows for
a policy to be specified as a URI allows policy information to be
communicated, regardless of application profile (and even within an
application profile). We do not need to be explicit regarding the expression
of policy at this stage, although we may choose to adopt a relevant policy
expression language at a later date. As a consequence I would like to see
the concept of identifying a policy clearly captured in the requirements
document.

	</snip> 



> 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



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