[Specs-cx] Multi-party contract

[David García]

Hi Nara,

I'd like to expose my point at topic no. 7 signature. I live in Europe and
here (and in many countries outside Europe like Brazil) ETSI xml based
advanced signature is gaining strength as a "defacto standard".

Speaking in detail advanced signature performed with a qualified certificate
inside a SSCD (secure signature creation device), this is most national
eIds, is equivalent to handwritten signature.

This kind of signature offers xml signature benefits, like countersignature,
and other advanced desired features like signature preservation using
timestamps chains. Looking at the CX spec, the concept of signatures exposed
fits better on AdES (Advanced Electronic Signature) rather than simple
XMLdSIG.

But here arises a problem, there are little or no XAdES libraries publicly
available. I've working some years developing signature technologies for
Spanish government and now I'm on an startup offering those kind of
services, but this knowledge is still very condensed on a few players with
little or no alternatives on open source libraries.

So I propose to consider using advanced signature on contract signature, not
only because its technical advantages (preservation over signing
certificate's lifetime, countersignature, autovalidation using CRL/OCSP
ref/values attributes...). I know that speak it's easy, so I started some
days ago an effort to develop open source XAdES libraries for different
languages.

It's still in a very early stage, but I'm standing over the great work
developed by some folks like Aleksey's xmlsec and their bindings on dynamic
languages. I'm planning to port it to ruby (almost done), php (a partner
will do it) and create the guidelines to port it to any other language like
python or erlang.

The current status anyway (2 days of work) is a XAdES 1.3.2 version with
signature creation/validation working on ruby. Not bad for so little :) .

Of course using an easier approach that could be natively solved on each
language (or using simple encryption offered by openssl) will be easier to
implement, but I'm afraid that this won't be the best option for contracts
regarding to the actual legal schema in many countries.

Anyway that's only my point. I'd like to go back to this point once the
XAdES library effort is more advanced, but I only wanted to make a reflexion
about the topic of generating signed contracts (that will have implication
on the offline world) with a technology that has been bound (in many cases)
to offline equivalents (like handwritten signature).

Best regards, and sorry if my email is so extensive... caffeine still didn't
make it's effect.

Dave Garcia


2010/5/12 nara hideki <hdknr at ic-tact.co.jp>

> Hi,all experts.
>
> I had a off meeting with =nat about CX in the afternoon.
> The followings are what we discussed.
>
> 1.  Any party should be able to notfiy CX contract identifier to any
> party in the contract.
>
>    Current revision of the CX spec, only "cxstat" is defined.  "cxid"
> like parameter seems to be wanted to notify the contract identifier.
>
> 2. Signatory is a party who  a RP starts to have CX session with.
> That should be advertised in XRDS/XRD for the user/server identifier.
>
> 3. /Contract/Pary/obligation/endpoint  [0..n] is better. Site can be
> configured as a farm with some servers.
>    But the response must be the exactly same.
>
> 4. Data request provided at /Contract/Party/obligation/endpoint which
> is the url and should be requested in the following form ::
>
>    endpoint?id=_cx_identifier_&party=_party_identfier_in_the_contract_
>
>    The "Party" must encrypt the response message using the public key
> of  "_party_identfier_in_the_contract_"
>
> 5. The contract itself can be fetched by any party in the contract.
> Contract request is the exactly same as the "Data request".
>    But the url is the CX identifier itself.
>
> 6. Any party should state the notification endpoint.
> /Contract/Party/returnto  is good , isn't it?
>
> 7. Magic Signature could be more simple and better than XML Signature.
>
> I'm happy if discussion would be split into single item.
>
> Best regards.
> -----
> hdknr
> _______________________________________________
> Specs-cx mailing list
> Specs-cx at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-cx
>



-- 
David Garcia
CTO
Tractis - Online contracts you can enforce
http://www.tractis.com
--
Email: david.garcia at tractis.com
Skype: deiffbcn
Blog: http://blog.negonation.com
Linkedin: http://www.linkedin.com/in/davebcn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-cx/attachments/20100512/da898914/attachment.htm>