<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:D="DAV:" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"MS PGothic";
panose-1:2 11 6 0 7 2 5 8 2 4;}
@font-face
{font-family:"\@MS PGothic";
panose-1:2 11 6 0 7 2 5 8 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"MS PGothic","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I have to agree with David that this charter is far from minimal
or specific in many respects. One of my concerns is the same as David’s
below – when XMLDSIG and other signature algorithms already exist, it is incumbent
upon the proposers to justify the creation of yet another, incompatible
signature algorithm.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>It is therefore my recommendation that the specifications
council communicate something like this position to the membership to guide
their vote about this working group:<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>The OpenID Specifications
Council recommends that members reject this proposal to create a working group
because the charter is excessively broad, it seems to propose the creation of new
mechanisms that unnecessarily create new ways to do accomplish existing tasks,
such as digital signatures, and it the proposal is not sufficiently clear on
whether it builds upon existing mechanisms such as AX 1.0 in a compatible
manner, or whether it requires breaking changes to these underlying protocols.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>We, as a specs council, have an obligation to promptly produce a
recommendation prior to the membership vote. My stab at our recommendation is
above. Wordsmithing welcome. If you disagree, please supply alternate wording
that you think we should use instead.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'> --
Mike<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> David Recordon
[mailto:recordond@gmail.com] <br>
<b>Sent:</b> Monday, December 22, 2008 10:20 AM<br>
<b>To:</b> Nat Sakimura<br>
<b>Cc:</b> Mike Jones; specs-council@openid.net<br>
<b>Subject:</b> Re: [OIDFSC] FW: Proposal to create the TX working group<o:p></o:p></span></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal style='margin-bottom:12.0pt'>To update Nat's note, the
proposal is actually at <a
href="http://wiki.openid.net/Working_Groups%3AContract_Exchange_1">http://wiki.openid.net/Working_Groups%3AContract_Exchange_1</a>
(the wiki doesn't like periods in URLs).<br>
<br>
While the number of specifications listed has been reduced, it still feels
nebulous in terms of what will be produced as laid out by the purpose and
scope. For example, the scope says that the working group will develop
"A Public Key Cryptography based digital signature method", but isn't
it already defined how to sign chunks of XML? Why would the working group
be developing a new signature mechanism?<br>
<br>
--David<o:p></o:p></p>
<div>
<p class=MsoNormal>On Thu, Dec 18, 2008 at 9:09 PM, Nat Sakimura <<a
href="mailto:n-sakimura@nri.co.jp">n-sakimura@nri.co.jp</a>> wrote:<o:p></o:p></p>
<p class=MsoNormal>The most current version is here: <a
href="http://wiki.openid.net/Working_Groups:Contract_Exchange_1.0"
target="_blank">http://wiki.openid.net/Working_Groups:Contract_Exchange_1.0</a><br>
<br>
Since AX 2.0 WG is spinning up, I have removed it from the possible output of
this WG.<br>
<br>
=nat<br>
<br>
Mike Jones wrote:<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'><br>
Forwarding this note to the list to kick off the actual specs council work on
this spec…<br>
<br>
<br>
(Nat, if there's a newer version of this proposal can you please reply to the
list so we're considering the right version?)<br>
<br>
<br>
*From:* Mike Jones<br>
*Sent:* Wednesday, December 03, 2008 11:01 PM<br>
*To:* Johnny Bufu; Brad Fitzpatrick; 'Dick Hardt'; Josh Hoyt; David Recordon;
Allen Tom<br>
*Subject:* Specifications council actions needed<br>
<br>
<br>
Dear fellow Specifications Council members,<br>
<br>
<br>
The OIDF procedures include:<o:p></o:p></p>
</div>
<p class=MsoNormal>*4.2 Review.* The Specifications Council will
review each proposal within 15 days after receipt and promptly provide notice
to <a href="mailto:specs@openid.net" target="_blank">specs@openid.net</a>
<mailto:<a href="mailto:specs@openid.net" target="_blank">specs@openid.net</a>>
of its recommendation to either accept or reject it, together with a brief
statement of the rationale for its recommendation (including any findings or
opinions by the Specifications Council regarding the criteria for rejection in
the following clauses (a)-(d). The decision to accept or reject the
proposal will then promptly be submitted to a vote of the OIDF membership, in
accordance with the voting procedures in §3. If a proposal is rejected,
it may be modified and resubmitted. The reasons for rejection will be
limited to:<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'><br>
<br>
*(a) *an incomplete Proposal (i.e., failure to comply with §4.1);<br>
<br>
*(b) *a determination that the proposal contravenes the OpenID
community's purpose;<br>
<br>
*(c) *a determination that the proposed WG does not have
sufficient support to succeed or to deliver proposed deliverables within
projected completion dates; or<br>
<br>
*(d) *a determination that the proposal is likely to cause
legal liability for the OIDF or others.<br>
<br>
<br>
We've failed to uphold our responsibility to respond within 15 days to the
proposal below. Can we begin discussion on the technical merits of the
proposal now and reach a consensus determination soon? I believe we owe
that to the community.<br>
<br>
<br>
Thanks,<br>
<br>
-- Mike<br>
<br>
<br>
*From:* <a href="mailto:specs-bounces@openid.net" target="_blank">specs-bounces@openid.net</a>
[mailto:<a href="mailto:specs-bounces@openid.net" target="_blank">specs-bounces@openid.net</a>]
*On Behalf Of *Nat Sakimura<br>
*Sent:* Thursday, November 13, 2008 8:40 AM<br>
*To:* <a href="mailto:specs@openid.net" target="_blank">specs@openid.net</a>; <a
href="mailto:david@sixapart.com" target="_blank">david@sixapart.com</a>; Dick
Hardt<br>
*Subject:* Re: Proposal to create the TX working group<br>
<br>
<br>
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<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'>On Thu, Nov 13, 2008 at 4:02
PM, Nat Sakimura <<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>
<mailto:<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>>>
wrote:<br>
<br>
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>
*Contract Exchange WG Charter (formally TX). *<br>
<br>
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>
*Proposal*:<br>
<br>
(a) *Charter*.<br>
<br>
(i) *WG name*: Contract Exchange WG (formally Trust Exchange
Extension (TX))<br>
<br>
(ii) *Purpose*: The purpose of this WG is to produce a series
of standard OpenID extension to the OpenID Authentication protocol that enables
arbitrary parties to create and exchange a mutually-digitally-signed legally
binding "contract" that are both broadband and mobile friendly
by defining appropriate bindings for each use case. <br>
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.<br>
<br>
<br>
(iii) *Scope*:<br>
<br>
Scope of the work<br>
<br>
* Development of the specifications including:<o:p></o:p></p>
</div>
<p class=MsoNormal> o Public Key Exchange
method<br>
o A Public Key Cryptography based digital
signature method.<br>
o Legally binding contract format.<br>
o Query/response communication protocols for
establishing<o:p></o:p></p>
<div>
<p class=MsoNormal><br>
and canceling of the contract.<o:p></o:p></p>
</div>
<p class=MsoNormal> o Message Encryption
method to be used for the relevant<br>
communications.<br>
o Notification interface for asynchronous
communications.<br>
o Possible extension and profiling of [AX] to
accommodate<br>
the above.<br>
o Provisions for long term storage of the
contracts.<br>
<br>
o Conformance requirements for other data
transfer protocol<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'><br>
bindings<br>
<br>
* Security, threats and Risk analysis<o:p></o:p></p>
</div>
<p class=MsoNormal> o Perform Security Risk
analysis and profiles for best practice<o:p></o:p></p>
<div>
<p class=MsoNormal><br>
<br>
Out of scope<br>
<br>
* Term negotiation: Actual negotiation of the terms of a contract<br>
should be dealt with out-of-band or by other
specifications.<br>
<br>
* Assurance programs or other identity governance frameworks.<br>
* It is the intent that this specification be usable by any trust<br>
community, whether it uses conventional PKI hierarchies,<br>
peer-to-peer trust mechanisms, reputation systems, or other<br>
forms of trust assurance. The specification of any
particular<br>
trust root, trust hierarchy, or trust policy is explicitly
out<br>
of scope.<br>
<br>
<br>
(iv) *Proposed* 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.<br>
<br>
<br>
<br>
(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.<br>
<br>
(vi) *Language* in which the WG will conduct business:
English.<br>
<br>
(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.<br>
<br>
(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.<br>
<br>
<br>
<br>
(b) *Background Information*.<br>
<br>
(i) Related work being done by other WGs or organizations:<br>
<br>
* OpenID Attribute Exchange Extension 1.0 [AX]<o:p></o:p></p>
</div>
<p class=MsoNormal> <<a
href="http://openid.net/specs/openid-attribute-exchange-1_0.html"
target="_blank">http://openid.net/specs/openid-attribute-exchange-1_0.html</a>><br>
<br>
* LIberty Alliance Identity Governance Framework [IGF] 1.0 Draft<br>
<<a
href="http://www.projectliberty.org/liberty/content/download/4329/28939/file/liberty-igf-draft-1.0-2008-06-21.zip"
target="_blank">http://www.projectliberty.org/liberty/content/download/4329/28939/file/liberty-igf-draft-1.0-2008-06-21.zip</a>><br>
<br>
<br>
* _XML Advanced Electronic Signatures [XAdES]_<o:p></o:p></p>
<div>
<p class=MsoNormal><br>
* WS-Trust 1.3 [WS-trust]<o:p></o:p></p>
</div>
<p class=MsoNormal> <<a
href="http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.doc"
target="_blank">http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.doc</a>><br>
* XRI 2.0 [XRI]<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'><br>
* XDI 1.0 [XDI]<br>
* Vendor Relationship Management [VRM]<br>
<br>
(ii) Proposers:<o:p></o:p></p>
</div>
<p class=MsoNormal> Drummond Reed, <a
href="mailto:drummond.reed@parity.com" target="_blank">drummond.reed@parity.com</a>
<mailto:<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>
<mailto:<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>
<mailto:<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>
<mailto:<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>
<mailto:<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>
<mailto:<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>
<mailto:<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>
<mailto:<a href="mailto:tatsuki@nri.com" target="_blank">tatsuki@nri.com</a>>,
NRI America, Ltd. (U.S.A.)<br>
<br>
Toru Yamaguchi, <a href="mailto:trymch@gmail.com" target="_blank">trymch@gmail.com</a>
<mailto:<a href="mailto:trymch@gmail.com" target="_blank">trymch@gmail.com</a>>,
Cybozu Lab (Japan)<br>
<br>
<br>
Editors:<br>
<br>
Nat Sakimura, <a href="mailto:n-sakimura@nri.co.jp" target="_blank">n-sakimura@nri.co.jp</a>
<mailto:<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>
* Sakimura, N., et. al "OpenID Trusted data eXchange
Extention Specification (draft)", Oct. 2008. [TX2008] <<a
href="http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/*checkout*/spec/openid-trust-exchange-1_0.html?root=openidtx"
target="_blank">http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/*checkout*/spec/openid-trust-exchange-1_0.html?root=openidtx</a>>.
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'><br>
<br>
<br>
<br>
On Wed, Nov 12, 2008 at 6:39 AM, David Recordon <<a
href="mailto:drecordon@sixapart.com" target="_blank">drecordon@sixapart.com</a>
<mailto:<a href="mailto:drecordon@sixapart.com" target="_blank">drecordon@sixapart.com</a>>>
wrote:<br>
<br>
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>
<br>
--David<br>
<br>
<br>
<br>
On Nov 11, 2008, at 1:13 PM, Martin Paljak wrote:<br>
<br>
On 09.11.2008, at 20:51, Nat Sakimura wrote:<br>
<br>
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>
<br>
<o:p></o:p></p>
</div>
<p class=MsoNormal>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>
<<a href="http://openid.ee" target="_blank">http://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> <<a
href="http://openid.ee" target="_blank">http://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).<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'><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>
<br>
<br>
<br>
-- <br>
<br>
Nat Sakimura (=nat)<br>
<a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br>
<br>
<br>
<br>
<br>
-- <br>
Nat Sakimura (=nat)<br>
<a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><o:p></o:p></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</body>
</html>