RE: [dss] Comments on Core WD 01 3 Oct 03

[Pieter Kasselman <pkasselman@baltimore.com>]

Instead of dropping the use of <DocumentURI> (and possibly excluding certain
use cases/requirements), we can add a security warning and make support for
this element optional, leaving it as a service policy decision on whether it
supports this type. If it does not support this mode, it can simply respond
with a <Status>RequestDenied</Status> and an appropriate <StatusMessage/>.

Cheers

Pieter

> -----Original Message-----
> From:	Nick Pope [SMTP:pope@secstan.com]
> Sent:	17 October 2003 15:13
> To:	OASIS DSS TC
> Cc:	Juan Carlos Cruellas
> Subject:	RE: [dss] Comments on Core WD 01 3 Oct 03
> 
> We have discussed the question raised below regarding policy for adhering
> to
> the DSS requirements document and the proposal is that:
> 
> Changes can be made in the DSS Schema to the requirements identified in
> the
> earlier DSS Requirements document provided that:
> a) The change to the existing requirement to brought to the attention of
> the
> DSS group through the e-mail list,
> b) Any relevant use cases that relate to the requirement should be
> identified
> c) No major objections are raised in response
> 
> Nick Pope & Juan Carlos - DSS Chairs
> 
> >
> > Nick
> >
> > -----Original Message-----
> > From: Trevor Perrin [mailto:trevp@trevp.net]
> > Sent: 15 October 2003 23:46
> > To: Rich Salz
> > Cc: Nick Pope; OASIS DSS TC
> > Subject: Re: [dss] Comments on Core WD 01 3 Oct 03
> >
> >
> > At 06:15 PM 10/15/2003 -0400, Rich Salz wrote:
> >
> > > > Drop the <DocumentURI> and just have <Document> and <DocumentHash>?
> > >
> > >yes.
> > >
> > > > I dunno..  I'm always in favor of simplifying, but having a
> > URI option was
> > > > in the requirements doc.
> > >
> > >Aren't we allowed to not meet some requirements? :)
> >
> > I'll leave that for the chairs, I dunno :-).
> >
> > Let's try to figure out why we added it, though.  As far as I can tell,
> > Gregor Karlinger suggested it:
> > http://lists.oasis-open.org/archives/dss/200301/msg00016.html
> > """
> > 2.3.2 Signed Data: Reference or direct provision
> >
> > Data items to be signed/validated should be either provided
> > to the service as a reference (URI), or directly as part of
> > the request. The latter is important for situations where
> > the data to be signed cannot be located by resolving a URI.
> > """
> >
> > You were skeptical:
> > http://lists.oasis-open.org/archives/dss/200301/msg00017.html
> > """
> > In some (many? :) cases, a DSS service will not be willing to retrieve
> > data from arbitrary URL's on behalf of a client.  In this case, the
> > client must be able to "push" the data, along with an indicator of the
> > URL of the data.
> >
> > Extending on this, a DSS service might be asked to verify a signature
> > where it does not have the privileges to read the source document. A
> > "just trust the References" mode would allow such a service to operate.
> > """
> >
> > But that's all the discussion there was.  Then I put it in the
> > 1st draft of
> > the requirements doc, and there it stayed cause no-one found it
> offensive
> > enough to complain about.
> >
> > I don't really see the use of this - it seems kinda unnecessary,
> > since the
> > client could always just hash the website on its own and send the hash.
> >
> > So I lean your way, we could take this out.  Does anyone want it or see
> a
> > real use for it?
> >
> > 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.p
> hp.
> 
> 
> 
> 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