RE: RE: RE: [dss-x] Fwd: Presentation client and server signature

["Pim van der Eijk" <pvde@sonnenglanz.net>]

OK, let's hear what other people think.

Pim

PS "ebXML stack" sounds somewhat intimidating,  an ebMS
"light handler" can be (in fact my light handler is being)
written as a set of Python scripts, so no need for complex
and/or expensive toolkits or products. 

-----Original Message-----
From: kuehne@trustable.de [mailto:kuehne@trustable.de] 
Sent: 16 February 2011 17:30
To: pvde@sonnenglanz.net; dss-x@lists.oasis-open.org
Subject: Re: RE: RE: [dss-x] Fwd: Presentation client and
server signature

Hi Pim,

thanks, now I see !
My knowledge is pretty outdated, I'm not aware of all the
new stuff introduced with version 3 ...

Yes, this inversion-of-control on the transport level will
do the job. But I have some doubts that the Oscars likes to
deploy an ebXML stack on his clients. Afaik the driving
force of Oscar's approach was to keep deployments lean. 

On the other hands is's always the better approach to use an
existing solution in favour of building another
hard-to-understand special way. As we once implemented this
i-o-c hack I wouldn't have bet a penny that it could make to
an OASIS profile ;-)

Let's see what the other think about it.

Greetings

Andreas

----- original Nachricht --------

Betreff: RE: RE: [dss-x] Fwd: Presentation client and server
signature
Gesendet: Mi, 16. Feb 2011
Von: Pim van der Eijk<pvde@sonnenglanz.net>

> 
> Andreas,
> 
> What I was saying is that ebMS 3.0 in Pull mode offers
exactly this 
> "inverted" model.  The DSS server would pull messages as
an HTTP 
> client (initiator+receiver) from a DSS client that is the
HTTP server 
> (sender+responder). The requests are pulled using a
standardized 
> pre-defined pull signal message.
> 
> In the ebMS 3.0 Part 1 Core that the DSS ebXML profile
references, a 
> pull request pulls a single "UserMessage", and multiple
such user 
> messages are polled by repeated polling.
> If there is nothing to pull, there is a standardized
response 
> indicating this. Section 5.2.4 of the Core also describes
a way of 
> combining a UserMessage push and Pull request, which you
want here.  
> The only limit is that the Part 1 Core bundling is limited
to a single 
> user message per bundle. The ebMS 3.0 Part 2 defines a
"bundling" 
> feature to pull or push a set of user messages. That makes
it 
> equivalent to what you describe, and that is what I wanted
to point 
> out.
>
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/part2/201004/
> 
> 
> If your WSDL operation definition is about responses that
are 
> responses to requests made in a previous invocation of the
operation, 
> and about requests that are new requests, the responses to
which will 
> sent in a later invocation, then you are stretching the
semantics of 
> "operation".  But as long as everybody understands what
you're doing, 
> why not.  It's possible to define custom polling,
bundling, 
> asynchronous processing protocols for DSS as for any other

