OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-architecture message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: ebXML Requirements





Mike Rawlins wrote: 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.

<dwight> There was a similar discussion in the transport list. I do not
understand this requirement. Many types of application will require many
types of attribution and authentication of static documents that are to be
incorporated into (attached to?) (carried through?) ebXML messages. EbXML
imho needs to be able to attribute and authenticate its own envelopes, and
must not interfere with the schemes used by applications to authenticate and
attribute any objects placed into the ebXML envelope. However, I do not
think it feasible for ebXML to incorporate a comprehensive specification for
signing objects, combinations of objects, or ranges within objects with both
transitory and persistent signatures. I believe that this should happen at a
layer that's higher than the scope of ebXML.</dwight>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC