Hi Nara,<br><br>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".<br>
<br>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.<br><br>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.<br>
<br>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.<br>
<br>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.<br>
<br>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.<br>
<br>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 :) .<br><br>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.<br>
<br>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).<br>
<br>Best regards, and sorry if my email is so extensive... caffeine still didn't make it's effect.<br><br>Dave Garcia <br><br><br><div class="gmail_quote">2010/5/12 nara hideki <span dir="ltr"><<a href="mailto:hdknr@ic-tact.co.jp">hdknr@ic-tact.co.jp</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi,all experts.<br>
<br>
I had a off meeting with =nat about CX in the afternoon.<br>
The followings are what we discussed.<br>
<br>
1. Any party should be able to notfiy CX contract identifier to any<br>
party in the contract.<br>
<br>
Current revision of the CX spec, only "cxstat" is defined. "cxid"<br>
like parameter seems to be wanted to notify the contract identifier.<br>
<br>
2. Signatory is a party who a RP starts to have CX session with.<br>
That should be advertised in XRDS/XRD for the user/server identifier.<br>
<br>
3. /Contract/Pary/obligation/endpoint [0..n] is better. Site can be<br>
configured as a farm with some servers.<br>
But the response must be the exactly same.<br>
<br>
4. Data request provided at /Contract/Party/obligation/endpoint which<br>
is the url and should be requested in the following form ::<br>
<br>
endpoint?id=_cx_identifier_&party=_party_identfier_in_the_contract_<br>
<br>
The "Party" must encrypt the response message using the public key<br>
of "_party_identfier_in_the_contract_"<br>
<br>
5. The contract itself can be fetched by any party in the contract.<br>
Contract request is the exactly same as the "Data request".<br>
But the url is the CX identifier itself.<br>
<br>
6. Any party should state the notification endpoint.<br>
/Contract/Party/returnto is good , isn't it?<br>
<br>
7. Magic Signature could be more simple and better than XML Signature.<br>
<br>
I'm happy if discussion would be split into single item.<br>
<br>
Best regards.<br>
-----<br>
hdknr<br>
<div><div></div><div class="h5">_______________________________________________<br>
Specs-cx mailing list<br>
<a href="mailto:Specs-cx@lists.openid.net">Specs-cx@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-cx" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-cx</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>David Garcia<br>CTO<br>Tractis - Online contracts you can enforce<br><a href="http://www.tractis.com">http://www.tractis.com</a><br>--<br>Email: <a href="mailto:david.garcia@tractis.com">david.garcia@tractis.com</a><br>
Skype: deiffbcn<br>Blog: <a href="http://blog.negonation.com">http://blog.negonation.com</a><br>Linkedin: <a href="http://www.linkedin.com/in/davebcn">http://www.linkedin.com/in/davebcn</a><br><br><br>