I was pointed out by Dick that "Key Exchnage" really should be "Key Discovery". I agree. So, I would do s/Key Exchange/Key Discovery/g. <br><br>Cheers, <br><br>=nat<br><br><div class="gmail_quote">On Thu, Nov 13, 2008 at 4:02 PM, Nat Sakimura <span dir="ltr"><<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi. <br><br>Here is the modified version of the charter based on the discussion at IIW. I chose Contract Exchange instead of Contract Negotiation since detailed negotiation is out of scope. <br>
<br>Cheers, <br><br>=nat<br>
<br>
<p style="margin-left: 42pt; text-align: left;" align="left"><b><span style="font-size: 13.5pt;" lang="EN-US">Contract Exchange WG
Charter (formally TX). </span></b></p>
<p style="text-align: left;" align="left"><span style="font-size: 12pt;" lang="EN-US"><div class="Ih2E3d">In accordance with the OpenID Foundation IPR policies and
procedures this note proposes the formation of a new working group chartered to
produce an OpenID specification. As per Section 4.1 of the Policies, the
specifics of the proposed working group are:<br>
<br>
<br>
<b>Proposal</b>:<br>
<br>
(a) <b>Charter</b>.<br>
<br></div>
(i) <b>WG name</b>: Contract
Exchange WG (formally Trust Exchange Extension (TX))<br>
<br>
(ii) <b>Purpose</b>: The
purpose of this WG is to produce a series of standard OpenID extension to the
OpenID Authentication protocol that enable<span style="color: navy;">s</span>
arbitrary parties to create and exchange <span style="color: navy;">a</span>
mutually<span style="color: navy;">-</span>digitally<span style="color: navy;">-</span>signed
legally binding "contract" that are <span> </span>both broadband and mobile friendly by defining
appropriate bindings for each use case. </span></p>
<p style="text-align: left;" align="left"><span style="font-size: 12pt;" lang="EN-US">For this purpose, (1) public key exchange, (2) signed
request and response based on the public keys, (3) content encryption based on
public key, (4) extensible data transfer method, (5) contract format, (6)
notification methods for asynchronous communications are needed to be defined.
For this purpose, this WG will explorer the possibility of using/extending
OpenID Attribute Exchange [AX] as well as defining new extensions where it may
fit. </span></p><div class="Ih2E3d">
<p style="text-align: left;" align="left"><span style="font-size: 12pt;" lang="EN-US"><br>
(iii) <b>Scope</b>: <br>
<br>
Scope of the work</span></p>
</div><ul type="disc"><li style="text-align: left;"><span style="font-size: 12pt;" lang="EN-US"> Development of the specifications including:</span></li></ul>
<ul type="disc"><ul type="circle"><li style="text-align: left;"><span style="font-size: 12pt;" lang="EN-US">Public Key Exchange method</span></li><li style="text-align: left;">
<span style="font-size: 12pt;" lang="EN-US">A Public Key Cryptography based digital signature method. </span></li><li style="text-align: left;"><span style="font-size: 12pt;" lang="EN-US">Legally binding contract format. </span></li>
<li style="text-align: left;"><span style="font-size: 12pt;" lang="EN-US">Query/response communication protocols for establishing and
canceling of the contract. </span></li><li style="color: navy; text-align: left;"><span style="font-size: 12pt; color: windowtext;" lang="EN-US">Message Encryption method to be used for the
relevant communications. </span><span style="font-size: 12pt;" lang="EN-US"></span></li><li style="color: navy; text-align: left;"><span style="font-size: 12pt; color: windowtext;" lang="EN-US">Notification interface for asynchronous
communications. </span><span style="font-size: 12pt;" lang="EN-US"></span></li><li style="color: navy; text-align: left;"><span style="font-size: 12pt; color: windowtext;" lang="EN-US">Possible extension and profiling of [AX] to accommodate
the above. </span><span style="font-size: 12pt;" lang="EN-US"></span></li><li style="color: navy; text-align: left;"><span style="font-size: 12pt; color: windowtext;" lang="EN-US">Provisions for long term storage of the contracts. </span><span style="font-size: 12pt;" lang="EN-US"></span></li>
<div class="Ih2E3d">
<li style="color: navy; text-align: left;"><span style="font-size: 12pt; color: windowtext;" lang="EN-US">Conformance requirements for other data transfer
protocol bindings</span><span style="font-size: 12pt;" lang="EN-US"></span></li></div></ul></ul><div class="Ih2E3d">
<ul type="disc"><li style="text-align: left;"><span style="font-size: 12pt;" lang="EN-US">Security, threats and Risk analysis</span></li></ul>
<ul type="disc"><ul type="circle"><li style="text-align: left;"><span style="font-size: 12pt;" lang="EN-US">Perform Security Risk analysis and profiles for best practice</span></li>
</ul></ul>
<p style="text-align: left;" align="left"><span style="font-size: 12pt;" lang="EN-US"> Out of scope</span></p>
</div><ul type="disc"><div class="Ih2E3d"><li style="text-align: left;"><span style="font-size: 12pt;" lang="EN-US">Term negotiation: Actual negotiation of the terms of a contract
should be dealt with out-of-band or by other specifications. </span></li></div><div class="Ih2E3d"><li style="text-align: left;"><span style="font-size: 12pt;" lang="EN-US">Assurance programs or other identity governance frameworks.</span></li>
<li style="text-align: left;"><span style="font-size: 12pt;" lang="EN-US">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.</span></li></div></ul>
<p style="margin-bottom: 12pt; text-align: left;" align="left"><span style="font-size: 12pt;" lang="EN-US"><br>
(iv) <b>Proposed</b> List of
Specifications: Sries of specs encompassing the above requirements. The
actual spec may happened to be just an expansion of AX or several news specs as
it will be determined in the WG. Expected completion of the first iteration is
in Q1 2009.<div class="Ih2E3d"><br>
<br>
(v) <b>Anticipated audience or
users of the work</b>: 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.<br>
<br>
(vi) <b>Language</b> in which
the WG will conduct business: English.<br>
<br>
(vii) <b>Method of work</b>:
E-mail discussions on the working group mailing list, working group conference
calls, and possibly face-to-face meetings at conferences.<br>
<br></div>
(viii) <b>Basis for determining
when the work of the WG is completed</b>: 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.<div class="Ih2E3d"><br>
<br>
(b) <b>Background Information</b>.<br>
<br>
(i) Related work being done by other WGs or organizations: </div></span></p>
<ul type="disc"><li style="text-align: left;"><span style="font-size: 12pt;" lang="EN-US"><a href="http://openid.net/specs/openid-attribute-exchange-1_0.html" target="_blank">OpenID
Attribute Exchange Extension 1.0 [AX]</a></span></li><div class="Ih2E3d"><li style="text-align: left;"><span style="font-size: 12pt;" lang="EN-US"><a href="http://www.projectliberty.org/liberty/content/download/4329/28939/file/liberty-igf-draft-1.0-2008-06-21.zip" target="_blank">LIberty Alliance Identity Governance Framework [IGF] 1.0
Draft</a> </span></li></div><li style="text-align: left;"><u><span style="font-size: 12pt; color: blue;" lang="EN-US">XML Advanced Electronic Signatures [XAdES]</span></u><span style="font-size: 12pt;" lang="EN-US"></span></li>
<li style="text-align: left;"><span style="font-size: 12pt;" lang="EN-US"><a href="http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.doc" target="_blank">WS-Trust
1.3 [WS-trust] </a></span></li><li style="text-align: left;"><span style="font-size: 12pt;" lang="EN-US">XRI 2.0 [XRI]</span></li><li style="text-align: left;">
<span style="font-size: 12pt;" lang="EN-US">XDI 1.0 [XDI]</span></li><li style="text-align: left;"><span style="font-size: 12pt;" lang="EN-US">Vendor Relationship Management [VRM]</span></li>
</ul>
<p style="margin-bottom: 12pt; text-align: left;" align="left"><span style="font-size: 12pt;" lang="EN-US"> <br>
(ii) Proposers:</span></p>
<p style="text-align: left;" align="left"><span style="font-size: 12pt;" lang="EN-US"><div class="Ih2E3d"> Drummond Reed, <a href="mailto:drummond.reed@parity.com" target="_blank">drummond.reed@parity.com</a>,
Cordance/Parity/OASIS (U.S.A)<br>
Henrik Biering, <a href="mailto:hb@netamia.com" target="_blank">hb@netamia.com</a>,
Netamia (Denmark)<br>
Hideki Nara, <a href="mailto:hdknr@ic-tact.co.jp" target="_blank">hdknr@ic-tact.co.jp</a>,
Tact Communications (Japan)<br>
John Bradeley, <a href="mailto:jbradley@mac.com" target="_blank">jbradley@mac.com</a>,
OASIS IDTrust Member Section (Canada)<br>
Mike Graves, <a href="mailto:mgraves@janrain.com" target="_blank">mgraves@janrain.com</a>,
JanRain, Inc. (U.S.A.)<br>
Nat Sakimura, <a href="mailto:n-sakimura@nri.co.jp" target="_blank">n-sakimura@nri.co.jp</a>,
Nomura Research Institute, Ltd.(Japan)<br>
Robert Ott, <a href="mailto:robert.ott@clavid.com" target="_blank">robert.ott@clavid.com</a>,
Clavid (Switzerland)<br>
Tatsuki Sakushima, <a href="mailto:tatsuki@nri.com" target="_blank">tatsuki@nri.com</a>,
NRI America, Ltd. (U.S.A.)<br></div>
Toru Yamaguchi, <a href="mailto:trymch@gmail.com" target="_blank">trymch@gmail.com</a>,
</span><cite><span style="font-family: Century; font-style: normal;" lang="EN-US">Cybozu</span></cite><cite><span style="font-family: Century;" lang="EN-US"> </span></cite><span style="font-size: 12pt;" lang="EN-US">Lab (Japan)</span></p>
<p style="text-align: left;" align="left"><span style="font-size: 12pt;" lang="EN-US"><div class="Ih2E3d"><br>
Editors:<br>
<br>
Nat Sakimura, <a href="mailto:n-sakimura@nri.co.jp" target="_blank">n-sakimura@nri.co.jp</a>,
Nomura Research Institute, Ltd.<br>
<br>
(iii) Anticipated Contributions: <br></div>
* <a href="http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/*checkout*/spec/openid-trust-exchange-1_0.html?root=openidtx" target="_blank">Sakimura, N., et. al "OpenID Trusted data eXchange
Extention Specification (draft)", Oct. 2008. [TX2008]</a>. </span></p><div><div></div><div class="Wj3C7c">
<p><span lang="EN-US"> </span></p>
<p style="text-align: left;" align="left"><span style="font-size: 12pt;" lang="EN-US"></span></p>
<p><span lang="EN-US"> </span></p>
<br><br><div class="gmail_quote">On Wed, Nov 12, 2008 at 6:39 AM, David Recordon <span dir="ltr"><<a href="mailto:drecordon@sixapart.com" target="_blank">drecordon@sixapart.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Just wanted to add that Nat is running a session on TX at IIW this afternoon. We should definitly chat about the needs being expressed in this thread and how they might be able to be solved with OpenID.<br><font color="#888888">
<br>
--David</font><div><div></div><div><br>
<br>
On Nov 11, 2008, at 1:13 PM, Martin Paljak wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 09.11.2008, at 20:51, Nat Sakimura wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
As to AX+SAML (or for that matter XAdES) is concerned, that is a valid approach, but if I were to use SAML, I would use<br>
</blockquote>
<br>
Just to clarify a technical detail: The XAdES example regarding Estonia you mentioned earlier does not include transporting XAdES payloads over OpenID AX (which seems to be the purpose of the discussed workgroup where the similarities of SAML over AX come in). The special behavior and out of band assurances given by <a href="http://openid.ee" target="_blank">openid.ee</a> does not include anything new on the protocol level, just added semantics to basic OpenID transactions. If we could use PDF signatures as legally valid signatures in Estonia, it could be PDF based signatures instead of XAdES, or ODF signatures, or MS .doc signatures.<br>
<br>
FYI, <a href="http://openid.ee" target="_blank">openid.ee</a> allows a RP to upload a contract (template) which must be agreed with and digitally signed (legally binding signature resulting in an XAdES document with the filled in contract signed by the user with an ID-card and stored on the OP) before the OP starts issuing positive assertions about the given user to the given RP. The contract could be a document of any kind (PDF, JPG, DOC, TXT) and the only thing that is transferred to the RP over AX is a 'secret url' from where the RP can download the signed contract (XAdES container with the possibly PDF contract in it).<br>
<br>
The actual assurance (that the user has signed the contract the RP has uploaded) comes from out of band agreements/contracts between OP and RP. The AX attribute is just an extra option, if the RP wishes to automatically fetch and store the signed contract somewhere.<br>
<br>
Basically it is an advanced and legally binding 'I agree with terms and conditions' checkbox built on top of standard OpenID.<br>
With legally binding I mean that it is dead simple in the court: "Here are the terms and conditions you digitally signed and which you have violated" as checking checkboxes and pressing 'continue' is not a legally binding action in Estonia, at least I don't know of any court cases about it.<br>
<br>
If you need an example use case, think of signing and faxing NDA-s before you can download some simple "secret" product documentation.<br>
<br>
<br>
-- <br>
Martin Paljak<br>
<a href="http://martin.paljak.pri.ee" target="_blank">http://martin.paljak.pri.ee</a><br>
+372.515.6495<br>
<br>
</blockquote>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br></div></div>-- <br><div><div></div><div class="Wj3C7c">Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br>