> application.
> 
> Pim
>  
> 
> -----Original Message-----
> From: kuehne@trustable.de [mailto:kuehne@trustable.de]
> Sent: 16 February 2011 16:07
> To: pvde@sonnenglanz.net; dss-x@lists.oasis-open.org
> Subject: Re: RE: [dss-x] Fwd: Presentation client and
server signature
> 
> Hi Pim,
> 
> I'm afraid I don't get your hint regarding the ebXML
profile aligned 
> with Oscar's problem ;-)
> 
> I'm thinking of adding a new operation to the wsdl,
something like 
> this
> 
> 		<operation name="pollingForSignRequests">
> 			<input
> message="impl:SignResponseList"/>
> 			<output
> message="impl:SignRequestList"/>
> 		</operation>
> 
> These are more or less the same structures as we know them
from core, 
> just wrapped into a 0..n List. But in contrast to the
usual 'client 
> calls, server responds' scenario, here the 'server' (the
process 
> holding the private key) calls the client (the process
requesting the 
> signature). With this call zero or more SignResponses of
previous 
> requests are send to the client and in return zero or more
fresh 
> SignRequests travel to the server.
> 
> This matches Oscars scenario where the browser serves as
the 'server' 
> as it has access to the private key. The browser
periodically performs 
> calls to the an instance where a specialized DSS process
does all the 
> pre- and postprocessing of the signature. But to a certain
degree it 
> plays the role of a client as it isn't able to encrypt a
hash value.
> 
> This approach looks a bit wierd, especially as it
intermixes the 
> wellknown roles of server and client. But it's just a
inversion of 
> control to circumvent the inability of the web browser to
be an 
> endpoint of a call. It  serves as an originator of the
polling calls.
> 
> I cannot an advantage of using ebXML as dtmu it just
transports the 
> payload for a given operation ...
> 
> Greetings
> 
> Andreas
> 
> ----- original Nachricht --------
> 
> Betreff: RE: [dss-x] Fwd: Presentation client and server
signature
> Gesendet: Mi, 16. Feb 2011
> Von: Pim van der Eijk<pvde@sonnenglanz.net>
> 
> > 
> > Hello Andreas,
> > 
> > Just a comment that a "polling" use case could be
provided
> by using
> > the ebMS 3.0 transport binding for DSS:
> >
>
http://docs.oasis-open.org/dss-x/profiles/ebxml/v1.0/oasis-d
> > ss-1.0-profiles-ebxml.pdf
> > 
> > In ebMS 3.0, it is possible to have a service provider
> that is HTTP
> > "client only":  it pulls requests, and pushes the
> responses back. This
> > message exchange pattern is referred to as the
> "Two-Way/Pull-and-Push
> > MEP" in ebMS 3.0. The definition is in section 2.2.8 of:
> >
>
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/os/ebms_
> > core-3.0-spec-os.pdf
> > 
> > A main benefit of this is that no changes are needed to
> the DSS
> > messages, the polling functionality is provided by the
> transport
> > protocol binding, not by a DSS profile.  A regular DSS
> sign/verify
> > request can be polled, and a regular DSS response
> returned. I'm not
> > sure that is appropriate for the use cases you're
> describing, but it
> > may be of interest anyway.
> > 
> > A light client conformance profile for ebMS 3.0 is
defined
> in section
> > 3.2 of:
> >
>
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/2007
> > 07/ebms3-confprofiles-cs-01.html
> > 
> > This ebMS 3.0 conformance profile does not require any
of
> the "heavy" 
> > Web Services modules (security or reliable
> > messaging) and no HTTP server capabilities.  It can be
> built using
> > just HTTP client, TLS, SOAP/MIME and XML libraries, so
it
> is not hard
> > to implement.
> > 
> > Pim
> > 
> > -----Original Message-----
> > From: kuehne@trustable.de [mailto:kuehne@trustable.de]
> > Sent: 14 February 2011 19:31
> > To: dss-x@lists.oasis-open.org
> > Subject: Re: [dss-x] Fwd: Presentation client and server
> signature
> > 
> > Hi all,
> > 
> > I would like to make on Oscars use case :
> > 
> > In this scenario the client itself requests a signature
ad
> is holding
> > the required private key, too. In this case outlined
> request /
> > response pair is a perfect fit.
> > 
> > In my use case the requirements a bit broader :
> > The client can request a document to be signed but
> additionally there
> > may be more requests ready to be signed originated
earlier
> / by other
> > sources. So I would like to propose a more general
> approach that
> > solves both requirements :
> > 
> > 1. A signing request as we already know it. Usually
> asynchrounous, as
> > it may take an unpredictable amount of time to be
> processed. It cannot
> > be guessed in advance when the user / the supervisor /
the
> notary logs
> > in again to sign pending documents.
> > 
> > 2. A polling-styled request to get new signing requests
> for the local
> > private key and to return encrypted hashes. This new
> method can be
> > consructed by the elements we already got in the schema,
> just a bit
> > twisted :
> > 
> > The client request holds a signing response to an
earlier,
> already
> > processed call. And the server response transports new
> signing
> > requests stripped down to the plain bytes that should be
> encrypted by
> > the clients private key.
> > 
> > As this is a polling mechanism, responses and / or
> requests may be
> > empty.
> > 
> > 3. The server returns the signature as the response to
the
> initial
> > call from 1. .
> > 
> > This solution could cover both requirements without to
> much extra
> > burden on Oscar client-initiated signing. Just a little
> bit of
> > inversion-of-control ...
> > 
> > 
> > Greetings
> > 
> > Andreas
> > 
> > 
> > 
> > 
> > ----- original Nachricht --------
> > 
> > Betreff: [dss-x] Fwd: Presentation client and server
> signature
> > Gesendet: Mo, 14. Feb 2011
> > Von: Juan Carlos Cruellas<cruellas@ac.upc.edu>
> > 
> > >
> > >
> > > -------- Mensaje original --------
> > > Asunto:       Presentation client and server signature
> > > Fecha:        Mon, 14 Feb 2011 16:23:26 +0100
> > > De:   Òscar Burgos <oburgos@catcert.net>
> > > Para:         Juan Carlos Cruellas
> <cruellas@ac.upc.edu>,
> > <stefan@drees.name>
> > > CC:   Òscar Burgos <oburgos@catcert.net>
> > >
> > >
> > >
> > > Sorry for the delay.
> > >
> > > If we have time (I’ll be a bit late) we can discuss on
> > this mixed
> > > scenario and how can we approach it (whether it is
> > possible using a
> > > profile or adding new elements to the core)
> > >
> > > See you later.
> > >
> > > Oscar.
> > >
> > > _
> > >
> > >      
> > >      
> > >
> > > *Oscar Burgos Palomar*
> > > Àrea d'assessorament
> > >
> > >
> > > Agència Catalana de Certificació - CATCert Passatge de
> la
> > Concepció
> > > 11, 08008 Barcelona
> > > tel: 93 272 25 88 - fax: 93 272 25 39 www.catcert.cat 
> > > <http://www.catcert.cat/>
> > >
> > > _
> > > _
> > >
> > >      
> > >
> > > Aquest correu electrònic, així com qualsevol fitxer
> annex,
> > conté
> > > informació classificada. Queda prohibida la seva
> > divulgació, còpia o
> > > distribució a persones diferents del seu destinatari
> > exclusiu sense
> > > autorització prèvia per escrit de l'Agència Catalana
de
> > Certificació -
> > > CATCert. Si vostè ha rebut aquest correu electrònic
per
> > error, si us
> > > plau notifiqui-ho immediatament al remitent
> reenviant-lo.
> > >
> > >
> > 
> > --- original Nachricht Ende ----
> > 
> > 
> >
>
------------------------------------------------------------
> > ---------
> > To unsubscribe from this mail list, you must leave the
> OASIS TC that
> > generates this mail.  Follow this link to all your TCs
in
> OASIS at:
> >
>
https://www.oasis-open.org/apps/org/workgroup/portal/my_work
> > groups.php
> > 
> > 
> > 
> > 
> > 
> 
> --- original Nachricht Ende ----
> 
> 
> 
>
------------------------------------------------------------
---------
> To unsubscribe from this mail list, you must leave the
OASIS TC that 
> generates this mail.  Follow this link to all your TCs in
OASIS at:
>
https://www.oasis-open.org/apps/org/workgroup/portal/my_work
groups.php
> 
> 

--- original Nachricht Ende ----