[Specs-cx] General Concept of Contract Exchange and Contract Schema

[Nat Sakimura]

Thaks Henrik for the Contribution agreement, and also for the comment!

On Tue, Jul 14, 2009 at 7:24 AM, Henrik Biering <hb at netamia.com> wrote:

>  Hi,
> my original contribution agreement is here at the OpenID website:
> http://openid.net/ipr/Non-Assertion-Agreement/executed/
> But since there is some confusion about this, I attach a signed version of
> the newer edition.
>
> I have two (mutually contradictory?) comments to the structure of the
> contract::
>
> 1.
> To keep the structure generic, I propose that
> >Main Content of this Contract
> >- What is to be provided (text)
> >- What is received in return (text)
> is replaced by the more symmetric (e.g. covering NDA and collaboration
> agreements, rather than just seller/buyer relationships):
> Main Content of this Contract
> - Obligations of Party A (text)
> - Obligations of Party B (text)
>

This sounds better to me.


>
>
> 2.
> For specific "order confirmation" type of contracts compatibility with the
> OASIS UBL 2.0 structure would be desirable, if it could be achieved without
> too many complications
>  *UBL 2.0 Order*
>
> Order Class Diagram<http://docs.oasis-open.org/ubl/os-UBL-2.0/uml/UBL-2.0-OrderDocumentAssembly.html>
>
> mod/maindoc/UBL-Order-2.0.ods<http://docs.oasis-open.org/ubl/os-UBL-2.0/mod/maindoc/UBL-Order-2.0.ods>
>
> mod/maindoc/UBL-Order-2.0.xls<http://docs.oasis-open.org/ubl/os-UBL-2.0/mod/maindoc/UBL-Order-2.0.xls>
>
> I think we should explore it.

FYI, we are writing the draft on the basis of tag=value pair.
Would that be ok? Or do you prefer it to be XML based?
Since XRD 1.0 is going to have the XML Signature facilities, most of the OP
and RPs are going to end up having that as well, which means one of the
barriers for us to use XML was removed, so...

> Best Regards,
> Henrik Biering
> =henrik
>
>
>
>
> Nat Sakimura skrev:
>
> Hi.
>
> Sorry that it is so slow for me to get fully involved.
>
> I would like to start discussion from the concept.
> Without understanding the general concept, the discussion can go sideways
> quite easily.
>
> The main aim of Contract Exchange is to define a way to exchange the
> "(possibly) Legally Binding Contract" between parties.
>
> Thus, defining what should be in that Contract Document is one of the main
> task of this WG.
>
> The other task is to define a protocol that enables parties to achieve the
> creation and exchange of such contract documents.
>
> From my experiecne, a contract generally has the following in it.
>
> Contract ID (uri)
> Party A (uri)
> Party B (uri)
> Signatory of Party A (text)
> Signatory of Party B (text)
> Contact Address of Party A (text or uri?)
> Contact Address of Party B (text or uri?)
> Main Content of this Contract
> - What is to be provided (text)
> - What is received in return (text)
> Term and Termination
> - Term / Validity Period of the Contract (Datetime-Datetime)
> - Termination (text)
> - Survival of Certain Terms (text)
> Damages
> - Explanation (text)
> - max amount from A to B (number?)
> - max amount from B to A (number?)
> Non Disclosure
> - How to specify (text)
> - How Long (datetime-datetime)
> Relationship to other Contracts (text)
> Signature of the Signatory of Party A (text)
> Date of the Signature A (datetime)
> Signature of the Signatory of Party B (text)
> Date of the Signature B (datetime)
>
> Is this generally good or are there anything that are necessary in addition
> to these?
>
> Should we specify the schema for these or should we keep it to bare minimal
> and let everything else be represented as text?
> Should we try to incorporate LegalXML etc.
>
> These are the kind of questions that I have in mind for the "Contract as a
> document" portion.
>
> Fortunately, we have Scott Blackmer in this WG who is a knowledgeable
> lawyer, so Scott could cast some insight on this issue.
>
> Then, there will be the protocol for exchanging this along with some
> technical requirement such as inclusion of the public key of the parties.
> I will touch on these on a separate post.
>
> Please discuss.
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
>
> ------------------------------
>
> _______________________________________________
> Specs-cx mailing listSpecs-cx at openid.nethttp://openid.net/mailman/listinfo/specs-cx
>
>
> _______________________________________________
> Specs-cx mailing list
> Specs-cx at openid.net
> http://openid.net/mailman/listinfo/specs-cx
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-cx/attachments/20090714/e3b21fc6/attachment.htm>