Proposal to create the TX working group

Nat Sakimura sakimura at gmail.com
Thu Nov 13 16:40:26 UTC 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://lists.openid.net/pipermail/openid-specs/attachments/20081114/21578e48/attachment-0002.htm>


More information about the specs mailing list