RE: [ebxml-dev] signed acknowledgement - BSI's role?

["Damodaran, Suresh" <Suresh_Damodaran@stercomm.com>]

The model I find convenient to use is the following

application/service <--> MSH<--> Communication protocol handler
			   BSI     Binding

where the service layer/MSH communication takes place using BSI.
Thus, BSI supports communication in both directions.
We may call MSI as the part of BSI that lets service layer
talk to MSH. In any case, I would not waste time splitting hair
on how much of BSI is MSI and so on and so forth:-)

As for the service layer's relationship MSH acknowledgement,
there is at least one instance where the service layer will
find it useful to have access to MSH acknowledgement:
when an application wants to use a signed acknowledgement
it received from the otherParty MSH for non-repudiation later.
The advantage of persistent signature is too good to waste.

A difficulty arises when we try to map business transactions (BPSS like)
to MSH responses/signals. Mapping from a business signal
has to be done to a MSH response, if we prohibit MSH ack from being used 
as business ack. The ebMS spec does not prohibit such use, though
it clearly states that these two acks (i.e., business/MSH) are different.
I would, therefore, conclude for now MSH can do ack by itself,
though the use of the ack (based on the mapping done) in the application
layer is application/implementation dependent. I.e., if the application
recognizes
that only a structurally valid receipt of a message is 
valid acknowledgement, then it has to use the business level acknowledgement
that will arrive in a MSH response. (I don't know whether there is
a good way to send business ack and business response together.
May be Hima/Duane can speak to it from BPSS point of view.)

On the original question of MSH having access to the private keys,
as someone who has helped create an MSH, I have this to say.
The way the current spec is, it makes sense for MSH to have
direct access to the keys. The vulnerability issue is not any worse
(may be better) than keys for SSL. The solution is to
find whatever you are comfortable from a deployment/security/performance
point of view.

On the related question on "does the application play a role in signed
acks,"
I think the answer is: yes. Typically the certificateIds are pointed to by
CPA
(used by MSH to get the certs) 
that is drawn up between parties, which may be applications. Thus,
the certificates used may vary between apps even though the same parties
are involved. Any different views on this?

Cheers,
-Suresh  

-----Original Message-----
From: Himagiri(Hima) Mukkamala [mailto:himagiri@sybase.com]
Sent: Friday, May 03, 2002 1:13 AM
To: Duane Nickull
Cc: ebxml-dev@lists.ebxml.org
Subject: Re: [ebxml-dev] signed acknowledgement - BSI's role?


I do agree that there exists a technical/service interface for BSI,
but my take on this would be , BSI layer would use
a MSH API for interacting at the service layer.

Taking JAXM as an example, BSI could use JAXM with
an ebxml profile to use ebXML messaging as the service layer.

This doesn't mean that BSI sends the Transport level
acknowledgments, it's still the MSH taking care
of Transport level acks. This way the abstaraction is at
the messaging layer.

For discussion sake, if there was BSI using MQ as the
service/messaging layer, BSI would use MQ layer
to transfer messages, but would not dictate how
MQ level acks are exchanged.

-hima

Duane Nickull wrote:

> The BSI is built of two components - the Business Interface and the
> Service (Technical) Interface.  Since the Technical Interface includes
> details of endpoint, protocol, etc, which CAN be the ebXML MS, it could
> be argued that the BSI sends the Transport level acknowledgements.
>
> These are different than the Business logic level acknowledgements.  Let
> me explain:
>
> The Transport level acknowledgements basically says "I received your
> message, but have not yet read it or agreed to anything you propose".
> The Business level acknowledgement says "I received your [name of
> specific document] and acknowledge receipt and possibly agree to it
> [depending on the BP you are engaging in]".
>
> Cheers
>
> Duane
>
> "Himagiri(Hima) Mukkamala" wrote:
> >
> > No, Acks at MSH and BSI level are different.
> > Acknowledgments sent at MSH level do not have to deal
> > with any payload validity check. This is a SOAP Header extension
> > and not derived from RosettaNet. Please refer to section 6.3.2
> > in the ebXML MSH 2.0 specification.
> >
> > http//www.oasis-open.org/committees/ebxml-msg/documents/ebMS_v2_0.doc
> >
> > FYI, Acks for BSI (BPSS 2.0) are not derived from RosettaNet.
> >
> > -hima
> >
> > Nandini Ektare wrote:
> >
> > > Correct me if I am wrong. Isn't the Receipt Acknowledgement at MSH
> > > level and BSI level same?
> > >
> > > Both are derived from same Standard Rosettanet dtd and both say
> > > "this ack is sent if the message received is legible(i.e the
> > > *message* has passed a structure/ schema validity check)"
> > >
> > > -Nandini.
> > >
> > > "Himagiri(Hima) Mukkamala" wrote:
> > >
> > >> No. BSI doesn't play a role in sending/receiving acks at MSH
> > >> level.
> > >>
> > >> There are different acknowledgments that are to be dealt at the
> > >> BSI layer
> > >> implied by some attributes in BPSS instance document. These
> > >> include
> > >> the "ReceiptAcknowledgment" and the "AcceptanceAcknowledgment".
> > >>
> > >> So in that sense as MSH has control over the MSH Acks, it has to
> > >> have
> > >> control over the keys to sign the acknowledgments.
> > >>
> > >> -hima
> > >>
> > >> Nandini Ektare wrote:
> > >>
> > >> >
> > >> > As this question has been raised, I want to add to the question.
> > >> >
> > >> > I agree sending receipt acknowledgement is the responsibility of
> > >> > MSH but is it also true that creation of the ack automatically is
> > >> > MSH's responsibility. >From what Patrick has asked I get a
> > >> > picture that Acknowledgements are 'traded' just between the MSH
> > >> > at both ends.
> > >> >
> > >> > As a layer above MSH in the ebXML stack, a BSI may want to alter
> > >> > the ack before sending (say) to state the reason for negative
> > >> > ack. (the <FreeFormText> element in the standard
> > >> > ReceiptAcknowledgement dtd could be used). Similarly  the BSI
> > >> > wants to receive the ack in order to (say) send a separate
> > >> > "Notification of failure" in case of a -ve  ack which is treated
> > >> > as a business protocol exception by the BSI.
> > >> >
> > >> > All in all, doesn't the BSI play a role in sending/receiving
> > >> > Acknowledgements - whether Receipt or Acceptance?
> > >> >
> > >> > And if BSI does play a role, the key/passwd per appln need not
> > >> > necessarily be stored in MSH keystore.
> > >> >
> > >> > thanks,
> > >> > Nandini
> > >> >
> > >> >
> > >> > Patrick Yee wrote:
> > >> >
> > >> >>  Dear all, I have a question about messaging service. According
> > >> >>  to the specification, the sender of a message can request an
> > >> >>  acknowledgement from the receiver, and optionally, the sender
> > >> >>  can request that acknowledgement to be signed. Since the
> > >> >>  acknowledgement sending is done automatically by the MSH, does
> > >> >>  that imply the MSH should keep the application's private key
> > >> >>  and password to the keystore for signing automatically? Will
> > >> >>  that cause any vulnerability problem?Thanks in
> > >> >>  advance.Regards,-Patrick--
> > >> >>  Patrick Yee
> > >> >>  System Architect
> > >> >>  Center for E-Commerce Infrastructure Development (CECID)
> > >> >>  Dept. of Computer Science and Information Systems
> > >> >>  The University of Hong Kong
> > >> >>  Tel: (852) 22415674
> > >> >>  Fax: (852) 25474611
> > >> >
>
> --
> CTO, XML Global Technologies
> ****************************
> Transformation - http://www.xmlglobal.com/prod/foundation/
> ebXML Central - http://www.xmlglobal.com/prod/central/


----------------------------------------------------------------
The ebxml-dev list is sponsored by OASIS.
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.ebxml.org/ob/adm.pl>