[OIDFSC] [VOTE] Contract Exchange Working Group Proposal

Mon Feb 2 14:52:09 UTC 2009

Yes. After all, it is all about contract. The spec will be very clear  
on it. Also, I think the WG will produce a usecase and requirement  
document a la OASIS Style.

=nat at TOKYO via iPhone

On 2009/02/02, at 2:42, Allen Tom <atom at yahoo-inc.com> wrote:

> Hi Nat,
>
> Please be sure to clearly define the term "Contract" in the spec,  
> and it would be good to describe some usecases either in the  
> appendix or have the spec link to a separate document with some  
> usecases.  One of the reasons why the specs committee took so long  
> to vote on the CX proposal is because of a general lack of  
> understanding as to what CX is supposed to do.
>
> Allen
>
>
> Nat Sakimura wrote:
>>
>> Wow, Brad,  it has been such a long time since I have seen you on  
>> the list!
>>
>> By the way, it is "contract" and not "contact".
>>
>> "contract" by the way, usually is mutual agreement between parties.  
>> In many jurisdictions it does not have to be written down at all to  
>> be a valid contract. However, we usually write down the contract  
>> "just in case" when we have to bring it to the court. To prepare  
>> for such circumstances, we usually have the following items in a  
>> contract. (Note: not all contact have all the items below, but I  
>> consider it is generally a good practice to have them. At least, my  
>> legal department would not accept one if any of them is missing.)
>>
>> 1. Identifier of the parties involved. (Usually, registered name  
>> and address.)
>> 2. General purpose of the agreement. ("Preemable").
>> 3. Business Term that the parties agreed to.
>> 4. Expiration Date and Renewal method (if relevant).
>> 5. Termination Clause.
>> 6. Non disclosure
>> 7. Indemnity liability, Remedies to damage
>> 8. Jurisdiction
>> 9. Dispute resolution point
>> 10. Date
>> 11. Credential
>>
>> Credential, in case of paper contract, usually is signature in the  
>> Western world. In Asia, it usually is a registered seal. What makes  
>> them a valid credential depends on the relevant laws and judicial  
>> precedents.
>>
>> From the point of the workflow, as it is depicted in http://en.wikipedia.org/wiki/Contract 
>> , it is composed of offer and acceptance. My idea is to use OpenID  
>> protocols to make an offer including 1 to 10 and 11 of the offering  
>> party, and if the offered party accepts it, returns the acceptance  
>> with his portion of 11. This is just my idea, and the details is  
>> needed to be discussed inside the WG.
>>
>> Cheers,
>>
>> =nat
>>
>>
>> On Sat, Jan 31, 2009 at 3:26 AM, Brad Fitzpatrick <brad at danga.com>  
>> wrote:
>> Can I vote neutral?  While I'm very much +1 on the previously  
>> discussed OpenID/OAuth hybrid proposal, this one's more "meh" to  
>> me.  I'm not against it, though.  Its charter page doesn't even  
>> explain use cases or what a "contact" is (though I was amused to  
>> see it put in quotes and then later never explained.)
>>
>> On Wed, Jan 28, 2009 at 11:09 AM, David Recordon  
>> <recordond at gmail.com> wrote:
>> Since we've had so many different threads on this proposal, I'd like
>> to have one final thread where there is a clear vote held on the
>> latest revision of the proposal.  The proposal can be found at
>> http://wiki.openid.net/Working_Groups%3AContract_Exchange_1 and in  
>> the
>> email below.  If you're a member of the Specs Council, please respond
>> ASAP.
>>
>> Thanks,
>> --David
>>
>> (i) WG name
>> Contract Exchange Extension Working Group
>>
>> (ii) Purpose
>> The purpose of this WG is to produce a standard OpenID extension to
>> the OpenID Authentication protocol that enables arbitrary parties to
>> create and exchange a mutually-digitally-signed "contract". This
>> contract can be both broadband and mobile friendly through  
>> appropriate
>> bindings that will be defined for each use case.
>>
>> (iii) Scope
>> Development of a specification that allows parties to exchange a
>> mutually-digitally-signed contract leveraging on OpenID  
>> Authentication
>> 2.0 and OpenID Attribute Exchange 2.0 via the appropriate bindings
>> defined in the specification.
>>
>> Out of scope
>>
>>    * UI and user experience: The Working Group will develop the wire
>> protocol and and any related processing mechanisms required to  
>> support
>> it but user interface and experience is out of scope.
>>    * Public Key Discovery method: This functionality will be either
>> defined in the XRD 1.0 specification currently in progress at the
>> OASIS XRI TC or a mechanism that works with OpenID Authentication
>> 2.0/2.1 discovery will be defined independently.
>>    * Terms negotiation: Actual negotiation of the terms of a contract
>> should be dealt with out-of-band or by other specifications.
>>    * Assurance: These will be handled by third-party assurance
>> programs or other identity governance frameworks.
>>    * Trust hierarchies. It is the intent that this specification be
>> usable by any trust community, whether it uses conventional PKI
>> hierarchies, peer-to-peer trust mechanisms, reputation systems, or
>> other forms of trust assurance. The specification of any particular
>> trust root, trust hierarchy, or trust policy is explicitly out of
>> scope.
>>
>> (iv) Proposed List of Specifications
>>    * Contract Exchange 1.0 - Expected completion of the first
>> iteration is in Q1 2009.
>>
>> (v) Anticipated audience or users of the work
>> Implementers of OpenID Providers and Relying Parties, especially  
>> those
>> who require security and accountability features to exchange  
>> sensitive
>> customer information (e.g. personally identifiable information and
>> credit card numbers) responsibly among trusted parties.
>>
>> (vi) Language in which the WG will conduct business
>> English.
>>
>> (vii) Method of work
>> E-mail discussions on the working group mailing list, working group
>> conference calls, and possibly face-to-face meetings at conferences.
>>
>> (viii) Basis for determining when the work of the WG is completed
>> Drafts will be evaluated on the basis of whether they increase or
>> decrease consensus within the working group. The work will be
>> completed once it is apparent that maximal consensus on the drafts  
>> has
>> been achieved, consistent with the purpose and scope.
>>
>> (b) Background Information.
>> (i) Related work being done by other WGs or organizations
>>    * OpenID Authentication 2.1 [AN]
>>    * OpenID Attribute Exchange Extension 2.0 [AX]
>>    * LIberty Alliance Identity Governance Framework [IGF] 1.0 Draft
>>    * XML Advanced Electronic Signatures [XAdES]
>>    * WS-Trust 1.3 [WS-trust]
>>    * XRI 2.0 and XRI 3.0 [XRI]
>>    * XRD 1.0 [XRI]
>>    * XDI 1.0 [XDI]
>>    * Vendor Relationship Management [VRM]
>>
>> (ii) Proposers
>>    * Drummond Reed, =drummond, drummond.reed at parity.com,
>> Cordance/Parity/OASIS (U.S.A)
>>    * Henrik Biering, hb at netamia.com, Netamia (Denmark)
>>    * Hideki Nara, hdknr at ic-tact.co.jp, Tact Communications (Japan)
>>    * John Bradeley, jbradley at mac.com, OASIS IDTrust Member Section  
>> (Canada)
>>    * Mike Graves, mgraves at janrain.com, JanRain, Inc. (U.S.A.)
>>    * Nat Sakimura, n-sakimura at nri.co.jp, Nomura Research Institute,  
>> Ltd.(Japan)
>>    * Robert Ott, robert.ott at clavid.com, Clavid (Switzerland)
>>    * Tatsuki Sakushima, tatsuki at nri.com, NRI America, Inc. (U.S.A.)
>>    * Toru Yamaguchi, trymch at gmail.com, DeNA Co. Ltd.  (Japan)
>>
>> Editors:
>> Nat Sakimura, n-sakimura at nri.co.jp, Nomura Research Institute, Ltd.
>>
>> (iii) Anticipated Contributions
>>    * Sakimura, N., et. al "OpenID Trusted data eXchange Extention
>> Specification (draft)", Oct. 2008. [TX2008].
>>
>>
>>
>>
>> -- 
>> Nat Sakimura (=nat)
>> http://www.sakimura.org/en/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20090202/5b841b5c/attachment-0002.htm>