Proposal to create the TX working group

Drummond Reed drummond.reed at
Sun Nov 9 07:14:49 UTC 2008

+1. "OpenID Trust Extension" seems like a good fit.





From: specs-bounces at [mailto:specs-bounces at] On Behalf
Of Nat Sakimura
Sent: Saturday, November 08, 2008 12:22 PM
To: david at
Cc: specs at
Subject: Re: Proposal to create the TX working group


Maybe just OpenID Trust Extension just like WS-Trust? 



On Sun, Nov 9, 2008 at 5:06 AM, Nat Sakimura <sakimura at> wrote:

Hi David, 


I do not have any particular attachment to "trust exchange". So, I am ok in
changing it but it would be nice if I can preserve "TX" acronym though. Do
you have any specific suggestions? 




On Sun, Nov 9, 2008 at 3:50 AM, David Recordon <drecordon at>

Hi Nat,

Thanks.  I still would really like to see the name changed for when we think
about the World-wide market.  Do others disagree?  OpenID Trust Exchange
just feels like it doesn't actually describe what the spec does nor how you
can actually exchange "trust".




On Nov 1, 2008, at 2:19 AM, Nat Sakimura wrote:

Hi David, 


Thanks for your comments. My reply inline below: 


2008/11/1 David Recordon <drecordon at>

Hey Nat,

Do you see this as being built atop Attribute Exchange for transport or as
something new that TX defines?  I know Sxip had done work with AX to enable
passing signed and encrypted attributes using SAML assertions.


I have thought of using AX as transport once, then gave up on it when I was
thinking of a mobile use case where the amount of payload that could be
carried with was very limited (URL length in GET is limited to one of
128bytes, 256bytes or 512bytes depending on the handset). So, the current
draft looks a lot like AX with bunch of hard coded attribute types in a way.


As far as carrying SAML token etc. in AX are concerned, similar thing has
also been done by one of the proposer, Robert Ott of Clavid. Martin Paljak
of Estonia ( has been using XAdES with AX. 

These approach are valid. However, I thought the approach partly defeats the
purpose of OpenID. 

If we were using SAML, then we could have used it through out. 

I wanted to make it easier for the developers by sticking to the tag-value

This made us define some of the attribute types defined in SAML and XAdES to
be defined as tag-value tag. 




Is "Trust Exchange" really the best name?  Seems like "trust" is quite a
broad concept so something more specific might be better.


Right. Naming was a bit problematic. I started using "Trust" because the
messaging model is not dis-similar to WS-Trust. Now, the "trust" defined in
WS-Trust in our context is essentially "Contract". So I thought of changing
it to "CX" or something, but then, at least in Japan, quite a few key people
were already exposed to "TX" by now and thus I kept the name "TX". 






On Oct 31, 2008, at 4:21 AM, Nat Sakimura wrote:


Dear Specification Council members: 

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:


Trust Exchange (TX) Extension WG Charter

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:


(a)  Charter.

 (i)  WG name:  Trust Exchange Extension (TX)

 (ii)  Purpose:  The purpose of this WG is to produce a standard OpenID
extension to the OpenID Authentication protocol that enables arbitrary
parties to create and exchange a mutually-digitally-signed legally binding
"contract". This protocol extension aims to be both broadband and mobile
friendly by defining appropriate bindings for each use case. 

Although this specification defines one default protocol for transfering
data based on the contract, the data transfer portion is intended to be
pluggable so that other protocols may also be used for this purpose. 

The extension is not intended to be a general method for defining
attributes; the scope is limited to a specific set of attributes necessary
for contract semantics. The extension will also define a contract signature
based on public key cryptography. When used with a digital certificate
signed by a third party, the contract and signature can be used as an
assertion of conformance to an applicable assurance program.

 (iii)  Scope: 

Scope of the work

*	   Development of the specification including:

*	An extensible tag-value contract format
*	Public Key Cryptography based digital signature method applied to
the above contract format
*	Query/response communication protocols for establishing the contract
*	Default data transfer protocol based on the contract
*	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. 
*	General purpose data type identifiers: this should be determined on
a per-community bases using other specifications such as OpenID Attribute
*	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:  TX 1.0, spec completion expected in
January 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

 (viii)  Basis for determining when the work of the WG is completed:  Draft
1 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 draft has been achieved, consistent
with the purpose and scope.

(b)  Background Information.

 (i)  Related work being done by other WGs or organizations: 

*	LIberty Alliance Identity Governance Framework (IGF) 1.0
<>  Draft 
*	XML Advanced Electronic <>  Signatures

 (ii)  Proposers:

   Drummond Reed, drummond.reed at, Cordance/Parity/OASIS (U.S.A)
   Henrik Biering, hb at, Netamia (Denmark)
   Hideki Nara, hdknr at, Tact Communications (Japan)
   John Bradeley, jbradley at, OASIS IDTrust Member Section (Canada)
   Mike Graves, mgraves at, JanRain, Inc. (U.S.A.)
   Nat Sakimura, n-sakimura at, Nomura Research Institute,
   Robert Ott, at, Clavid (Switzerland)
   Tatsuki Sakushima, tatsuki at, NRI America, Ltd. (U.S.A.)
   Toru Yamaguchi, trymch at, Cyboze Lab (Japan)


   Nat Sakimura, n-sakimura at, Nomura Research Institute, Ltd.

 (iii)  Anticipated Contributions:  
    (1) Sakimura, N., et. al
exchange-1_0.html?root=openidtx> "OpenID Trusted data eXchange Extention
Specification (draft)", Oct. 2008. [TX2008]. 


specs mailing list
specs at


specs mailing list
specs at

Nat Sakimura (=nat)


Nat Sakimura (=nat)

Nat Sakimura (=nat)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the specs mailing list