RE: [ebxml-dev] RE: [ubl-dev] UBL payload and client-server integration

["David RR Webber \(XML\)" <david@drrw.info>]

Bernd / Sacha,

Very interesting thoughts!  pre-Getback tax =? refund or withholding or
pre-paid or exempt.  I think its probably the last one - that you are
exempt from paying the tax - because you are going to pay it - but you
have to sign to say / accept responsibility for that?

I did a whole project design for the EU some years back involving
proxy-billing and proxy-tax handling - particularly VAT on goods and
services.

So Bernd noting that using a proxy service - aka clearinghouse -
obviously that is one solution.

However - I'm wondering if Sacha's Javascript is too complicated an
approach - is it not simpler than that?

The web browser itself already has built-in certificate services - where
it presents the certificate to establish an SSL connection via https. 
That seems to me to be the better way.  This allows you to confirm who
you are talking to - and then you have a legal agreement on file - with
their certificate as the signature for that.  So in AJAX - you would
merely send the client back a unique hashed code from the server that
IDs their certificate and session - that string would then be included
in the UBL that gets sent when they use the "Send".

Actually an ebXML Registry - aka OMAR works very nicely for this already
- it creates certificates for you and automatically sends them to the
client on user account creation for storage by the browser.

So from my previous model - the client using AJAX submits the
transaction to the server - and it can then onward dispatch that using
ebXML - and again the certificate will be available for that exchange. 
Better yet - the ebXML server itself can be a signed proxy service
provider for its customers - so that the downstream system need only
confirm the one secure exchange.  This is the model we are using
currently at NIH - where the S2Sclient is installed on the service
provider - and they can then submit transactions on behalf of their
customers.

DW


 -------- Original Message --------
Subject: RE: [ebxml-dev] RE: [ubl-dev] UBL payload and client-server
integration tools
From: "Eckenfels. Bernd" <B.Eckenfels@seeburger.de>
Date: Tue, November 14, 2006 4:05 am
To: "Sacha Schlegel" <sacha@schlegel.li>, "David RR Webber (XML)"
<david@drrw.info>
Cc: <fulton.wilcox@coltsnecksolutions.com>, "Stephen Green"
<stephen_green@bristol-city.gov.uk>, <ebxml-dev@lists.ebxml.org>,
<ubl-dev@lists.oasis-open.org>

Hallo Sacha,

It is currentl (in germany) not possible to implement this signing in
Javascript. The Key must not (in germany) leave the card. Also you
cannot do that in OpenSource, since the component which actually aplies
the signature (calculates the hash, displays the document, manages the
keys) must be certified in a specific version and as a whole package.

There is btw another problem with that, as soon as you have legally
bindinding electronic documents, you need to archive them (and the
result of signature verification) on receipient side in a quite complex
way. Also the sender has problems with keeping an archive, so in the SMB
area it is currently much eaier to use a clearing center for that.

In germany there are some political lobbying going on to chnage that and
allow advanced signatures, but you are not there yet. 

Greetings
Bernd

-----Original Message-----
From: Sacha Schlegel [mailto:sacha@schlegel.li] 
Sent: Tuesday, November 14, 2006 9:57 AM
To: David RR Webber (XML)
Cc: fulton.wilcox@coltsnecksolutions.com; 'Stephen Green';
ebxml-dev@lists.ebxml.org; ubl-dev@lists.oasis-open.org
Subject: [ebxml-dev] RE: [ubl-dev] UBL payload and client-server
integration tools

Hi David

Have you seen an Open Source Javascript XML Digital Signature toolkit,
yet? ... to client side sign a dom or ubl instance?

There are some regular encryption algorithms implemented in Javascript
but not yet XML Digital Signature, as far as I have seen.

In some countries an invoice must be digitally signed so that the
receiver can pre-getback the tax (dont know the right term in English /
Vorabsteuer beziehen in German).

So for the dsig part:

a) it must simply get cheaper that SME's (including one man companies)
can afford a certificate signed by one of the authorities (one that is
OK for the countries tax agencies). Maybe 10$ a year but not more.

b) a javascript that before it sends the UBL invoice opens a dialog to
load the private key to sign the UBL invoice and then sends the UBL
invoice or

c) have a browser plugin to do the signing. A plugin may have more
rights to access the computers harddisk to retrieve the private key so
the user must not manually select the certificate

c) the tool (javascript/plugin) should be Open Source so it is possible
to make sure the script does not maliciously send the private key
somewhere. 

Regards

Sacha

