Maybe just OpenID Trust Extension just like WS-Trust? =nat On Sun, Nov 9, 2008 at 5:06 AM, Nat Sakimura <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]> >> >>> 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, [EMAIL PROTECTED], Cordance/Parity/OASIS >>> (U.S.A) >>> Henrik Biering, [EMAIL PROTECTED], Netamia (Denmark) >>> Hideki Nara, [EMAIL PROTECTED], Tact Communications (Japan) >>> John Bradeley, [EMAIL PROTECTED], OASIS IDTrust Member Section >>> (Canada) >>> Mike Graves, [EMAIL PROTECTED], JanRain, Inc. (U.S.A.) >>> Nat Sakimura, [EMAIL PROTECTED], Nomura Research Institute, >>> Ltd.(Japan) >>> Robert Ott, [EMAIL PROTECTED], Clavid (Switzerland) >>> Tatsuki Sakushima, [EMAIL PROTECTED], NRI America, Ltd. (U.S.A.) >>> Toru Yamaguchi, [EMAIL PROTECTED], Cyboze Lab (Japan) >>> >>> >>> Editors: >>> >>> Nat Sakimura, [EMAIL PROTECTED], 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@openid.net >>> http://openid.net/mailman/listinfo/specs >>> >>> >>> >>> _______________________________________________ >>> specs mailing list >>> specs@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/
_______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs