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

Wed May 12 10:27:51 UTC 2010

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-cx/attachments/20100512/6130c147/attachment-0001.htm>