Am Freitag, den 10.11.2006, 11:50 -0700 schrieb David RR Webber (XML): 
> Fulton,
>   
> Actually I'm deep into AJAX right now.  Oracle have an excellent open 
> source toolset available.
>   
> However - for me the power of the RIA approach is
> 1) Layering the solution (which was the whole permiss to XML) so 
> rendering, rules, form, xml all separate.
> 2) Being able to make things agile and dynamically context aware (XML
> scripted)
> 3) The DOM inside the browser client is way more powerful than 
> anything we had before.
>   
> So - unlike your model - I'm seeing - yes - we do those realtime RIA 
> requests and updates - but what is happening is you are building up 
> the information you need in the DOM at the client interactively.  Once

> its all complete - then you hit "Send" - and the RIA then packages the

> UBL transaction and dispatches it to the server for delivery.  That 
> delivery could involve traditional B2B style reliable exchanges.  What

> you've saved is having to package / validate the XML on the server.
>   
> Here's a recap' of how this works (layers details exposed): 
>   
> 1) RIA works with user and database to collect valid content to client
> 2) DOM in client is updated with labelled data fields ( notice those 
> labels match the UBL names....)
> 3) Javascript invoked by "Send" button - it opens up a XML template of

> the UBL (hint: CAM templates work great!)
>     and simply does substitutions matching data labels to structure 
> placeholders.  This is "code free" + re-usable -
>     if you change the template - add more fields - then the "Send"
> requires zero changes. 
> 4) UBL XML transmitted to server via browser XML send command. 
> 5) Server places XML in outbound queue for sending via secure B2B 
> system.
>   
> What is way crazy about all this is that Duane and I built a prototype

> for this back in 1999 for a example selling products - simple 
> catalogue in XML, pick, buy.  Javascript + DOM + XML = very slick!
>   
> DW
>  
> 
> 
>  -------- Original Message --------
> Subject: [ubl-dev] UBL payload and client-server integration tools
> From: Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>
> Date: Thu, November 09, 2006 6:58 pm
> To: 'Stephen Green' <stephen_green@bristol-city.gov.uk>,
> ebxml-dev@lists.ebxml.org, ubl-dev@lists.oasis-open.org
> 
> Stephan et al:
> 
> I am leveraging your note regarding UBL payload, but in a somewhat 
> different context - hence the different subject line. The parallel 
> with your note is that there are various ways to leverage the payload 
> IP of UBL, even though the middleware and transport would be something

> different.
> 
> As is widely known, there are various tools and techniques used to 
> recreate client-server selective updates, under the rubric "rich 
> internet applications" (RIA). For example Adobe's Flash brings back 
> 1990's style field-at-a time-update/validation with "Flash Remoting." 
> Flash is certainly not the only RIA option, but it holds some high 
> ground because of the ubiquity of Flash agents.
> 
> For reference, see http://www.amfphp.org, which is the home page of an

> open source Flash Remoting gateway. As it happens, the example shown 
> on that page is a configuration-style order transaction for pizza. 
> Presumably, as the user adds or deletes ingredients, the client-side 
> software updates the price and perhaps validates the feasibility of 
> the pizza, via calls to the server.
> Given that client-server responses need to flow consistently with the 
> user's thought processes and rate of data input, RIA proponents are 
> concerned about performance and therefore prefer binary data transfer 
> rather than text and cannot afford a lot of XML overheads.
> 
> As RIA tools become more commonplace and accepted, thousands of 
> programmers will use RIA calls to create or to consume what are or 
> should be UBL transactions. Unfortunately, designers in the RIA world 
> tend to be unaware of any of the relevant payload standards or are 
> dismissive of those standards because they do not see a way to achieve

> high performance with text. There is also the issue that for RIA there

> may be a marked preference for dealing with a UBL transaction in 
> pieces rather than as an entire document - e.g., call for the 
> deliver-to address first to see if the vendor even wants to consider 
> this order.
> 
> What are the implications of fairing UBL into RIA architectures?
> 
> One proposition would be to repackage UBL for RIA client-server use.
> Doing
> so is particularly helpful in avoiding a downstream need to translate 
> some ideosynchratic ad hoc transaction design into something useful to

> the other party to the transaction.
> 
> The second is to consider use of RIA techniques within the more 
> typical eBusiness server-to-server exchange of transactions. RIA calls

