Proposal to create the TX working group

Nat Sakimura sakimura at gmail.com
Sat Nov 8 20:22:11 UTC 2008


Maybe just OpenID Trust Extension just like WS-Trust?
=nat

On Sun, Nov 9, 2008 at 5:06 AM, Nat Sakimura <sakimura at gmail.com> 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?
>
> =nat
>
>
> On Sun, Nov 9, 2008 at 3:50 AM, David Recordon <drecordon at sixapart.com>wrote:
>
>> 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<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/
>>
>>
>>
>
>
> --
> 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/20081109/91409725/attachment-0002.htm>


More information about the specs mailing list