Re: RosettaNet response to ebXML MSS 0.98b

[Andrzej Bialecki <abial@webgiro.com>]

Hello,

Let me add some brief comments to your discussion:

On Wed, 11 Apr 2001, Prasad Yendluri wrote:

> > > > > 3. Non-repudiation of Relay message is not supported by ebXML.  While
> > > > > RNIF 2.0 also does not yet allow for this feature, it is an important
> > > > > member requirement that will affect future direction decisions.
> > > >
> > > > I'm not sure that I understand what a Relay message is. Are you
> > > > talking about NR of messages exchanged p2p between nodes of a network
> > > > of RNIF systems (what we have called intermediaries) as a message
> > > > works its way from To->From?
> > > >
> > > > Can you please explain why the extension mechanism isn't
> > > > adequate to your needs if the feature you require is not
> > > > directly supported?
> > >
> > > <PY> Non-Repdudiation of Relay is ensuring that a third-party-router / intermediary can not deny
> > > (later) that they had "relayed" a message received from X to Y.  This would call for some protocol
> > > between 'sending-party and intermediary' and 'intermediary and receiving party', that involves
> > > digital signatures.
> > > </PY>
> >
> > Can't a signed RM acknowledgment serve this purpose?
> 
> <PY>This would only prove that the intermediary received it and not actually sent (relayed) it. Also,
> this covers only the Sender-->Intermediary and not I-->Receiver (next hop) interaction. Something to
> factor in when we do specify multi-hop messaging beyond 1.0.</PY>

I would like to draw your attention to Hewlett-Packard's e-Speak framework
where the problem of authenticating the intermediaries is addressed in a
satisfactory way (http://www.e-speak.net). Might be a source for
inspiration...

> > > > > 10. RNIF's GlobalUsageCode is used to indicate test mode, negating the
> > > > > legally binding effect of transactions that aren't meant to be
> > > > > enforced.  Without it, out-of-band legal agreements must likely be
> > > > > made in order to distinguish binding transactions from testing.
> > > >
> > > > This issue was discussed ad nauseum a while back (late last year I believe)
> > > > and we concluded that because you could extend the message envelope,
> > > > that we need not provide for this.
> > >
> > > <PY>Yup. I also conveyed that :) but, if  one received a signed order for 1 million widgets
> > > supposedly in test mode, if the "test" aspect is not captured in the message itself, there could
> > > be cases where this might be an issue. A small boolean that says this is a message in "test" mode
> > > might help. Oops! not starting it again :)   </PY>
> >
> > Yes, and I originally raised the issue as part of my mapping between
> > other standards such as RNIF (specifically in this case).
> >
> > The real issue surrounding the test attribute was what the MSH could
> > possibly do to enforce it. The MSH simply passes off to an application
> > handler once the message is received. If the handler wasn't correctly
> > programmed to expect and handle a test indicator, then what?
> >
> > In truth, this agrument is quite compelling. Use of a test indicator
> > could at best be informative and certainly, unless we placed specific
> > requirements on the applications and application handlers that process
> > messages to ENFORCE the test indicator (and perform a rollback or something
> > equivalent) which we were loath to do, the test indicator could in fact
> > be quite harmful.
> >
> > The outcome of the thread/discussion was that the use of production
> > facilities to perform testing was deemed a poor practice and that we
> > shouldn't encourage it. If you want to perform testing with your
> > parter before "going live", then do so with a test infrastructure
> > that has a separate set of URIs and a separate CPA so that there is
> > no possibility that the test messages could be confised with or for
> > production messages.
> 
> <PY>In general people want to *test* their production set-up I think. Also, I believe this is not for
> accidental confusion of test message to be a production message but to cover the case of  malicious
> intent by one. However, I agree that this may not be an MSH issue. The test indicator should perhaps go
> in the payload (business content). In essence at the TRP level we can perhaps punt it..</PY>

You may want to test several different layers of the infrastructure: e.g.
the transport and the application. There shouldn't be any confusion about
which one the test indicator is supposed to relate to. In other words, if
the decision would be to have a test indicator, it should have a very
precisely defined scope.


Andrzej

// ----------------------------------------------------------------
// Andrzej Bialecki <abial@webgiro.com>, Chief System Architect
// WebGiro AB, Sweden (http://www.webgiro.com)
// ----------------------------------------------------------------
// <abial@freebsd.org> FreeBSD developer (http://www.freebsd.org)