Proposal to create the TX working group
Nat Sakimura
sakimura at gmail.com
Thu Nov 13 08:40:26 PST 2008
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> 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 enable
> s 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:
>
>
> - Public Key Exchange method
> - A Public Key Cryptography based digital signature method.
> - Legally binding contract format.
> - Query/response communication protocols for establishing and
> canceling of the contract.
> - Message Encryption method to be used for the relevant
> communications.
> - Notification interface for asynchronous communications.
> - Possible extension and profiling of [AX] to accommodate the above.
>
> - Provisions for long term storage of the contracts.
> - Conformance requirements for other data transfer protocol bindings
>
>
> - Security, threats and Risk analysis
>
>
> - 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, 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, Ltd. (U.S.A.)
> Toru Yamaguchi, trymch at gmail.com, Cybozu Lab (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]<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>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 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 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://openid.net/pipermail/specs/attachments/20081114/21578e48/attachment-0001.htm
More information about the specs
mailing list