|

»

Proposal to create the TX working group

View: New views

18 Messages — Rating Filter: Alert me

	Proposal to create the TX working group by Nat Sakimura-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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@..., Cordance/Parity/OASIS (U.S.A) Henrik Biering, hb@..., Netamia (Denmark) Hideki Nara, hdknr@..., Tact Communications (Japan) John Bradeley, jbradley@..., OASIS IDTrust Member Section (Canada) Mike Graves, mgraves@..., JanRain, Inc. (U.S.A.) Nat Sakimura, n-sakimura@..., Nomura Research Institute, Ltd.(Japan) Robert Ott, robert.ott@..., Clavid (Switzerland) Tatsuki Sakushima, tatsuki@..., NRI America, Ltd. (U.S.A.) Toru Yamaguchi, trymch@..., Cyboze Lab (Japan) Editors: Nat Sakimura, n-sakimura@..., 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@... http://openid.net/mailman/listinfo/specs
	Re: Proposal to create the TX working group by David Recordon-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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. Is "Trust Exchange" really the best name? Seems like "trust" is quite a broad concept so something more specific might be better. --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@..., Cordance/Parity/OASIS (U.S.A) Henrik Biering, hb@..., Netamia (Denmark) Hideki Nara, hdknr@..., Tact Communications (Japan) John Bradeley, jbradley@..., OASIS IDTrust Member Section (Canada) Mike Graves, mgraves@..., JanRain, Inc. (U.S.A.) Nat Sakimura, n-sakimura@..., Nomura Research Institute, Ltd.(Japan) Robert Ott, robert.ott@..., Clavid (Switzerland) Tatsuki Sakushima, tatsuki@..., NRI America, Ltd. (U.S.A.) Toru Yamaguchi, trymch@..., Cyboze Lab (Japan) Editors: Nat Sakimura, n-sakimura@..., 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@... http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@... http://openid.net/mailman/listinfo/specs
	Re: Proposal to create the TX working group by Nat Sakimura :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Hi David, Thanks for your comments. My reply inline below: 2008/11/1 David Recordon <drecordon@...> 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@..., Cordance/Parity/OASIS (U.S.A) Henrik Biering, hb@..., Netamia (Denmark) Hideki Nara, hdknr@..., Tact Communications (Japan) John Bradeley, jbradley@..., OASIS IDTrust Member Section (Canada) Mike Graves, mgraves@..., JanRain, Inc. (U.S.A.) Nat Sakimura, n-sakimura@..., Nomura Research Institute, Ltd.(Japan) Robert Ott, robert.ott@..., Clavid (Switzerland) Tatsuki Sakushima, tatsuki@..., NRI America, Ltd. (U.S.A.) Toru Yamaguchi, trymch@..., Cyboze Lab (Japan) Editors: Nat Sakimura, n-sakimura@..., 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@... http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@... http://openid.net/mailman/listinfo/specs -- Nat Sakimura (=nat) http://www.sakimura.org/en/ _______________________________________________ specs mailing list specs@... http://openid.net/mailman/listinfo/specs
	Re: Proposal to create the TX working group by santosh subramanian :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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@...> Hi David, Thanks for your comments. My reply inline below: 2008/11/1 David Recordon <drecordon@...> 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@..., Cordance/Parity/OASIS (U.S.A) Henrik Biering, hb@..., Netamia (Denmark) Hideki Nara, hdknr@..., Tact Communications (Japan) John Bradeley, jbradley@..., OASIS IDTrust Member Section (Canada) Mike Graves, mgraves@..., JanRain, Inc. (U.S.A.) Nat Sakimura, n-sakimura@..., Nomura Research Institute, Ltd.(Japan) Robert Ott, robert.ott@..., Clavid (Switzerland) Tatsuki Sakushima, tatsuki@..., NRI America, Ltd. (U.S.A.) Toru Yamaguchi, trymch@..., Cyboze Lab (Japan) Editors: Nat Sakimura, n-sakimura@..., 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@... http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@... http://openid.net/mailman/listinfo/specs -- Nat Sakimura (=nat) http://www.sakimura.org/en/ _______________________________________________ specs mailing list specs@... http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@... http://openid.net/mailman/listinfo/specs
	Re: Proposal to create the TX working group by Nat Sakimura-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Hi Santosh, Welcome! The spec committee will be giving out advisory within two weeks. Then, WG is going to be formed, I think. (Would there be a member voting for creating a WG? > the board. Hopefully not.) To join WG, you need to submit IPR agreement, but that's about it. There will be a ML setup for discussion. I am hoping that we can do some face to face at iiw2008b as well. Regards, =nat santosh subramanian wrote: > 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@... <mailto:sakimura@...>> > > Hi David, > > Thanks for your comments. My reply inline below: > > > 2008/11/1 David Recordon <drecordon@... > <mailto:drecordon@...>> > > 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 <http://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: >> >> o An extensible tag-value contract format >> o Public Key Cryptography based digital signature >> method applied to the above contract format >> o Query/response communication protocols for >> establishing the contract >> o Default data transfer protocol based on the contract >> o Conformance requirements for other data transfer >> protocol bindings >> >> * Security, threats and Risk analysis >> >> o 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@... >> <mailto:drummond.reed@...>, Cordance/Parity/OASIS (U.S.A) >> Henrik Biering, hb@... <mailto:hb@...>, >> Netamia (Denmark) >> Hideki Nara, hdknr@... >> <mailto:hdknr@...>, Tact Communications (Japan) >> John Bradeley, jbradley@... <mailto:jbradley@...>, >> OASIS IDTrust Member Section (Canada) >> Mike Graves, mgraves@... >> <mailto:mgraves@...>, JanRain, Inc. (U.S.A.) >> Nat Sakimura, n-sakimura@... >> <mailto:n-sakimura@...>, Nomura Research Institute, >> Ltd.(Japan) >> Robert Ott, robert.ott@... >> <mailto:robert.ott@...>, Clavid (Switzerland) >> Tatsuki Sakushima, tatsuki@... >> <mailto:tatsuki@...>, NRI America, Ltd. (U.S.A.) >> Toru Yamaguchi, trymch@... >> <mailto:trymch@...>, Cyboze Lab (Japan) >> >> >> Editors: >> >> Nat Sakimura, n-sakimura@... >> <mailto:n-sakimura@...>, 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@... <mailto:specs@...> >> http://openid.net/mailman/listinfo/specs > > > _______________________________________________ > specs mailing list > specs@... <mailto:specs@...> > http://openid.net/mailman/listinfo/specs > > > > > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/ > > _______________________________________________ > specs mailing list > specs@... <mailto:specs@...> > http://openid.net/mailman/listinfo/specs > > > ------------------------------------------------------------------------ > > _______________________________________________ > specs mailing list > specs@... > http://openid.net/mailman/listinfo/specs > _______________________________________________ specs mailing list specs@... http://openid.net/mailman/listinfo/specs
	Re: Proposal to create the TX working group by David Recordon-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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@...> 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@..., Cordance/Parity/OASIS (U.S.A) Henrik Biering, hb@..., Netamia (Denmark) Hideki Nara, hdknr@..., Tact Communications (Japan) John Bradeley, jbradley@..., OASIS IDTrust Member Section (Canada) Mike Graves, mgraves@..., JanRain, Inc. (U.S.A.) Nat Sakimura, n-sakimura@..., Nomura Research Institute, Ltd.(Japan) Robert Ott, robert.ott@..., Clavid (Switzerland) Tatsuki Sakushima, tatsuki@..., NRI America, Ltd. (U.S.A.) Toru Yamaguchi, trymch@..., Cyboze Lab (Japan) Editors: Nat Sakimura, n-sakimura@..., 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@... http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@... http://openid.net/mailman/listinfo/specs -- Nat Sakimura (=nat) http://www.sakimura.org/en/ _______________________________________________ specs mailing list specs@... http://openid.net/mailman/listinfo/specs
	Re: Proposal to create the TX working group by Nat Sakimura :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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@...> 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@...> 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@..., Cordance/Parity/OASIS (U.S.A) Henrik Biering, hb@..., Netamia (Denmark) Hideki Nara, hdknr@..., Tact Communications (Japan) John Bradeley, jbradley@..., OASIS IDTrust Member Section (Canada) Mike Graves, mgraves@..., JanRain, Inc. (U.S.A.) Nat Sakimura, n-sakimura@..., Nomura Research Institute, Ltd.(Japan) Robert Ott, robert.ott@..., Clavid (Switzerland) Tatsuki Sakushima, tatsuki@..., NRI America, Ltd. (U.S.A.) Toru Yamaguchi, trymch@..., Cyboze Lab (Japan) Editors: Nat Sakimura, n-sakimura@..., 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@... http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@... http://openid.net/mailman/listinfo/specs -- Nat Sakimura (=nat) http://www.sakimura.org/en/ -- Nat Sakimura (=nat) http://www.sakimura.org/en/ _______________________________________________ specs mailing list specs@... http://openid.net/mailman/listinfo/specs
	Re: Proposal to create the TX working group by Nat Sakimura :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Maybe just OpenID Trust Extension just like WS-Trust? =nat On Sun, Nov 9, 2008 at 5:06 AM, Nat Sakimura <sakimura@...> 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@...> 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@...> 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@..., Cordance/Parity/OASIS (U.S.A) Henrik Biering, hb@..., Netamia (Denmark) Hideki Nara, hdknr@..., Tact Communications (Japan) John Bradeley, jbradley@..., OASIS IDTrust Member Section (Canada) Mike Graves, mgraves@..., JanRain, Inc. (U.S.A.) Nat Sakimura, n-sakimura@..., Nomura Research Institute, Ltd.(Japan) Robert Ott, robert.ott@..., Clavid (Switzerland) Tatsuki Sakushima, tatsuki@..., NRI America, Ltd. (U.S.A.) Toru Yamaguchi, trymch@..., Cyboze Lab (Japan) Editors: Nat Sakimura, n-sakimura@..., 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@... http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@... 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@... http://openid.net/mailman/listinfo/specs
	RE: Proposal to create the TX working group by Drummond Reed :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Some parts of this message have been removed. Learn more about Nabble's security policy. +1. “OpenID Trust Extension” seems like a good fit. =Drummond From: specs-bounces@... [mailto:specs-bounces@...] On Behalf Of Nat Sakimura Sent: Saturday, November 08, 2008 12:22 PM To: david@... Cc: specs@... Subject: Re: Proposal to create the TX working group Maybe just OpenID Trust Extension just like WS-Trust? =nat On Sun, Nov 9, 2008 at 5:06 AM, Nat Sakimura <sakimura@...> 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@...> 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@...> 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@..., Cordance/Parity/OASIS (U.S.A) Henrik Biering, hb@..., Netamia (Denmark) Hideki Nara, hdknr@..., Tact Communications (Japan) John Bradeley, jbradley@..., OASIS IDTrust Member Section (Canada) Mike Graves, mgraves@..., JanRain, Inc. (U.S.A.) Nat Sakimura, n-sakimura@..., Nomura Research Institute, Ltd.(Japan) Robert Ott, robert.ott@..., Clavid (Switzerland) Tatsuki Sakushima, tatsuki@..., NRI America, Ltd. (U.S.A.) Toru Yamaguchi, trymch@..., Cyboze Lab (Japan) Editors: Nat Sakimura, n-sakimura@..., 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@... http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@... 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@... http://openid.net/mailman/listinfo/specs
	Re: Proposal to create the TX working group by David Recordon-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message After reading the extension a few times, I'm getting caught up in 4.1.6 (http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/checkout/spec/openid-trust-exchange-1_0.html?root=openidtx#anchor7) which references amounts being paid, currency, contracts, terms of the contract, etc. Overall, I'm pretty confused about what this extension does (it seems to do a lot of different things) which is making it hard for me to determine a better name. I also still feel that the reuse of AX (for it's extensibility) combined with the ability to exchange signed SAML tokens is a more future proof method and something that will be easier to be widely adopted as OpenID continues to evolve. --David On Nov 8, 2008, at 11:14 PM, Drummond Reed wrote: +1. “OpenID Trust Extension” seems like a good fit. =Drummond From: specs-bounces@... [specs-bounces@...] On Behalf Of Nat Sakimura Sent: Saturday, November 08, 2008 12:22 PM To: david@... Cc: specs@... Subject: Re: Proposal to create the TX working group Maybe just OpenID Trust Extension just like WS-Trust? =nat On Sun, Nov 9, 2008 at 5:06 AM, Nat Sakimura <sakimura@...> 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@...> 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@...> 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 enablesarbitrary 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@..., Cordance/Parity/OASIS (U.S.A) Henrik Biering, hb@..., Netamia (Denmark) Hideki Nara, hdknr@..., Tact Communications (Japan) John Bradeley, jbradley@..., OASIS IDTrust Member Section (Canada) Mike Graves, mgraves@..., JanRain, Inc. (U.S.A.) Nat Sakimura, n-sakimura@..., Nomura Research Institute, Ltd.(Japan) Robert Ott, robert.ott@..., Clavid (Switzerland) Tatsuki Sakushima, tatsuki@..., NRI America, Ltd. (U.S.A.) Toru Yamaguchi, trymch@..., Cyboze Lab (Japan) Editors: Nat Sakimura, n-sakimura@..., 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@... http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@... 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@... http://openid.net/mailman/listinfo/specs
	Re: Proposal to create the TX working group by Nat Sakimura :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Whether to include these amt.* in it as a generic item or not is what is needed to be discussed in the WG, I think. I have thrown those in as in most "contracts" these are needed. (Note: unit does not have to be a monetary one.) As a summary value, in the actual transactions, they happen to be pretty useful. As to AX+SAML (or for that matter XAdES) is concerned, that is a valid approach, but if I were to use SAML, I would use XRDS based trusted discovery + ID-WSF (preferably RESTful version) rather than OpenID because it implies that you have SAML processor including XMLEncryption and XMLSig (which seems to hinder the adoption right now in many scripting language.) TX as it stands now is trying to avoid this issue by being purely tag-value based. Also, it is trying to be mobile friendly, which is kind of hard with AX partly because of its extensibility feature. Having said that, I think it is important to be able to translate TX message to SAML ro WS-Trust based messages for the harmonization reason. Whether it has a future or not is not something a spec writer should determine, but it is something that the market should determine, IMHO. Is there an example of AX+SAML deployed and making transaction of monetary value right now or in the near future? An earlier version of TX is doing millions of dollars right now and is set to expand in the coming years (hopefully quite drastically.) You can start guessing by looking at the member list of OpenID Japan (note: not all of them are in the list. Some of them are still in process, and some of them would not like to be identified.) and why some "peculiar" variables are defined in the proposed TX spec. =nat On Sun, Nov 9, 2008 at 4:29 PM, David Recordon <drecordon@...> wrote: After reading the extension a few times, I'm getting caught up in 4.1.6 (http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/checkout/spec/openid-trust-exchange-1_0.html?root=openidtx#anchor7) which references amounts being paid, currency, contracts, terms of the contract, etc. Overall, I'm pretty confused about what this extension does (it seems to do a lot of different things) which is making it hard for me to determine a better name. I also still feel that the reuse of AX (for it's extensibility) combined with the ability to exchange signed SAML tokens is a more future proof method and something that will be easier to be widely adopted as OpenID continues to evolve. --David On Nov 8, 2008, at 11:14 PM, Drummond Reed wrote: +1. "OpenID Trust Extension" seems like a good fit. =Drummond From: specs-bounces@... [specs-bounces@...] On Behalf Of Nat Sakimura Sent: Saturday, November 08, 2008 12:22 PM To: david@... Cc: specs@... Subject: Re: Proposal to create the TX working group Maybe just OpenID Trust Extension just like WS-Trust? =nat On Sun, Nov 9, 2008 at 5:06 AM, Nat Sakimura <sakimura@...> 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@...> 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@...> 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 enablesarbitrary 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@..., Cordance/Parity/OASIS (U.S.A) Henrik Biering, hb@..., Netamia (Denmark) Hideki Nara, hdknr@..., Tact Communications (Japan) John Bradeley, jbradley@..., OASIS IDTrust Member Section (Canada) Mike Graves, mgraves@..., JanRain, Inc. (U.S.A.) Nat Sakimura, n-sakimura@..., Nomura Research Institute, Ltd.(Japan) Robert Ott, robert.ott@..., Clavid (Switzerland) Tatsuki Sakushima, tatsuki@..., NRI America, Ltd. (U.S.A.) Toru Yamaguchi, trymch@..., Cyboze Lab (Japan) Editors: Nat Sakimura, n-sakimura@..., 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@... http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@... 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/ -- Nat Sakimura (=nat) http://www.sakimura.org/en/ _______________________________________________ specs mailing list specs@... http://openid.net/mailman/listinfo/specs
	Re: Proposal to create the TX working group by Martin Paljak-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message On 09.11.2008, at 20:51, Nat Sakimura wrote: > As to AX+SAML (or for that matter XAdES) is concerned, that is a > valid approach, but if I were to use SAML, I would use Just to clarify a technical detail: The XAdES example regarding Estonia you mentioned earlier does not include transporting XAdES payloads over OpenID AX (which seems to be the purpose of the discussed workgroup where the similarities of SAML over AX come in). The special behavior and out of band assurances given by openid.ee does not include anything new on the protocol level, just added semantics to basic OpenID transactions. If we could use PDF signatures as legally valid signatures in Estonia, it could be PDF based signatures instead of XAdES, or ODF signatures, or MS .doc signatures. FYI, openid.ee allows a RP to upload a contract (template) which must be agreed with and digitally signed (legally binding signature resulting in an XAdES document with the filled in contract signed by the user with an ID-card and stored on the OP) before the OP starts issuing positive assertions about the given user to the given RP. The contract could be a document of any kind (PDF, JPG, DOC, TXT) and the only thing that is transferred to the RP over AX is a 'secret url' from where the RP can download the signed contract (XAdES container with the possibly PDF contract in it). The actual assurance (that the user has signed the contract the RP has uploaded) comes from out of band agreements/contracts between OP and RP. The AX attribute is just an extra option, if the RP wishes to automatically fetch and store the signed contract somewhere. Basically it is an advanced and legally binding 'I agree with terms and conditions' checkbox built on top of standard OpenID. With legally binding I mean that it is dead simple in the court: "Here are the terms and conditions you digitally signed and which you have violated" as checking checkboxes and pressing 'continue' is not a legally binding action in Estonia, at least I don't know of any court cases about it. If you need an example use case, think of signing and faxing NDA-s before you can download some simple "secret" product documentation. -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 _______________________________________________ specs mailing list specs@... http://openid.net/mailman/listinfo/specs
	Re: Proposal to create the TX working group by David Recordon-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Just wanted to add that Nat is running a session on TX at IIW this afternoon. We should definitly chat about the needs being expressed in this thread and how they might be able to be solved with OpenID. --David On Nov 11, 2008, at 1:13 PM, Martin Paljak wrote: > On 09.11.2008, at 20:51, Nat Sakimura wrote: >> As to AX+SAML (or for that matter XAdES) is concerned, that is a >> valid approach, but if I were to use SAML, I would use > > Just to clarify a technical detail: The XAdES example regarding > Estonia you mentioned earlier does not include transporting XAdES > payloads over OpenID AX (which seems to be the purpose of the > discussed workgroup where the similarities of SAML over AX come in). > The special behavior and out of band assurances given by openid.ee > does not include anything new on the protocol level, just added > semantics to basic OpenID transactions. If we could use PDF > signatures as legally valid signatures in Estonia, it could be PDF > based signatures instead of XAdES, or ODF signatures, or MS .doc > signatures. > > FYI, openid.ee allows a RP to upload a contract (template) which > must be agreed with and digitally signed (legally binding signature > resulting in an XAdES document with the filled in contract signed by > the user with an ID-card and stored on the OP) before the OP starts > issuing positive assertions about the given user to the given RP. > The contract could be a document of any kind (PDF, JPG, DOC, TXT) > and the only thing that is transferred to the RP over AX is a > 'secret url' from where the RP can download the signed contract > (XAdES container with the possibly PDF contract in it). > > The actual assurance (that the user has signed the contract the RP > has uploaded) comes from out of band agreements/contracts between OP > and RP. The AX attribute is just an extra option, if the RP wishes > to automatically fetch and store the signed contract somewhere. > > Basically it is an advanced and legally binding 'I agree with terms > and conditions' checkbox built on top of standard OpenID. > With legally binding I mean that it is dead simple in the court: > "Here are the terms and conditions you digitally signed and which > you have violated" as checking checkboxes and pressing 'continue' is > not a legally binding action in Estonia, at least I don't know of > any court cases about it. > > If you need an example use case, think of signing and faxing NDA-s > before you can download some simple "secret" product documentation. > > > -- > Martin Paljak > http://martin.paljak.pri.ee > +372.515.6495 > _______________________________________________ specs mailing list specs@... http://openid.net/mailman/listinfo/specs
	Re: Proposal to create the TX working group by Nat Sakimura :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Some parts of this message have been removed. Learn more about Nabble's security policy. Hi. Here is the modified version of the charter based on the discussion at IIW. I chose Contract Exchange instead of Contract Negotiation since detailed negotiation is out of scope. Cheers, =nat Contract Exchange WG Charter (formally TX). 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: Contract Exchange WG (formally Trust Exchange Extension (TX)) (ii) Purpose: The purpose of this WG is to produce a series of standard OpenID extension to the OpenID Authentication protocol that enables arbitrary parties to create and exchange a mutually-digitally-signed legally binding "contract" that are both broadband and mobile friendly by defining appropriate bindings for each use case. For this purpose, (1) public key exchange, (2) signed request and response based on the public keys, (3) content encryption based on public key, (4) extensible data transfer method, (5) contract format, (6) notification methods for asynchronous communications are needed to be defined. For this purpose, this WG will explorer the possibility of using/extending OpenID Attribute Exchange [AX] as well as defining new extensions where it may fit. (iii) Scope: Scope of the work Development of the specifications including: Public Key Exchange method A Public Key Cryptography based digital signature method. Legally binding contract format. Query/response communication protocols for establishing and canceling of the contract. Message Encryption method to be used for the relevant communications. Notification interface for asynchronous communications. Possible extension and profiling of [AX] to accommodate the above. Provisions for long term storage of the contracts. 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. 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: Sries of specs encompassing the above requirements. The actual spec may happened to be just an expansion of AX or several news specs as it will be determined in the WG. Expected completion of the first iteration is in Q1 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: Drafts 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 drafts has been achieved, consistent with the purpose and scope. (b) Background Information. (i) Related work being done by other WGs or organizations: OpenID Attribute Exchange Extension 1.0 [AX] LIberty Alliance Identity Governance Framework [IGF] 1.0 Draft XML Advanced Electronic Signatures [XAdES] WS-Trust 1.3 [WS-trust] XRI 2.0 [XRI] XDI 1.0 [XDI] Vendor Relationship Management [VRM] (ii) Proposers: Drummond Reed, drummond.reed@..., Cordance/Parity/OASIS (U.S.A) Henrik Biering, hb@..., Netamia (Denmark) Hideki Nara, hdknr@..., Tact Communications (Japan) John Bradeley, jbradley@..., OASIS IDTrust Member Section (Canada) Mike Graves, mgraves@..., JanRain, Inc. (U.S.A.) Nat Sakimura, n-sakimura@..., Nomura Research Institute, Ltd.(Japan) Robert Ott, robert.ott@..., Clavid (Switzerland) Tatsuki Sakushima, tatsuki@..., NRI America, Ltd. (U.S.A.) Toru Yamaguchi, trymch@..., Cybozu Lab (Japan) Editors: Nat Sakimura, n-sakimura@..., Nomura Research Institute, Ltd. (iii) Anticipated Contributions: * Sakimura, N., et. al "OpenID Trusted data eXchange Extention Specification (draft)", Oct. 2008. [TX2008]. On Wed, Nov 12, 2008 at 6:39 AM, David Recordon <drecordon@...> wrote: Just wanted to add that Nat is running a session on TX at IIW this afternoon. We should definitly chat about the needs being expressed in this thread and how they might be able to be solved with OpenID. --David On Nov 11, 2008, at 1:13 PM, Martin Paljak wrote: On 09.11.2008, at 20:51, Nat Sakimura wrote: As to AX+SAML (or for that matter XAdES) is concerned, that is a valid approach, but if I were to use SAML, I would use Just to clarify a technical detail: The XAdES example regarding Estonia you mentioned earlier does not include transporting XAdES payloads over OpenID AX (which seems to be the purpose of the discussed workgroup where the similarities of SAML over AX come in). The special behavior and out of band assurances given by openid.ee does not include anything new on the protocol level, just added semantics to basic OpenID transactions. If we could use PDF signatures as legally valid signatures in Estonia, it could be PDF based signatures instead of XAdES, or ODF signatures, or MS .doc signatures. FYI, openid.ee allows a RP to upload a contract (template) which must be agreed with and digitally signed (legally binding signature resulting in an XAdES document with the filled in contract signed by the user with an ID-card and stored on the OP) before the OP starts issuing positive assertions about the given user to the given RP. The contract could be a document of any kind (PDF, JPG, DOC, TXT) and the only thing that is transferred to the RP over AX is a 'secret url' from where the RP can download the signed contract (XAdES container with the possibly PDF contract in it). The actual assurance (that the user has signed the contract the RP has uploaded) comes from out of band agreements/contracts between OP and RP. The AX attribute is just an extra option, if the RP wishes to automatically fetch and store the signed contract somewhere. Basically it is an advanced and legally binding 'I agree with terms and conditions' checkbox built on top of standard OpenID. With legally binding I mean that it is dead simple in the court: "Here are the terms and conditions you digitally signed and which you have violated" as checking checkboxes and pressing 'continue' is not a legally binding action in Estonia, at least I don't know of any court cases about it. If you need an example use case, think of signing and faxing NDA-s before you can download some simple "secret" product documentation. -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 -- Nat Sakimura (=nat) http://www.sakimura.org/en/ _______________________________________________ specs mailing list specs@... http://openid.net/mailman/listinfo/specs
	Re: Proposal to create the TX working group by Nat Sakimura :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message I was pointed out by Dick that "Key Exchnage" really should be "Key Discovery". I agree. So, I would do s/Key Exchange/Key Discovery/g. Cheers, =nat On Thu, Nov 13, 2008 at 4:02 PM, Nat Sakimura <sakimura@...> wrote: Hi. Here is the modified version of the charter based on the discussion at IIW. I chose Contract Exchange instead of Contract Negotiation since detailed negotiation is out of scope. Cheers, =nat Contract Exchange WG Charter (formally TX). 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: Contract Exchange WG (formally Trust Exchange Extension (TX)) (ii) Purpose: The purpose of this WG is to produce a series of standard OpenID extension to the OpenID Authentication protocol that enables arbitrary parties to create and exchange a mutually-digitally-signed legally binding "contract" that are both broadband and mobile friendly by defining appropriate bindings for each use case. For this purpose, (1) public key exchange, (2) signed request and response based on the public keys, (3) content encryption based on public key, (4) extensible data transfer method, (5) contract format, (6) notification methods for asynchronous communications are needed to be defined. For this purpose, this WG will explorer the possibility of using/extending OpenID Attribute Exchange [AX] as well as defining new extensions where it may fit. (iii) Scope: Scope of the work Development of the specifications including: Public Key Exchange method A Public Key Cryptography based digital signature method. Legally binding contract format. Query/response communication protocols for establishing and canceling of the contract. Message Encryption method to be used for the relevant communications. Notification interface for asynchronous communications. Possible extension and profiling of [AX] to accommodate the above. Provisions for long term storage of the contracts. 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. 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: Sries of specs encompassing the above requirements. The actual spec may happened to be just an expansion of AX or several news specs as it will be determined in the WG. Expected completion of the first iteration is in Q1 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: Drafts 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 drafts has been achieved, consistent with the purpose and scope. (b) Background Information. (i) Related work being done by other WGs or organizations: OpenID Attribute Exchange Extension 1.0 [AX] LIberty Alliance Identity Governance Framework [IGF] 1.0 Draft XML Advanced Electronic Signatures [XAdES] WS-Trust 1.3 [WS-trust] XRI 2.0 [XRI] XDI 1.0 [XDI] Vendor Relationship Management [VRM] (ii) Proposers: Drummond Reed, drummond.reed@..., Cordance/Parity/OASIS (U.S.A) Henrik Biering, hb@..., Netamia (Denmark) Hideki Nara, hdknr@..., Tact Communications (Japan) John Bradeley, jbradley@..., OASIS IDTrust Member Section (Canada) Mike Graves, mgraves@..., JanRain, Inc. (U.S.A.) Nat Sakimura, n-sakimura@..., Nomura Research Institute, Ltd.(Japan) Robert Ott, robert.ott@..., Clavid (Switzerland) Tatsuki Sakushima, tatsuki@..., NRI America, Ltd. (U.S.A.) Toru Yamaguchi, trymch@..., Cybozu Lab (Japan) Editors: Nat Sakimura, n-sakimura@..., Nomura Research Institute, Ltd. (iii) Anticipated Contributions: * Sakimura, N., et. al "OpenID Trusted data eXchange Extention Specification (draft)", Oct. 2008. [TX2008]. On Wed, Nov 12, 2008 at 6:39 AM, David Recordon <drecordon@...> wrote: Just wanted to add that Nat is running a session on TX at IIW this afternoon. We should definitly chat about the needs being expressed in this thread and how they might be able to be solved with OpenID. --David On Nov 11, 2008, at 1:13 PM, Martin Paljak wrote: On 09.11.2008, at 20:51, Nat Sakimura wrote: As to AX+SAML (or for that matter XAdES) is concerned, that is a valid approach, but if I were to use SAML, I would use Just to clarify a technical detail: The XAdES example regarding Estonia you mentioned earlier does not include transporting XAdES payloads over OpenID AX (which seems to be the purpose of the discussed workgroup where the similarities of SAML over AX come in). The special behavior and out of band assurances given by openid.ee does not include anything new on the protocol level, just added semantics to basic OpenID transactions. If we could use PDF signatures as legally valid signatures in Estonia, it could be PDF based signatures instead of XAdES, or ODF signatures, or MS .doc signatures. FYI, openid.ee allows a RP to upload a contract (template) which must be agreed with and digitally signed (legally binding signature resulting in an XAdES document with the filled in contract signed by the user with an ID-card and stored on the OP) before the OP starts issuing positive assertions about the given user to the given RP. The contract could be a document of any kind (PDF, JPG, DOC, TXT) and the only thing that is transferred to the RP over AX is a 'secret url' from where the RP can download the signed contract (XAdES container with the possibly PDF contract in it). The actual assurance (that the user has signed the contract the RP has uploaded) comes from out of band agreements/contracts between OP and RP. The AX attribute is just an extra option, if the RP wishes to automatically fetch and store the signed contract somewhere. Basically it is an advanced and legally binding 'I agree with terms and conditions' checkbox built on top of standard OpenID. With legally binding I mean that it is dead simple in the court: "Here are the terms and conditions you digitally signed and which you have violated" as checking checkboxes and pressing 'continue' is not a legally binding action in Estonia, at least I don't know of any court cases about it. If you need an example use case, think of signing and faxing NDA-s before you can download some simple "secret" product documentation. -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 -- Nat Sakimura (=nat) http://www.sakimura.org/en/ -- Nat Sakimura (=nat) http://www.sakimura.org/en/ _______________________________________________ specs mailing list specs@... http://openid.net/mailman/listinfo/specs
	Re: Proposal to create the TX working group by David Recordon-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Hi Nat, Mike Jones just pointed out that the Steward Council hadn't yet caught this email which I apologize for. I have two concerns with this charter: 1) It appears the WG is going to deliver 9 specifications with a list that isn't clear about what each specification will do and how they relate. Past approved WG proposals (as well as the current drafts) have had a very clear set of deliverables. 2) While discussed heavily at IIW, this proposal still does not clearly seem build on top of the AX specification. The current OpenID specifications very clearly fit together and build atop each other and this one should be no different. I'm working on figuring out how to have the Stewards Council recommendation created on a public mailing list, but felt it worthwhile to share my opinions here until that happens. --David On Nov 13, 2008, at 8:40 AM, Nat Sakimura wrote: I was pointed out by Dick that "Key Exchnage" really should be "Key Discovery". I agree. So, I would do s/Key Exchange/Key Discovery/g. Cheers, =nat On Thu, Nov 13, 2008 at 4:02 PM, Nat Sakimura <sakimura@...> wrote: Hi. Here is the modified version of the charter based on the discussion at IIW. I chose Contract Exchange instead of Contract Negotiation since detailed negotiation is out of scope. Cheers, =nat Contract Exchange WG Charter (formally TX). 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: Contract Exchange WG (formally Trust Exchange Extension (TX)) (ii) Purpose: The purpose of this WG is to produce a series of standard OpenID extension to the OpenID Authentication protocol that enables arbitrary parties to create and exchange a mutually-digitally-signed legally binding "contract" that are both broadband and mobile friendly by defining appropriate bindings for each use case. For this purpose, (1) public key exchange, (2) signed request and response based on the public keys, (3) content encryption based on public key, (4) extensible data transfer method, (5) contract format, (6) notification methods for asynchronous communications are needed to be defined. For this purpose, this WG will explorer the possibility of using/extending OpenID Attribute Exchange [AX] as well as defining new extensions where it may fit. (iii) Scope: Scope of the work Development of the specifications including: Public Key Exchange method A Public Key Cryptography based digital signature method. Legally binding contract format. Query/response communication protocols for establishing and canceling of the contract. Message Encryption method to be used for the relevant communications. Notification interface for asynchronous communications. Possible extension and profiling of [AX] to accommodate the above. Provisions for long term storage of the contracts. 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. 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: Sries of specs encompassing the above requirements. The actual spec may happened to be just an expansion of AX or several news specs as it will be determined in the WG. Expected completion of the first iteration is in Q1 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: Drafts 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 drafts has been achieved, consistent with the purpose and scope. (b) Background Information. (i) Related work being done by other WGs or organizations: OpenID Attribute Exchange Extension 1.0 [AX] LIberty Alliance Identity Governance Framework [IGF] 1.0 Draft XML Advanced Electronic Signatures [XAdES] WS-Trust 1.3 [WS-trust] XRI 2.0 [XRI] XDI 1.0 [XDI] Vendor Relationship Management [VRM] (ii) Proposers: Drummond Reed, drummond.reed@..., Cordance/Parity/OASIS (U.S.A) Henrik Biering, hb@..., Netamia (Denmark) Hideki Nara, hdknr@..., Tact Communications (Japan) John Bradeley, jbradley@..., OASIS IDTrust Member Section (Canada) Mike Graves, mgraves@..., JanRain, Inc. (U.S.A.) Nat Sakimura, n-sakimura@..., Nomura Research Institute, Ltd.(Japan) Robert Ott, robert.ott@..., Clavid (Switzerland) Tatsuki Sakushima, tatsuki@..., NRI America, Ltd. (U.S.A.) Toru Yamaguchi, trymch@..., Cybozu Lab (Japan) Editors: Nat Sakimura, n-sakimura@..., Nomura Research Institute, Ltd. (iii) Anticipated Contributions: * Sakimura, N., et. al "OpenID Trusted data eXchange Extention Specification (draft)", Oct. 2008. [TX2008]. On Wed, Nov 12, 2008 at 6:39 AM, David Recordon <drecordon@...> wrote: Just wanted to add that Nat is running a session on TX at IIW this afternoon. We should definitly chat about the needs being expressed in this thread and how they might be able to be solved with OpenID. --David On Nov 11, 2008, at 1:13 PM, Martin Paljak wrote: On 09.11.2008, at 20:51, Nat Sakimura wrote: As to AX+SAML (or for that matter XAdES) is concerned, that is a valid approach, but if I were to use SAML, I would use Just to clarify a technical detail: The XAdES example regarding Estonia you mentioned earlier does not include transporting XAdES payloads over OpenID AX (which seems to be the purpose of the discussed workgroup where the similarities of SAML over AX come in). The special behavior and out of band assurances given by openid.ee does not include anything new on the protocol level, just added semantics to basic OpenID transactions. If we could use PDF signatures as legally valid signatures in Estonia, it could be PDF based signatures instead of XAdES, or ODF signatures, or MS .doc signatures. FYI, openid.ee allows a RP to upload a contract (template) which must be agreed with and digitally signed (legally binding signature resulting in an XAdES document with the filled in contract signed by the user with an ID-card and stored on the OP) before the OP starts issuing positive assertions about the given user to the given RP. The contract could be a document of any kind (PDF, JPG, DOC, TXT) and the only thing that is transferred to the RP over AX is a 'secret url' from where the RP can download the signed contract (XAdES container with the possibly PDF contract in it). The actual assurance (that the user has signed the contract the RP has uploaded) comes from out of band agreements/contracts between OP and RP. The AX attribute is just an extra option, if the RP wishes to automatically fetch and store the signed contract somewhere. Basically it is an advanced and legally binding 'I agree with terms and conditions' checkbox built on top of standard OpenID. With legally binding I mean that it is dead simple in the court: "Here are the terms and conditions you digitally signed and which you have violated" as checking checkboxes and pressing 'continue' is not a legally binding action in Estonia, at least I don't know of any court cases about it. If you need an example use case, think of signing and faxing NDA-s before you can download some simple "secret" product documentation. -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 -- Nat Sakimura (=nat) http://www.sakimura.org/en/ -- Nat Sakimura (=nat) http://www.sakimura.org/en/ _______________________________________________ specs mailing list specs@... http://openid.net/mailman/listinfo/specs
	Re: Proposal to create the TX working group by Nat Sakimura :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message I have discussed with Dick at iiw to see if it is possible to build on AX. It seems it is inevitable that there needs to be some "modifications/extensions" to AX if it is to be done on AX. We at NRI and Mike of JanRain have been evaluating what is needed since I submit the last version of the charter and we are coming close to the conclusion on what is needed. In essence, we need to add another message type apart from fetch and store to AX, and we need to define the direct communication in both directions (OP->RP and RP->OP). If it is done, we are quite confident that we can build the CX on top of AX. In conjunction with it, I have been working on XRD SimpleSign that it depends on. We are still working out the details, but that probably should be the topic of the WG to follow up. I am going to post the amended charter to the Wiki. Also, I think it is a good practice to formalize the message acceptance note issuing procedure (well, the workflow in general) so that there will not be a proposal which is not being dealt with. Regards, =nat On Thu, Dec 4, 2008 at 4:52 PM, David Recordon <drecordon@...> wrote: Hi Nat, Mike Jones just pointed out that the Steward Council hadn't yet caught this email which I apologize for. I have two concerns with this charter: 1) It appears the WG is going to deliver 9 specifications with a list that isn't clear about what each specification will do and how they relate. Past approved WG proposals (as well as the current drafts) have had a very clear set of deliverables. 2) While discussed heavily at IIW, this proposal still does not clearly seem build on top of the AX specification. The current OpenID specifications very clearly fit together and build atop each other and this one should be no different. I'm working on figuring out how to have the Stewards Council recommendation created on a public mailing list, but felt it worthwhile to share my opinions here until that happens. --David On Nov 13, 2008, at 8:40 AM, Nat Sakimura wrote: I was pointed out by Dick that "Key Exchnage" really should be "Key Discovery". I agree. So, I would do s/Key Exchange/Key Discovery/g. Cheers, =nat On Thu, Nov 13, 2008 at 4:02 PM, Nat Sakimura <sakimura@...> wrote: Hi. Here is the modified version of the charter based on the discussion at IIW. I chose Contract Exchange instead of Contract Negotiation since detailed negotiation is out of scope. Cheers, =nat Contract Exchange WG Charter (formally TX). 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: Contract Exchange WG (formally Trust Exchange Extension (TX)) (ii) Purpose: The purpose of this WG is to produce a series of standard OpenID extension to the OpenID Authentication protocol that enables arbitrary parties to create and exchange a mutually-digitally-signed legally binding "contract" that are both broadband and mobile friendly by defining appropriate bindings for each use case. For this purpose, (1) public key exchange, (2) signed request and response based on the public keys, (3) content encryption based on public key, (4) extensible data transfer method, (5) contract format, (6) notification methods for asynchronous communications are needed to be defined. For this purpose, this WG will explorer the possibility of using/extending OpenID Attribute Exchange [AX] as well as defining new extensions where it may fit. (iii) Scope: Scope of the work Development of the specifications including: Public Key Exchange method A Public Key Cryptography based digital signature method. Legally binding contract format. Query/response communication protocols for establishing and canceling of the contract. Message Encryption method to be used for the relevant communications. Notification interface for asynchronous communications. Possible extension and profiling of [AX] to accommodate the above. Provisions for long term storage of the contracts. 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. 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: Sries of specs encompassing the above requirements. The actual spec may happened to be just an expansion of AX or several news specs as it will be determined in the WG. Expected completion of the first iteration is in Q1 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: Drafts 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 drafts has been achieved, consistent with the purpose and scope. (b) Background Information. (i) Related work being done by other WGs or organizations: OpenID Attribute Exchange Extension 1.0 [AX] LIberty Alliance Identity Governance Framework [IGF] 1.0 Draft XML Advanced Electronic Signatures [XAdES] WS-Trust 1.3 [WS-trust] XRI 2.0 [XRI] XDI 1.0 [XDI] Vendor Relationship Management [VRM] (ii) Proposers: Drummond Reed, drummond.reed@..., Cordance/Parity/OASIS (U.S.A) Henrik Biering, hb@..., Netamia (Denmark) Hideki Nara, hdknr@..., Tact Communications (Japan) John Bradeley, jbradley@..., OASIS IDTrust Member Section (Canada) Mike Graves, mgraves@..., JanRain, Inc. (U.S.A.) Nat Sakimura, n-sakimura@..., Nomura Research Institute, Ltd.(Japan) Robert Ott, robert.ott@..., Clavid (Switzerland) Tatsuki Sakushima, tatsuki@..., NRI America, Ltd. (U.S.A.) Toru Yamaguchi, trymch@..., Cybozu Lab (Japan) Editors: Nat Sakimura, n-sakimura@..., Nomura Research Institute, Ltd. (iii) Anticipated Contributions: * Sakimura, N., et. al "OpenID Trusted data eXchange Extention Specification (draft)", Oct. 2008. [TX2008]. On Wed, Nov 12, 2008 at 6:39 AM, David Recordon <drecordon@...> wrote: Just wanted to add that Nat is running a session on TX at IIW this afternoon. We should definitly chat about the needs being expressed in this thread and how they might be able to be solved with OpenID. --David On Nov 11, 2008, at 1:13 PM, Martin Paljak wrote: On 09.11.2008, at 20:51, Nat Sakimura wrote: As to AX+SAML (or for that matter XAdES) is concerned, that is a valid approach, but if I were to use SAML, I would use Just to clarify a technical detail: The XAdES example regarding Estonia you mentioned earlier does not include transporting XAdES payloads over OpenID AX (which seems to be the purpose of the discussed workgroup where the similarities of SAML over AX come in). The special behavior and out of band assurances given by openid.ee does not include anything new on the protocol level, just added semantics to basic OpenID transactions. If we could use PDF signatures as legally valid signatures in Estonia, it could be PDF based signatures instead of XAdES, or ODF signatures, or MS .doc signatures. FYI, openid.ee allows a RP to upload a contract (template) which must be agreed with and digitally signed (legally binding signature resulting in an XAdES document with the filled in contract signed by the user with an ID-card and stored on the OP) before the OP starts issuing positive assertions about the given user to the given RP. The contract could be a document of any kind (PDF, JPG, DOC, TXT) and the only thing that is transferred to the RP over AX is a 'secret url' from where the RP can download the signed contract (XAdES container with the possibly PDF contract in it). The actual assurance (that the user has signed the contract the RP has uploaded) comes from out of band agreements/contracts between OP and RP. The AX attribute is just an extra option, if the RP wishes to automatically fetch and store the signed contract somewhere. Basically it is an advanced and legally binding 'I agree with terms and conditions' checkbox built on top of standard OpenID. With legally binding I mean that it is dead simple in the court: "Here are the terms and conditions you digitally signed and which you have violated" as checking checkboxes and pressing 'continue' is not a legally binding action in Estonia, at least I don't know of any court cases about it. If you need an example use case, think of signing and faxing NDA-s before you can download some simple "secret" product documentation. -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 -- 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@... http://openid.net/mailman/listinfo/specs
	Re: Proposal to create the TX working group by Nat Sakimura :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message P.S., Nine things in the scope does not correspond to the deliverables. It merely indicates that these things need to be addressed. P.P.S. Having stated above, after our evaluation, it boiled down to 4 deliverables. I have created the wiki page for it. Please refer to it as the most current version of the charter proposal. http://wiki.openid.net/Working_Groups:Contract_Exchange_1.0 Hope this one is finally acceptable. On Thu, Dec 4, 2008 at 10:42 PM, Nat Sakimura <sakimura@...> wrote: I have discussed with Dick at iiw to see if it is possible to build on AX. It seems it is inevitable that there needs to be some "modifications/extensions" to AX if it is to be done on AX. We at NRI and Mike of JanRain have been evaluating what is needed since I submit the last version of the charter and we are coming close to the conclusion on what is needed. In essence, we need to add another message type apart from fetch and store to AX, and we need to define the direct communication in both directions (OP->RP and RP->OP). If it is done, we are quite confident that we can build the CX on top of AX. In conjunction with it, I have been working on XRD SimpleSign that it depends on. We are still working out the details, but that probably should be the topic of the WG to follow up. I am going to post the amended charter to the Wiki. Also, I think it is a good practice to formalize the message acceptance note issuing procedure (well, the workflow in general) so that there will not be a proposal which is not being dealt with. Regards, =nat On Thu, Dec 4, 2008 at 4:52 PM, David Recordon <drecordon@...> wrote: Hi Nat, Mike Jones just pointed out that the Steward Council hadn't yet caught this email which I apologize for. I have two concerns with this charter: 1) It appears the WG is going to deliver 9 specifications with a list that isn't clear about what each specification will do and how they relate. Past approved WG proposals (as well as the current drafts) have had a very clear set of deliverables. 2) While discussed heavily at IIW, this proposal still does not clearly seem build on top of the AX specification. The current OpenID specifications very clearly fit together and build atop each other and this one should be no different. I'm working on figuring out how to have the Stewards Council recommendation created on a public mailing list, but felt it worthwhile to share my opinions here until that happens. --David On Nov 13, 2008, at 8:40 AM, Nat Sakimura wrote: I was pointed out by Dick that "Key Exchnage" really should be "Key Discovery". I agree. So, I would do s/Key Exchange/Key Discovery/g. Cheers, =nat On Thu, Nov 13, 2008 at 4:02 PM, Nat Sakimura <sakimura@...> wrote: Hi. Here is the modified version of the charter based on the discussion at IIW. I chose Contract Exchange instead of Contract Negotiation since detailed negotiation is out of scope. Cheers, =nat Contract Exchange WG Charter (formally TX). 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: Contract Exchange WG (formally Trust Exchange Extension (TX)) (ii) Purpose: The purpose of this WG is to produce a series of standard OpenID extension to the OpenID Authentication protocol that enables arbitrary parties to create and exchange a mutually-digitally-signed legally binding "contract" that are both broadband and mobile friendly by defining appropriate bindings for each use case. For this purpose, (1) public key exchange, (2) signed request and response based on the public keys, (3) content encryption based on public key, (4) extensible data transfer method, (5) contract format, (6) notification methods for asynchronous communications are needed to be defined. For this purpose, this WG will explorer the possibility of using/extending OpenID Attribute Exchange [AX] as well as defining new extensions where it may fit. (iii) Scope: Scope of the work Development of the specifications including: Public Key Exchange method A Public Key Cryptography based digital signature method. Legally binding contract format. Query/response communication protocols for establishing and canceling of the contract. Message Encryption method to be used for the relevant communications. Notification interface for asynchronous communications. Possible extension and profiling of [AX] to accommodate the above. Provisions for long term storage of the contracts. 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. 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: Sries of specs encompassing the above requirements. The actual spec may happened to be just an expansion of AX or several news specs as it will be determined in the WG. Expected completion of the first iteration is in Q1 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: Drafts 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 drafts has been achieved, consistent with the purpose and scope. (b) Background Information. (i) Related work being done by other WGs or organizations: OpenID Attribute Exchange Extension 1.0 [AX] LIberty Alliance Identity Governance Framework [IGF] 1.0 Draft XML Advanced Electronic Signatures [XAdES] WS-Trust 1.3 [WS-trust] XRI 2.0 [XRI] XDI 1.0 [XDI] Vendor Relationship Management [VRM] (ii) Proposers: Drummond Reed, drummond.reed@..., Cordance/Parity/OASIS (U.S.A) Henrik Biering, hb@..., Netamia (Denmark) Hideki Nara, hdknr@..., Tact Communications (Japan) John Bradeley, jbradley@..., OASIS IDTrust Member Section (Canada) Mike Graves, mgraves@..., JanRain, Inc. (U.S.A.) Nat Sakimura, n-sakimura@..., Nomura Research Institute, Ltd.(Japan) Robert Ott, robert.ott@..., Clavid (Switzerland) Tatsuki Sakushima, tatsuki@..., NRI America, Ltd. (U.S.A.) Toru Yamaguchi, trymch@..., Cybozu Lab (Japan) Editors: Nat Sakimura, n-sakimura@..., Nomura Research Institute, Ltd. (iii) Anticipated Contributions: * Sakimura, N., et. al "OpenID Trusted data eXchange Extention Specification (draft)", Oct. 2008. [TX2008]. On Wed, Nov 12, 2008 at 6:39 AM, David Recordon <drecordon@...> wrote: Just wanted to add that Nat is running a session on TX at IIW this afternoon. We should definitly chat about the needs being expressed in this thread and how they might be able to be solved with OpenID. --David On Nov 11, 2008, at 1:13 PM, Martin Paljak wrote: On 09.11.2008, at 20:51, Nat Sakimura wrote: As to AX+SAML (or for that matter XAdES) is concerned, that is a valid approach, but if I were to use SAML, I would use Just to clarify a technical detail: The XAdES example regarding Estonia you mentioned earlier does not include transporting XAdES payloads over OpenID AX (which seems to be the purpose of the discussed workgroup where the similarities of SAML over AX come in). The special behavior and out of band assurances given by openid.ee does not include anything new on the protocol level, just added semantics to basic OpenID transactions. If we could use PDF signatures as legally valid signatures in Estonia, it could be PDF based signatures instead of XAdES, or ODF signatures, or MS .doc signatures. FYI, openid.ee allows a RP to upload a contract (template) which must be agreed with and digitally signed (legally binding signature resulting in an XAdES document with the filled in contract signed by the user with an ID-card and stored on the OP) before the OP starts issuing positive assertions about the given user to the given RP. The contract could be a document of any kind (PDF, JPG, DOC, TXT) and the only thing that is transferred to the RP over AX is a 'secret url' from where the RP can download the signed contract (XAdES container with the possibly PDF contract in it). The actual assurance (that the user has signed the contract the RP has uploaded) comes from out of band agreements/contracts between OP and RP. The AX attribute is just an extra option, if the RP wishes to automatically fetch and store the signed contract somewhere. Basically it is an advanced and legally binding 'I agree with terms and conditions' checkbox built on top of standard OpenID. With legally binding I mean that it is dead simple in the court: "Here are the terms and conditions you digitally signed and which you have violated" as checking checkboxes and pressing 'continue' is not a legally binding action in Estonia, at least I don't know of any court cases about it. If you need an example use case, think of signing and faxing NDA-s before you can download some simple "secret" product documentation. -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 -- Nat Sakimura (=nat) http://www.sakimura.org/en/ -- 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@... http://openid.net/mailman/listinfo/specs