RE: [dss] public comment from ebXML

["Pope, Nick" <Nick.Pope@thales-esecurity.com>]

Andreas,

Andreas,

I agree a joint activity with ebXML would be great!

How would you suggest we answer the specific point made about adding ebXML
capabilities to the Core.

I thought initially that maybe a ebXML specific profile would be more
appropriate.  Alternatively, is adding ebXML transport to the Core something
that can be done with minimal disruption to the Core?  Is it something for
the next round? 

Nick

-----Original Message-----
From: Andreas Kuehne [mailto:kuehne@klup.de] 
Sent: 17 November 2006 10:32
To: Nick.Pope@thales-esecurity.com; dss@lists.oasis-open.org
Subject: Re: [dss] public comment from ebXML

Hi all !

I can agree with the proposal completely to add the broad range of 
functionalities of ebXML to a DSS implementation !

Dtmo it wouldn't replace the existing profiles ( especially Async ),
but enables a company to offer a DSS styled service over the internet,
not just within the intranet. In addition to the signing and
verification mentioned by Pim especially the timestamp would be a 
valueable service to offer. This is much more valuable when it's done by 
an independent third party.

I once thought about starting an ebXML effort within the TC. But I
was afraid to defer the 1.0 version. In the near future having 1.0 out / 
InterOp ready and getting some backing from the ebXML group it would be 
an interesting effort I would like to participate in.

So future looks bright for DSS !

Greetings

Andreas

>  On behalf of an end-user community that is looking to implement DSS in 
> an
>  ebXML infrastructure, I would like to submit the following comment 
> public
>  comment to the DSS TC.
>
>  The ability of the ebXML Messaging as a transport protocol to use 
> standard
>  facilities for asynchronous messaging, routing based on PartyId, and
>  reliable messaging, and the bilateral service configuration 
> capabilities of
>  ebXML Collaboration Protocols and Agreements are a main benefit 
> compared to
>  Asynchronous Processing Abstract Profile for the OASIS Digital 
> Signature
>  Services (which uses a protocol similar to XKMS).
>
>  Core features of an ebMS binding, for consideration:
>
>  -  Fixed value for the ebXML "eb:Service" header element:
>     "urn:oasis:names:tc:dss:1.0:ebxml-msg"
>
>  -  Fixed values for the ebXML "eb:Action" header element, one of:
>     "SignRequest"
>     "SignResponse"
>     "VerifyRequest"
>     "VerifyResponse"
>
>  Payload/header/message correlation:
>
>  An ebXML message with a value "eb:Action" set to "SignResponse"
>  (respectively, "VerifyResponse") sent from MSH A to MSH B should 
> contain an
>  "eb:RefToMessageId" header element. The value of this element must 
> match the
>  value of the eb:MessageId header element in an earlier ebXML message 
> sent
>  from MSH B to MSH A with a value "eb:Action" set to "SignRequest"
>  (respectively, "VerifyRequest"). The "eb:Service" would be
>  "urn:oasis:names:tc:dss:1.0:ebxml-msg".
>
>  If the DSS XML document included in that earlier request message 
> contains a
>  DSS "RequestId", the response message should include a DSS "RequestId" 
> with
>  the same value.
>
>  Request and response messages have the same values for 
> eb:ConversationId and
>  eb:CPAId/eb:AgreementRef.
>
>  The SSL/TLS transport level security settings for the ebXML message 
> exchange
>  would adhere to the DSS transport security settings.
>
>  The above is only a binding and would work with DSS XML request and 
> response
>  documents as used in the HTTP and SOAP 1.2 bindings.  To take 
> advantage of
>  the ebXML message structure, it might make sense to allow the 
> dss:Document
>  to reference documents stored in subsequent MIME attachments in the
>  SOAP-with-attachments message structure (via a reference attribute 
> using an
>  RFC 2392 "cid" URI).
>
>  When using a registry to store partner profiles or agreement templates 
> (or
>  negotiation description documents), the fixed values of the eb:Service 
> and
>  eb:Action would allow partners to find a suitable digital signature 
> service
>  provider in a particular community using the query functionality of 
> the
>  registry.
>
>  This profile works equally with ebXML Messaging version 2 (ISO 15000) 
> and
>  the upcoming version 3 ebXML specification.
>
>  Would the TC consider adding an ebXML Messaging transport profile 
> along
>  these lines to section 6 of the DSS 1.0 core specification?
>
>  Pim van der Eijk
>
>
>
>
>  This email and any files transmitted with it are confidential and 
> intended
>  solely for the use of the individual or entity to whom they are 
> addressed.
>  You must not disclose, copy or rely on any part of this correspondence 
> if
>  you are not the intended recipient.
>  If you have received this email in error, please delete it from your 
> system
>  and notify the System Administrator at Thales e-Security +44 (0)1844 
> 201800
>  or mail postmaster@thales-esecurity.com

___________________________________________________
Andreas Kühne
phone: +49 177 293 24 97
mailto: kuehne@trustable.de

Trustable
Kirchröder Str. 70e
30625 Hannover
Germany
www.trustable.de

Kostenlose Verifikation qualifizierter elektronischer Signaturen:
www.sig-check.de





This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
You must not disclose, copy or rely on any part of this correspondence if
you are not the intended recipient. 
If you have received this email in error, please delete it from your system
and notify the System Administrator at Thales e-Security +44 (0)1844 201800
or mail postmaster@thales-esecurity.com