<p>=hdknr is busily preparing the initial document for the current
thought now (which is going to be submit around Wednesday), but I will
start introducing concept here little by little. (I thought of using
<a href="http://wiki.openid.net">wiki.openid.net</a> but I did not know whether I can control the edits so
that we do not get exposed to IPR pollution, so I am doing it here.) </p>
        <p>The
main concept of the Contract Exchange is to exchange the public key
signed contract among “parties”. Basic model calls for two parties,
with two additional signatories. Under current situation, Signatories
are typically servers/services. </p>
        <p>There will be a contract proposal
(offer) on the table to start with. It is signed by the Offerer. The
signature achieves two things: </p>
        <p>1) Non-repudiation: The offerer really made the offer.<br>
2) Integrity: The accepting party cannot change the offer. </p>
        <p>Once
the accepting party reads the offer and agrees to it, the contract is
established, and to signify it, the accepting party will counter-sign
the document. </p>
        <p>That’s all what it does.<br>
It could subsequently be used as a token to obtain further data or service, i.e., just like an Access Token of OAuth. </p>
        <p>The
protocol that we have been talking at various venues (such as IIW) is
actually very simple. It is almost a simplified version of OAuth with a bit of 
tweaks. </p>
        <p>So, now you understand: There are two important parts in CX. </p>
        <p>1) Contract Format<br>
2) Protocol to exchange signed contract. </p>
        <p>Of the two, 2) is actually easier, as I mentioned above. </p>
        <p>In the following posts, I will talk about each.
</p><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br>