Re: ebXML Requirements

[Mike Rawlins <rawlins@metronet.com>]

My comments, MCR2

Duane Nickull wrote<snipped>:

> >From Duane Nickull:
>
> Mike Rawlins wrote:
> >
>
> > > *       In X12/EDIFACT, the facilities for signing/encrypting documents are
> > > quite extensive (e.g., signature over signature), whereas existing work with
> > > XML/EDI has only supported communication layer signatures/encryption.  From
> > > a business/legal viewpoint, what are the security/privacy requirements?
> > >                         The expedient thing to do would be to accept the
> > > communications level solution for now, but is it adequate for now?
> >
> > MCR:  That's a very good point.  I think it appropriate for us to list as
> > non-functional requirements all of the classic aspects of security such as
> > non-repudiation in various flavors, confidentiality, authentication, etc.  both
> > in regard to communications as well as static documents where appropriate.
>
> <DUANE>  The industry standard RSA encryption techniques that are
> available to http bound messages should be good enough to satisfy for
> now.  Can you please explain where you envision static documents fitting
> into the architecture that need to be encrypted?
> </DUANE>

MCR2:  This goes back to your group's (Bob Miller's) requirement for something beyond
just communications layer security.   Others have described this needs for both
communications session encryption/authentication/etc., and
encryption/authentication/etc. that could be applied to a stand alone (what I call
static) document.


> > > Interoperability Requirements (among disparate XML-capable systems)
> > >
> > > *       Some business advice on this topic beyond 'must support
> > > interoperability' is needed  (E.g., the scope of interoperability; upon
> > > which party or parties does responsibility lie for achieving
> > > interoperability; acceptability of non-XML based solutions)
> >
> > >
> > > *       Scope might include some existing XML/EDI applications, such as a
> > > RosettaNet application; some existing XML capable non-EDI applications, such
> > > as ORACLE-based application products.   ebXML conformance could be defined
> > > such that both a RosettaNet application and an X12 Technical Report  based
> > > application were implicitly ebXML conformant, or ebXML could be defined such
> > > that neither was conformant, but each could be transformed by some XML-based
> > > process to be ebXML conformant and so to be interoperable.
> >
> > MCR:  We are currently working on detailed requirements for interoperability
> > both between ebXML compliant applications and with existing XML solutions and
> > traditional EDI.
> <DUANE> We must clearly define the scope for ebXML.  Once this has been
> established,  it will be easy for other standards/solutions to interact
> with ebXML via mapping.  Bob, your comments are dead on.  Once we have
> defined ebXML, whatever that may eventually be,  the rest of the world
> can very easily translate.
>
> Mike - I disagree with your point.  There should not be interoperability
> mapping specifications done within the ebXML architecture.  Once we
> define ebXML,  let the software vendors do this.  We really need to
> define strict conformancy rules so non-conformant ebXML gets turfed
> (with error messages)
> </DUANE>

MCR2:  The requirements team has had difficulty reaching consensus on this point -
that is why I say we are working on it.  The core components team is currently
thinking that ebXML should define a set of core components and then let the various
standards bodies (X12, EWG, etc.) and vendors (CommerceOne, Ariba, etc.), define how
they map into ebXML.  I personally tend to agree with this idea, but as I say, we
don't have consensus yet.

--
Michael C. Rawlins, Rawlins EDI Consulting
http://www.metronet.com/~rawlins/