> are built for speed and light touch on bandwidth, so the fit would be 
> to highly repetitive transactions - e.g., price checks, inventory 
> availability checks, transportation scheduling, etc.
> 
> It is still early days for RIA, but perhaps not too early to consider 
> the implications for UBL and other Oasis standards.
> 
> 
>                                       Fulton Wilcox
>                                       Colts Neck Solutions lLC
> 
> 
> 
>  
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Stephen Green [mailto:stephen_green@bristol-city.gov.uk]
> Sent: Thursday, November 09, 2006 3:51 AM
> To: Stephen Green; ebxml-dev@lists.ebxml.org; 
> ubl-dev@lists.oasis-open.org
> Subject: RE: [ubl-dev] A UBL Customisation (beta) for general use
> 
> Offlist I was reminded that assimilation of the payload is the key 
> consideration here so I guess we're talking fast infoset for the 
> binary so as to allow the payload to be treated similarly to XML for 
> those used to XML but for those receiving messages who already have 
> telecoms technology then other binary formats may be appropriate.
> 
> Stephen Green
> 
> >>> "Stephen Green" <stephen_green@bristol-city.gov.uk> 08/11/06 
> >>> 16:23:14
> >>>
> Hi David,
> 
> Is this confusing ASN.1 and AS2?
> 
> I think the use of ASN.1 would be non-XML payloads using one of 
> several binary formats which rely on a schema written not in XSD but 
> in ASN.1 notation (though mappable to XSD). It gives the advantage of 
> preformance and/or small size and allows greater compression than with

> .zip or .gz, I believe. I think it predates XML in its use in the 
> telecoms industries but nicely complements XML now that the latter is 
> at the fore. So we are here talking payload, but with some bearing on 
> other layers perhaps. And I guess what I'm after is any info on 
> whether/how ebXML layers might need adapting to cater for it (e.g. I 
> guess the list of schema formats in the ebBP references to schema type

> won't include 'asn.1'
> so implementers might have to use 'other') - plus any general stories 
> about successful use or otherwise of the ASN.1 provisions in UBL - 
> either with ebXML or otherwise. Would, in fact, it be 
> prudent/advantageous to use ASN.1 with ebXML? Or - a key question - is

> there already a preferred framework used with such binary payloads? I 
> haven't come across any previous questions about this on these lists 
> so maybe this is still virgin ground. It could be important for large 
> files though.
> 
> All the best
> 
> Stephen Green
> 
> 
> >>> "David RR Webber (XML)" <david@drrw.info> 08/11/06 15:32:29 >>>
> Stephen,
> 
> I just noticed this post.  This week on the Hermes 2 dev list - some 
> people are looking to use Hermes 2 as a bridging server.
> 
> Basically Hermes 2 is pluggable - and supports both ebMS and AS2 - so 
> it can talk on either channel.
> 
> You'd have to have something in between to extract payload and then 
> repackage it - but I suspect all the parts are there to make it so.
> 
> Cheers, DW
> 
> 
> 
> -------- Original Message --------
> Subject: Re: [ubl-dev] A UBL Customisation (beta) for general use
> From: "Stephen Green" <stephen_green@bristol-city.gov.uk>
> Date: Thu, November 02, 2006 11:44 am
> To: <ebxml-dev@lists.ebxml.org>, <ubl-dev@lists.oasis-open.org>, 
> <stephen.green@systml.co.uk>
> 
> By the way, folk might note, following on from UBL's packages, we 
> included a set of ASN.1 schemas for our subsets.
> 
> Has anyone actually managed to implement UBL with ASN.1 and are they 
> able to comment on their experience of this?
> I'd be especially interested to know what might be involved using 
> ASN.1 with ebXML, such as ebMS. Is it feasible? I suppose it would 
> mean transforming the binary into MIME.
> What would be the preferred binary format and how would MIME handle 
> it? What values would be in the ebXML artefacts?
> Are there any products doing this?
> 
> All help appreciated.
> 
> All the best
> 
> Stephen Green
> 
> 
> 
> 
> >>> <stephen.green@systml.co.uk> 01/11/06 15:07:10 >>>
> I'm happy to say, on behalf of SystML, we have finished a beta 
> customisation of UBL versions 1.0 and 2.0 which is freely available at
> 
> www.systml.co.uk/xml/
> 
> for use at your own risk. We hope you will provide feedback which 
> could go to us at
> 
> info@systml.co.uk
> 
> It was produced by SystML and by HavanaWave AG 
> (Sacha.Schlegel@HavanaWave.com).
> 
> Obviously, it being at the beta stage, it is subject to possible 
> change (though we'd bear in mind that we should consider possible 
> users when contemplating any change) and how you use it is up to you 
> provided you do so at your own risk. Maybe if this is all sufficiently

> satisfactory we will find the means to preserve it, long term, as it 
> is (perhaps just changing the status to 'complete').
> Zip packages are provided for those who prefer the possible extra 
> security of storing it locally (much as you would with the source code

> of opensource, say).
> 
> I'm very grateful to all who've helped us with this project to get it 
> to this stage - to God and to colleagues : Thanks.  :-)
> 
> All the best
> 
> Stephen Green
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>