Proposal to create the TX working group
santosh subramanian
subra.santosh at gmail.com
Mon Nov 3 22:30:45 UTC 2008
Hi Nat,
We have been working on a similar problem. We would also like to be a part
of the working group. How do we go about it ?
Thanks,
Santosh Subramanian
Shishir Randive
Rob Johnson
2008/11/1 Nat Sakimura <sakimura at gmail.com>
> 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<http://openid.net/foundation/intellectual-property/>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<http://www.projectliberty.org/liberty/content/download/4329/28939/file/liberty-igf-draft-1.0-2008-06-21.zip>
>> - XML Advanced Electronic Signatures (XAdES)<http://www.w3.org/TR/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]<http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/*checkout*/spec/openid-trust-exchange-1_0.html?root=openidtx>.
>>
>>
>> _______________________________________________
>> 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/
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20081103/acc55917/attachment-0002.htm>
More information about the specs
mailing list