[OIDFSC] FW: Proposal to create the TX working group
Nat Sakimura
n-sakimura at nri.co.jp
Fri Dec 19 05:09:46 UTC 2008
The most current version is here:
http://wiki.openid.net/Working_Groups:Contract_Exchange_1.0
Since AX 2.0 WG is spinning up, I have removed it from the possible
output of this WG.
=nat
Mike Jones wrote:
>
> Forwarding this note to the list to kick off the actual specs council
> work on this spec…
>
>
>
> (Nat, if there’s a newer version of this proposal can you please reply
> to the list so we’re considering the right version?)
>
>
>
> *From:* Mike Jones
> *Sent:* Wednesday, December 03, 2008 11:01 PM
> *To:* Johnny Bufu; Brad Fitzpatrick; 'Dick Hardt'; Josh Hoyt; David
> Recordon; Allen Tom
> *Subject:* Specifications council actions needed
>
>
>
> Dear fellow Specifications Council members,
>
>
>
> The OIDF procedures include:
>
> *4.2 Review.* The Specifications Council will review each proposal
> within 15 days after receipt and promptly provide notice to
> specs at openid.net <mailto:specs at openid.net> 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:
>
> *(a) *an incomplete Proposal (i.e., failure to comply with §4.1);
>
> *(b) *a determination that the proposal contravenes the OpenID
> community’s purpose;
>
> *(c) *a determination that the proposed WG does not have
> sufficient support to succeed or to deliver proposed deliverables
> within projected completion dates; or
>
> *(d) *a determination that the proposal is likely to cause legal
> liability for the OIDF or others.
>
>
>
> 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.
>
>
>
> Thanks,
>
> -- Mike
>
>
>
> *From:* specs-bounces at openid.net [mailto:specs-bounces at openid.net] *On
> Behalf Of *Nat Sakimura
> *Sent:* Thursday, November 13, 2008 8:40 AM
> *To:* specs at openid.net; david at sixapart.com; Dick Hardt
> *Subject:* Re: Proposal to create the TX working group
>
>
>
> 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.
>
> Cheers,
>
> =nat
>
> On Thu, Nov 13, 2008 at 4:02 PM, Nat Sakimura <sakimura at gmail.com
> <mailto:sakimura at gmail.com>> wrote:
>
> Hi.
>
> 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.
>
> Cheers,
>
> =nat
>
> *Contract Exchange WG Charter (formally TX). *
>
> 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:
>
>
> *Proposal*:
>
> (a) *Charter*.
>
> (i) *WG name*: Contract Exchange WG (formally Trust Exchange
> Extension (TX))
>
> (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.
>
> 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.
>
>
> (iii) *Scope*:
>
> Scope of the work
>
> * Development of the specifications including:
>
> o Public Key Exchange method
> o A Public Key Cryptography based digital signature method.
> o Legally binding contract format.
> o Query/response communication protocols for establishing
> and canceling of the contract.
> o Message Encryption method to be used for the relevant
> communications.
> o Notification interface for asynchronous communications.
> o Possible extension and profiling of [AX] to accommodate
> the above.
> o Provisions for long term storage of the contracts.
>
> o Conformance requirements for other data transfer protocol
> bindings
>
> * Security, threats and Risk analysis
>
> o Perform Security Risk analysis and profiles for best practice
>
> Out of scope
>
> * Term negotiation: Actual negotiation of the terms of a contract
> should be dealt with out-of-band or by other specifications.
>
> * Assurance programs or other identity governance frameworks.
> * 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: 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.
>
>
>
> (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 Attribute Exchange Extension 1.0 [AX]
> <http://openid.net/specs/openid-attribute-exchange-1_0.html>
>
> * LIberty Alliance Identity Governance Framework [IGF] 1.0 Draft
> <http://www.projectliberty.org/liberty/content/download/4329/28939/file/liberty-igf-draft-1.0-2008-06-21.zip>
>
>
> * _XML Advanced Electronic Signatures [XAdES]_
> * WS-Trust 1.3 [WS-trust]
> <http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.doc>
> * XRI 2.0 [XRI]
> * XDI 1.0 [XDI]
> * Vendor Relationship Management [VRM]
>
>
> (ii) Proposers:
>
> Drummond Reed, drummond.reed at parity.com
> <mailto:drummond.reed at parity.com>, Cordance/Parity/OASIS (U.S.A)
> Henrik Biering, hb at netamia.com <mailto:hb at netamia.com>, Netamia
> (Denmark)
> Hideki Nara, hdknr at ic-tact.co.jp <mailto:hdknr at ic-tact.co.jp>, Tact
> Communications (Japan)
> John Bradeley, jbradley at mac.com <mailto:jbradley at mac.com>, OASIS
> IDTrust Member Section (Canada)
> Mike Graves, mgraves at janrain.com <mailto:mgraves at janrain.com>,
> JanRain, Inc. (U.S.A.)
> Nat Sakimura, n-sakimura at nri.co.jp <mailto:n-sakimura at nri.co.jp>,
> Nomura Research Institute, Ltd.(Japan)
> Robert Ott, robert.ott at clavid.com <mailto:robert.ott at clavid.com>,
> Clavid (Switzerland)
> Tatsuki Sakushima, tatsuki at nri.com <mailto:tatsuki at nri.com>, NRI
> America, Ltd. (U.S.A.)
>
> Toru Yamaguchi, trymch at gmail.com <mailto:trymch at gmail.com>, Cybozu
> Lab (Japan)
>
>
> Editors:
>
> Nat Sakimura, n-sakimura at nri.co.jp <mailto: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]
> <http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/*checkout*/spec/openid-trust-exchange-1_0.html?root=openidtx>.
>
>
>
>
>
>
>
>
> On Wed, Nov 12, 2008 at 6:39 AM, David Recordon
> <drecordon at sixapart.com <mailto:drecordon at sixapart.com>> wrote:
>
> 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.
>
> --David
>
>
>
> On Nov 11, 2008, at 1:13 PM, Martin Paljak wrote:
>
> On 09.11.2008, at 20:51, Nat Sakimura wrote:
>
> 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
>
>
> 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 openid.ee
> <http://openid.ee> 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.
>
> FYI, openid.ee <http://openid.ee> 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).
>
> 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.
>
> Basically it is an advanced and legally binding 'I agree with terms
> and conditions' checkbox built on top of standard OpenID.
> 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.
>
> If you need an example use case, think of signing and faxing NDA-s
> before you can download some simple "secret" product documentation.
>
>
> --
> Martin Paljak
> http://martin.paljak.pri.ee
> +372.515.6495
>
>
>
>
>
> --
>
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
>
>
>
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
>
More information about the specs-council
mailing list