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

Thu May 13 07:02:44 UTC 2010

Hi, David,

Sounds great! I'll check that later.

Thanks.
----
hdknr

2010/5/12 David García <david.garcia at tractis.com>:
> Hi Nara,
>
> about the software library I mentioned before I uploaded what I already have
> to github. You can check it at http://github.com/tractis/xades_library .
>
> Currently I uploaded only the ruby implementation. I'm trying to recruit
> some folks to help me doing the same on other languages. I already have a
> contributor to do the same on PHP. My goal is to have a common set of test
> cases for all languages including cross interops (a PHP signs, ruby
> validates and everybody is happy).
>
> As will see the library is very thin because the heavy work is delegated to
> libxmlsec, which is good because there are lots of heavy work done here by
> lib (most about c14n algs) that is complicated to implement and very
> intensive on calculation and libxmlsec is very solid and efficient.
>
> Stay tunned for more :)
>
> Best regards
>
> Dave
>
> 2010/5/12 nara hideki <hdknr at ic-tact.co.jp>
>>
>> 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
>> >
>> >
>> >
>
>
>
> --
> 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
>
>
>