Proposal to create the TX working group

David Recordon drecordon at sixapart.com
Sat Nov 8 18:50:28 UTC 2008


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".

--David

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 sixapart.com>
> 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 (openid.ee) 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 approach.
> 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".
>
>
>
> --David
>
> 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:
>>
>>
>> Proposal:
>>
>> (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 Exchange.
>> 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 conferences.
>>
>>  (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 (XAdES)
>>
>>  (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, Cyboze Lab (Japan)
>>
>>
>>    Editors:
>>
>>    Nat Sakimura, n-sakimura at nri.co.jp, Nomura Research Institute,  
>> Ltd.
>>
>>  (iii)  Anticipated Contributions:
>>     (1) Sakimura, N., et. al "OpenID Trusted data eXchange  
>> Extention Specification (draft)", Oct. 2008. [TX2008].
>>
>>
>> _______________________________________________
>> specs mailing list
>> specs at openid.net
>> http://openid.net/mailman/listinfo/specs
>
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>
>
>
> -- 
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20081108/7b329ac9/attachment-0002.htm>


More information about the specs mailing list