[Specs-cx] Multi-party contract

[nara hideki]

Hi, David, Thank you for your quick response.

Let me  provide a following XML scheme for /Contract/Party.
Any discussion is welcome.

/Contract/Party [2..n]
 - Stakeholders

/Contract/Party/@id [1..1]
 - Identifier of the specific party

/Contract/Party/@Rel [1..1]
 - Type of the party in this contract( proposer, ... )

/Contract/Party/xmldsig:Signature [1..1]
 - XML Signature  singing node.

/Contract/Party/obligation  [ 1..n ]
 -  Obligations owed by the party

/Contract/Party/obligation/@endpoint (0..1)
 -  Service endpoint of the obligation
 -  Other party(specified "to") included in this contract can request service
 -  Response must be encrypted with requesting Party's public key
 - @endpoint can be unique in the Party
 - If @endpoint is unique, request would be simple like this::
       endpoint?to={{ requesting Party }}
 - if no @endpoint specified or blank, no REST service is provided.

/Contract/Party/obligation/to [0..n]
 - Parties which can request @endpoint and must be one of

/Contract/Party/@id
 - If no "to" element is specified, any party in this Contract can
request @endpoint( i.e. wildcard )

/Contract/Party/obligation/param [1..n]
 - parameter provided for the obligation

/Contract/Party/obligation/param/@type  [1..1]
 - Parameter type

/Contract/Party/obligation/param/@id (1)
 - Identifier. param/@text can be replaced for {{@id}}  in template.
 - ( namespace might be used to avoid contention between multiple parties )

----
hdknr


2010/5/11 David García <david.garcia at tractis.com>:
> Hi Nara,
>
> doing multilateral obligations with /Contract/Party/obligation/to fits for
> me. It's kinda REST syntax.
> This solution and the one proposed by Nat are both good if we define
> wildcards on Nat's, because as Nara said the "any" wildcard would be very
> useful.
>
> Best regards
>
> Dave
>
> 2010/5/11 nara hideki <hdknr at ic-tact.co.jp>
>>
>> H, Nat and David.
>>
>> I think that /Contract/Party/obligation seems to be better.
>>
>>  1.  easier to grasp stakeholders in a contract
>>  2.  each party must sign the contract document and a signature
>> element must be needed.
>>  3.  an obligation could be 1 to N relations. Multiple
>> /Contract/Party/obligation/to can be used.
>>  4.  a party can owe multiple obligation to different parties in a
>> contract.
>>
>> One thing we should think of  is  an obligation to "any party in
>> contract".
>> Although we can provide every obligation to each party, but a wildcard
>> is quite useful especially when
>> the number of parties are big.
>>
>>  ----
>> hdknr
>>
>> 2010/5/7 David Garcia <david.garcia at tractis.com>:
>> > +1 to the second one. I think it's more powerful on multilateral
>> > contracts,
>> > because it allows to define party to party obligations with a fine grain
>> > detail.
>> > Best regards
>> >
>> > David Garcia
>> > El 07/05/2010, a las 06:36, Nat Sakimura <sakimura at gmail.com> escribió:
>> >
>> > In the current draft, <obiligation> is an child element of <party>.
>> > However,
>> > when we think about the multi-party scenario,
>> > unless we specify the target that the party is obliged to, it would have
>> > no
>> > meaning.
>> > Thus, we would have two ways to implement it.
>> > 1. destination as an attribute.
>> > <obligation to="partyid">
>> > 2. Flatten obligations.
>> > <obligation from="partyaid" to="partybid">
>> > Which do you think is better?
>> > From the point of view of writing an application, the second option may
>> > be
>> > easier.
>> > --
>> > Nat Sakimura (=nat)
>> > http://www.sakimura.org/en/
>> > http://twitter.com/_nat_en
>> >
>> > _______________________________________________
>> > Specs-cx mailing list
>> > Specs-cx at lists.openid.net
>> > http://lists.openid.net/mailman/listinfo/openid-specs-cx
>> >
>> > _______________________________________________
>> > 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
>
>
>