[OIDFSC] FW: Proposal to create the TX working group
David Recordon
recordond at gmail.com
Mon Dec 22 18:20:07 UTC 2008
To update Nat's note, the proposal is actually at
http://wiki.openid.net/Working_Groups%3AContract_Exchange_1 (the wiki
doesn't like periods in URLs).
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?
--David
On Thu, Dec 18, 2008 at 9:09 PM, Nat Sakimura <n-sakimura at nri.co.jp> wrote:
> 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/
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20081222/4e874908/attachment-0002.htm>
More information about the specs-council
mailing list