Re: [dss] public comment from ebXML

[Andreas Kuehne <kuehne@klup.de>]

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