[Specs-cx] Timestamping contracts (Re: Multi-party contract)

[nara hideki]

Hi, David.

Thank you very much for mentioning the timestamping.
( I changed the subject )

=Nat and me have recognized the timestamping of contracts and
one reason we firstly adapted XML to CX is the timestamping.

We should discuss this topic more and implement it with
the balancing other topics like  software libraries as you mentioned.

Thanks
----
hdknr

2010/5/12 David García <david.garcia at tractis.com>:
> 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
>
>
>