Re: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001

[Christopher Ferris <chris.ferris@sun.com>]

David,

Again, you are making an assumption that the "application"
or more specifically the NRR function doesn't have access
to the unadulterated message contents. I think that this is
a false assumption. The specification makes no claims whatsoever
as to what the "application" gets, nor what form that should
take.

You also say:

 > <<Not a problem!  The Application may pass anything it wishes to the MSH.>>


I would respond that the MSH may pass anything to the "application"
that it wishes. We say nothing about the implementation of
the software stack that manifests itself as an MSH + "application"
nor should we, IMO.

The MSH is an abstraction, not a technical specification for an
implementation.

Cheers,

Chris
David Fischer wrote:

> Hi Tony,
> 
> <<comments in-line>>
> 
> Regards,
> 
> David.
> 
> -----Original Message-----
> From: Tony Weida [mailto:rweida@hotmail.com]
> Sent: Sunday, October 21, 2001 8:05 PM
> To: David Fischer; CPPA
> Subject: Re: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001
> 
> 
> David,
> 
> I've embedded a couple comments below, prefixed with my initials.
> 
> Cheers,
> Tony
> 
> ----- Original Message -----
> From: David Fischer
> To: CPPA
> Sent: Sunday, October 21, 2001 6:32 PM
> Subject: RE: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001
> 
> 
> Sorry I missed the meeting, it didn't make it onto my calendar.
> 
> Comments:
> 
> If end-to-end, signed Acknowledgment is requested, it provides NRR -- in the
> same way DeliveryReceipt does.  NRR cannot be provided at the
> BPSS/Application level since MSH does not pass the entire message and thus
> the Application cannot generate the required Digest(s).
> 
> TW: That seems like a strong statement.  Signing the entire message is
> sufficient, but is it always necessary?  I understand that messaging
> elements may convey information relevant for non-repudiation, e.g., a
> timestamp.  Such information may also appear in a particular type of
> business payload.
> 
> <<In order for NRR to work, it must EXACTLY match the original signature
> digests -- which includes the MSH headers.  Since the Application doesn't have
> those headers, it cannot generate those digests.  This does not mean that the
> Application might not do something similar with only the payload.  Messaging
> does not stipulate what can be in the payload.  If the Application wants to do
> something like sign/encrypt the payload prior to passing to the MSH, it can.
> However, this is not NRR.  This is more like some subset of the original
> digests/ds:Signature, so the original signature will not match.  In any case,
> the Application can do whatever it likes and the MSH will provide NRR, if a
> signed Acknowledgment is requested.>>
> 
> 
> Since the MSH does not do any application parsing, any Business Level
> receipts cannot be done at the MSH level.  While the Application cannot do
> NRR, it can/must provide anything along the lines of "Message verified/being
> processed" (i.e. Delivery Receipt).  The Application would pass this signal
> to the MSH with a flag which says "sign this".  While it would not be
> illegal for the Application to send a signed/encrypted payload to the MSH
> (would this be S/MIME?), it is not within our model to do so.
> 
> TW: I expect that some security-sensitive applications will call for
> transmitting encrypted content between authorized persons or applications,
> not just between their respective MSHs.  The latter is more likely to
> compromise security, for example by exposing confidential information to
> unauthorized persons within an enterprise.
> 
> <<Not a problem!  The Application may pass anything it wishes to the MSH.>>
> 
> An Acknowledgment can be requested separately from Reliable Messaging
> although the only difference is duplicateElimination.
> 
> I think/agree that MSH signals should be returned synchronously for HTTP.
> This should be the default.  Maybe we don't need a flag, just make this a
> requirement (Why would this ever be done asynchronously for HTTP?)  I think
> I agree with Dale.  This should match the transport method (sync for HTTP,
> async for SMTP) and should not change per message.
> 
> Regards,
> 
> David Fischer
> Drummond Group.
> 
> -----Original Message-----
> From: Tony Weida [mailto:rweida@hotmail.com]
> Sent: Saturday, October 20, 2001 5:05 PM
> To: CPPA
> Subject: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001
> 
> 
> Draft minutes of the October 18 teleconference are attached.  Please send me
> any additions or corrections.
> 
> Cheers,
> Tony Weida
> Independent CPPA Fan :-)
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>