- Community - mailman.kantarainitiative.org

Re: [Kantara - Community] Institutional Web of Trust
by Michael Duffy 31 Jan '10

31 Jan '10

I think repositories only hold value if the storage and retrieval of information can be validated to be trusted, secure, reliable, and honest in its representations. We agree with Brian's statement. Within the *Institutional Web of Trust Repository* institutions will be authenticated by established certificate authorities. The major certificate authorities have high level processes for institutional authentication and security; these processes have established a record of reliability over many years. Institutions will have a vested interest in maintaining the validity of their certificates within the *Institutional Web of Trust Repository*. Since trust is an intangible value, I find it to be an unobtainable goal in ecommerce activities based on concepts that are not managed in accordance with good policies or even their own statements. IMHO any system that is self-managed is quite frankly a disaster and provides me as an informed consumer no level of trust or assurances proclaimed by any system or solution said to be good for goodness sakes. Self managed is equivalent to saying trust me because I say so. It is certainly our goal to have good policies. Assuming that processes of self-management can not be incorporated into good policies is a fallacious line of reasoning (http://www.opifexphoenix.com/reasoning/fallacies/slipperyslope.htm) Simply because a system involves self-management does not mean the system will inevitably end in disaster. From the user standpoint, the self-management aspect of our system is very slight. When a user activates his/her NFC enabled smart phone there will be a registration process where the user's legal identity and public key will be registered with the *Institutional Web of Trust Repository*. This process will be transparent to the user. There really is no way for certificate authorities or governments to manage the issuance and assurance of billions of private/public keys. A process in which users can self-register their own keys enables a workable world wide system. However, after reading Brian's response I can see that the term "self-management" is tinged with unreliability. We will remove this term from our presentation and replace it with "self-registered". I also don't understand why it is referred to as a "centralized" repository and then it is explained to be a "group" of repositories. Maybe it is just me, but isn't that a "distributed" model? Good point. That is clearly a mistake in our presentation. It is very likely each nation or groups of nations (EEC) will have its own central repository (replicated geographically). World wide, it will be a distributed model. Also, how do you ensure the individual is always in control of their key? I think that statement is simply not true, grandiose, and terrible misleading -- and not a basis of building any trust; as no system could ever ensure that the action of all its individuals was consistent and the same. Currently, there is a great deal of controversy regarding the security of data on mobile devices. Once the Trusted Platform Module (http://en.wikipedia.org/wiki/Trusted_Platform_Module) is instituted on mobile devices this controversy should abate. Of course, a user's cell phone which contains their digital wallet may be lost or stolen just as physical wallet can be lost or stolen. The *Institutional Web of Trust Repository *will have processes for canceling and reestablishing credentials. I think the International [Institutional] Web of Trust is a trap of old concepts, proclaiming protections that are perceived based on biased assessments, and one of the most frightening concepts for ensuring trust and identities that I have listened to in quite awhile. These statements are frighteningly hyperbolic and uniformed. If I go to my local bank and in the process of provisioning my digital debit card onto my cell phone ~ the banking system calculates a hash value of the credential ~ then that hash value is encrypted with my private key ~ then encrypted again with the banks private key ~ then the dual encrypted value is stored *Institutional Web of Trust Repository *that value represents an institutional validation of the my identity (without storing any private information about the user). The weight of multiple institutional validations makes the user's identity more trustworthy. When a user presents a credential from his/her digital wallet a transaction ID will be sent from the authenticating system to the user's digital wallet, be encrypted with the user's private key and sent back to the authenticating system. The user can be authenticated by decrypting the transaction ID with the user's public key from the *Institutional Web of Trust Repository*. The credential can be authenticated by calculating the hash value of the credential and then decrypting the hash value stored in the *Institutional Web of Trust Repository* with the institution's public key and the user's public key. *All in all, this is really a very simple system based on existing technologies.* The key nuance is that we store institutional validations, we do not store private data. Best regards, Michael Duffy CEO / CTO ~ The Trust Nexus http://www.thetrustnexus.com Brian Dilley wrote: > > Actually, I find that a "web" is a tangled mesh in which to entrap and > is a term that infringes on other trademarks and is a symbol that > doesn't inspire trust at all -- said the fly to the spider. I think > repositories only hold value if the storage and retrieval of > information can be validated to be trusted, secure, reliable, and > honest in its representations. Since trust is an intangible value, I > find it to be an unobtainable goal in ecommerce activities based on > concepts that are not managed in accordance with good policies or even > their own statements. IMHO any system that is self-managed is quite > frankly a disaster and provides me as an informed consumer no level of > trust or assurances proclaimed by any system or solution said to be > good for goodness sakes. Self managed is equivalent to saying trust > me because I say so. > > > > Also, the wallet idea has come and gone and a second showing will most > likely result in the same...I also don't understand why it is referred > to as a "centralized" repository and then it is explained to be a > "group" of repositories. Maybe it is just me, but isn't that a > "distributed" model? Also, how do you ensure the individual is always > in control of their key? I think that statement is simply not true, > grandiose, and terrible misleading -- and not a basis of building any > trust; as no system could ever ensure that the action of all its > individuals was consistent and the same. Therefore, the International > Web of Trust is seriously flawed by allowing such an assumption to be > the core value of its model. > > > > I really think this whole message has been completely self-promoting > and quite a story about X.509 certificates but vaguely disguised as a > wallet, and I think the International Web of Trust is a trap of old > concepts, proclaiming protections that are perceived based on biased > assessments, and one of the most frightening concepts for ensuring > trust and identities that I have listened to in quite awhile. > > > > This is exactly why such organizations as IETF, ANSI, ISO, AICPA, NIST > and Kantara are so much in need to prevent such flawed solutions as > this "web of trust" from being accepted by the electronic commerce > community. > > > > /_(My corporate cell phone number has been changed, if you could > please update your records that would be great.)_/ > > > > Sincerely, > > Brian > > Brian Dilley CISA / CIPP / CGEIT > > President > > */ /* > > */GSA Advantage! - Use our GSA Schedule 70 Today! > <http://www.evalid8.com/services/gsaschedule70.html>/*__ > > > > Office: (866) 465 - 6005 > > Fax: (443) 957 - 9005 > > Cell: *(443) 955 - 9885* > > Web: http://www.evalid8.com <http://www.evalid8.com/> > > > > This electronic message contains information from eValid8^® that may > be confidential, proprietary or otherwise protected from disclosure > and is only intended for the recipient. If you should have received > this transmission in error, we do make mistakes when selecting > addressees, please notify the email originator at info(a)evalid8.com > <mailto:info@evalid8.com> and please delete that email message from > your mailbox. eValid8^® wants to be safe on the Internet, and we > honor clients and people's privacy. To read our Privacy Statement, > click on this link, > http://www.evalid8.com/contactus/privacystatement.html . > > ------------------------------------------------------------------------ > > *From:* community-bounces(a)kantarainitiative.org > [mailto:community-bounces@kantarainitiative.org] *On Behalf Of > *Michael Duffy > *Sent:* Saturday, January 30, 2010 12:49 PM > *To:* Joni Brennan > *Cc:* community(a)kantarainitiative.org > *Subject:* Re: [Kantara - Community] Institutional Web of Trust > > > > As requested, we have voided all company references and provided a > brief summary. Again, we apologize for the inappropriate post. > > Here is an overview of the *Institutional Web of Trust* concept: > > ************************************************************** > Executive Summary:* For the purpose of securing identity, rather than > creating a centralized directory or multiple directories of private > information, it will be far better to create a central repository > containing a collection of institutional decisions which will > establish an *Institutional Web of Trust*. In essence, there are a > *limited number of institutions worldwide* (measured in thousands) > that truly matter when it comes to legitimizing identity. Digital > wallets on smart phones will enable the efficient association of > unique public/private keys to a specific legal identity (legal name > and legal address). If there is a non-unique association, an > inconsistency arises in the system. If the association is unique and > verified by one or more legitimate institutions an individual's > identity is secure (as long as the private key which he/she controls > is secure). > > This system secures identity, protects individual privacy and prevents > the establishment of monolithic government control. Under this > system, the user is always in control of his/her credentials. > > This system makes a simplified and efficient federation process > possible. An institution could *federate the identity* of it's users > (or a subset of its users) simply by adding (or modifying) a > credential to each of it's user's digital wallet and creating an > institutional reference within *The Institutional Web of Trust > Repository*. > > This system provides *the "Holy Grail" for single sign on*. > ************************************************************* > * > Digital credentials on NFC enabled smart phones will soon transform > the world of identity management. *Within three years there will be > corporate and government deployments where all members of the > organization are issued NFC enabled smart phones for the purpose of > identity management. > > The basic question is, how can trust be established in the digital > age? If you and I have never met and I come to your website or place > of business, how can you be confident that I am who I say that I am? > *The Institutional Web of Trust will resolve this basic question > regarding the establishment of trust.* > > A key component of the infrastructure will be an easy to use *digital > wallet* where credentials can be securely provisioned and transactions > occur smoothly. This digital wallet will be the *cornerstone of NFC > technologies on mobile devices* and provide the interface for > identity, marketing and financial services. *Every aspect of digital > life that depends on identity and transactions will flow through the > digital wallet. * > > This identity infrastructure will eliminate the possibility of > identity theft for all participants, protect consumers and financial > institutions from fraudulent transactions, greatly reduce cyber-crime > and solve many of the systemic problems of the current Public Key > Infrastructure system, especially the problems of certificate > revocation lists (CRLs) and on-line status checking. > > The solution is simple, practical and transparent to the consumer. > Consumer acceptance will be rapid and widespread. The solution secures > identity, protects individual privacy and prevents the establishment > of monolithic government control. Under this system, the user is > always in control of his/her credentials. > > The essence of the approach is very different from the "Big Brother" > approach recently announced by India. Rather than creating a > centralized directory of private information, there will be a central > repository containing a collection of institutional decisions which > will establish an *Institutional Web of Trust*. > > Compared to a decentralized web of trust which creates a web of > individuals with, "the expectation that anyone receiving [a list of > signatures] will trust at least one or two of the signatures", we will > create a system where *trusted institutions legitimize individual > identity*. Additionally, the *Institutional Web of Trust* will have > centralized controller processes that rely greatly on self-management > and automation resulting in great efficiencies. > > Digital wallets on NFC enabled smart phones will enable users to > secure their private keys and control/present their digital > credentials. Because a user's identity will be authenticated by the > processes of *The Institutional Web of Trust* (not a trust authority) > there is no need for a trust authority to issue and vouch for > public/private keys for individual users. It is only necessary that > the public key be registered and the private key be secured. Users can > self-issue their keys. > > *The Institutional Web of Trust* does not secure identity by, "making > personal data harder to steal". Rather, identity is secured by > self-managing logical inconsistencies within the system, resolving > identity conflicts and preventing fraudulent transactions. > > As Bruce Schneier, author and security guru, pointed out, "Proposed > [identity theft] fixes tend to concentrate on the first issue--making > personal data harder to steal--whereas the real problem is the second > [preventing fraudulent transactions]. If we're ever going to manage > the risks and effects of electronic impersonation [identity theft], > *we must concentrate on preventing and detecting fraudulent > transactions*." [Solving Identity Theft] > > In essence, there are a *limited number of institutions worldwide* > (measured in thousands) that truly matter when it comes to > legitimizing identity. Digital wallets on smart phones will enable > the efficient association of unique public/private keys to a specific > legal identity (legal name and legal address). If there is a > non-unique association, an inconsistency arises in the system. If the > association is unique and verified by one or more legitimate > institutions an individual's identity is secure (as long as the > private key which he/she controls is secure). > > In the process of adding a credential to a user's digital wallet, the > provisioning institution (government agency, bank, university, etc.) > will calculate a secure hash value (numerical representation) of the > credential combined with information from the user's *primary > credential* (legal identity). This hash value will be encrypted with > the user's private key and then encrypted again with the provisioning > institution's private key; this encrypted hash value will then be > stored in *The Institutional Web of Trust Repository* representing *an > institutional validation of the user's identity.* > > This dual encryption establishes that the credential was associated > with the user during the provisioning process rather than simply > asserting the association by a reference from the repository. Also, > There is no need to store any specific information (account number, > balance, etc.) about user's account. The user is in complete control > of the information he/she presents and his/her privacy is maintained. > > When a user presents a credential from his/her digital wallet a > transaction ID will be sent from the authenticating system to the > user's digital wallet, be encrypted with the user's private key and > sent back to the authenticating system. The user can be authenticated > by decrypting the transaction ID with the user's public key from *The > Institutional Web of Trust Repository*. The credential can be > authenticated by calculating the hash value of the credential and then > decrypting the hash value stored in *The Institutional Web of Trust > Repository* with the institution's public key and the user's public key. > > In a variation of this process the provisioning institution does not > store the encrypted hash value in *The Institutional Web of Trust > Repository*; rather, the provisioning institution itself maintains a > repository and a reference to the repository is authenticated by an > entry contained within *The Institutional Web of Trust Repository* > (through the institution's primary credential). In this way an > institution could *federate the identity* of it's users (or a subset > of its users) simply by adding (or modifying) a credential to each of > it's user's digital wallets and creating an institutional reference > within *The Institutional Web of Trust Repository*. > > As part of the federation process, cooperating institutions will most > likely create standard authorization levels for various services and > provision these levels as part of a user's credential. For example, a > coalition of universities may have authorization levels for library > services that will enable users to access any library within the > coalition; government organizations may provision security levels > within a user's credential that enable inter-agency access to > resources; etc. > > There is significant debate regarding the effectiveness of biometrics > in identity management. When a user is not present (authenticating > over a network) there are fatal problems with biometric > authentication. Most significantly, "The main security problem with > biometrics is the inability to create a new secret. If you allow your > fingerprint to be digitized and sent across a network or scanned by a > compromised scanner, it can be stolen. Then someone has a digital copy > of your fingerprint." > > Even if a method of biometric identification proved to be completely > reliable, security issues would still remain. There would be > opportunities to steal someone's biometric signature and forge their > identity credentials, especially if there was a massive store of > private personal data; one successful attack could essentially render > the entire system ineffective. > > When a user is present bio-metric data can be an effective > authenticator. It will be possible to *store bio-metric data within a > user's credential* (not within a central repository) when the > credential is created by the provisioning institution. When a user > presents the credential, verifying the biometric data in the > credential against the individual in real time will provide enhanced > security along with verifying the encrypted transaction code against > the user's public key and verifying the encrypted hash code of the > credential against the value stored in *The Institutional Web of Trust > Repository*. > > While there are many types of biometric identifiers, one of the > simplest and most usable is a photograph of the human face verified by > a human being. Any credential in a user's digital wallet that > includes a photograph (driver's license, passport, bank debit card, > etc.) will be highly reliable when a user presents the credential in > person. > > Why would a major institution (bank, university, corporation, > government agency, etc.) utilize *The Institutional Web of Trust > Repository* instead of its own internal system? When there is no need > for an external third party to rely on a user's credential an > institution may very well utilize its own internal repository. In > this same case, smaller institutions, for reasons of convenience and > cost, might still utilize *The Institutional Web of Trust Repository*. > > Whenever a third party (a party other than the provisioning > institution) must relay on a user's credential, the key services *The > Institutional Web of Trust Repository* provides are assurance that the > user is unique and trustworthy, assurance that the provisioning > institution is unique and trustworthy and assurance that the > credential is trustworthy. Also, *The Institutional Web of Trust > Repository* creates a "*data synergy effect*" which establishes an > *Institutional Web of Trust* (when multiple institutions validate a > unique user's identity the identity becomes more secure and trustworthy). > > If a unique user has digital credentials for a state driver's license, > a passport, a bank debit card, a university ID, insurance cards, > credit cards, etc., all independently validated by trustworthy > institutions, that user's identity is secure and highly trustworthy. > Similar to credit ratings, both individuals and institutions will have > "*trust ratings*" within *The Institutional Web of Trust Repository*. > A centralized notification service will also be provided when > credentials are lost or stolen. > > The uniqueness test for legal identities within *The Institutional Web > of Trust Repository* helps to secure identity and prevent identity > theft. If there is a non-unique association, an inconsistency arises > in the system. Also, easy access for online status checking > establishes the currency of a user's credentials in case the user's > digital wallet is lost or stolen. > > Additionally, the system provides *the "Holy Grail" for single sign > on*. All computers will soon have an interface (USB plugin or internal > card) that will enable NFC interactions with mobile devices. The > digital wallet on a user's cell phone will be provisioned with > credentials containing specified authorizations for different systems > and services. Rather than logging into a directory or utilizing a > complex federated identity process, a user will log onto his/her cell > phone with a PIN and/or a voice authentication signature. The user (or > the authenticating system) will then select the appropriate credential > for the specified system or service with no need to enter another user > name or password (the user's private key will be used to encrypt a > transaction ID). This approach also *solves the "Keys to the Kingdom" > problem* where a single sign on to a directory service opens access to > all the user's systems and services. > > Additionally, the system will enable a process of *mutual > authentication* that will prevent phishing scams. The user's > credential and the institution's credential could both contain a list > of valid URLs which could be matched during the sign on process. > > Existing providers of identity management services should not see *The > Institutional Web of Trust* as a competitor; rather, they should see > it as an infrastructure service (similar to the electric power grid > that has hundreds of energy providers). > > This identity infrastructure will be created with government resources > and be managed to a great extent as a public trust. > > Best regards, > > Michael Duffy > CEO / CTO ~ The Trust Nexus > http://www.thetrustnexus.com > > > > Joni Brennan wrote: > > Thanks Mike, > > It seems like you have a product and you're telling us about it. We > don't allow these types of messages here. So you have a few choices > of how to interact. > > 1 - Parse your email down to a very brief idea and some questions that > the group could respond to. (This mode is more aligned with the true > nature of the list.) Again - as it reads now it's a product > advertisement which is *prohibited. > * > 2 - Browse our groups list from the homepage here > http://kantarainitiative.org. You may find a group you could join and > then share your idea there. > > 3 - Start your own Work or Discussion Group to discuss your identity > based solutions ideas. If you're interested in this path please ping > me directly so we can discuss and I can learn more about your goals. > >From there I could help you to determine if this is appropriate work > material for Kantara or not. > > Cheers - Joni > > On Fri, Jan 29, 2010 at 10:04 AM, Michael Duffy > <thetrustnexus(a)austin.rr.com <mailto:thetrustnexus@austin.rr.com>> wrote: > > My apologies. > > A member of your group actually suggested we post to the community list. > > Our goal was not to promote the company but to discuss the ideas > related to an Institutional Web of Trust with the leading experts in > the field of identity. > > Is there another existing list that would better suit this purpose? > > If not, perhaps Kantara could create such a list (e.g., > ideas(a)kantarainitiative.org <mailto:ideas@kantarainitiative.org>). > > Mike > > > > > Roger Sullivan wrote: > > Let me echo Brett's sentiments. > > None of Kantara's lists are to be used for promotion of oneself or one's company. > > Please refrain from doing that. > > Roger Sullivan > President, Kantara Initiative > > > -----Original Message----- > From: Brett McDowell [mailto:email@brettmcdowell.com] > Sent: Friday, January 29, 2010 11:04 AM > To: Thomas Hardjono > Cc: community(a)kantarainitiative.org <mailto:community@kantarainitiative.org> > Subject: Re: [Kantara - Community] Institutional Web of Trust > > That is certainly not its intent and if it becomes used in that way I > fear we will see mass un-subscription which will undermine our ability > to communicate with each other. So I would ask that all subscribers > refrain from using this list for any form of advertising. > > Thank you, > > || Brett McDowell, Executive Director, Kantara Initiative > > On Fri, Jan 29, 2010 at 10:59 AM, Thomas Hardjono > <standards(a)hardjono.net> <mailto:standards@hardjono.net> wrote: > >> My apologies for asking this trivial question, >> >> but is this Kantara mailing-list allowed to be >> >> used for "advertising" emails? >> >> >> >> Regards. >> >> >> >> /thomas/ >> >> >> >> >> >> >> >> __________________________________________ >> >> Thomas Hardjono >> >> MIT Kerberos Consortium >> >> Massachusetts Institute of Technology >> >> 77 Massachusetts Ave W92-152 >> >> Cambridge, MA 02139 >> >> >> >> email: hardjono[at]mit.edu <http://mit.edu> >> >> web: http://www.kerberos.org >> >> mobile: +1 781-729-9559 >> >> desk: +1 617-715-2451 >> >> __________________________________________ >> >> >> >> >> >> >> >> From: community-bounces(a)kantarainitiative.org <mailto:community-bounces@kantarainitiative.org> >> [mailto:community-bounces@kantarainitiative.org] On Behalf Of Michael Duffy >> Sent: Friday, January 29, 2010 8:47 AM >> To: community(a)kantarainitiative.org <mailto:community@kantarainitiative.org> >> Subject: [Kantara - Community] Institutional Web of Trust >> >> >> >> We believe we have THE solution that will realize the vision of the Kantara >> Initiative: Ensure secure, identity-based, online interactions while >> preventing misuse of personal information so that networks will become >> privacy protecting and more natively trustworthy environments. >> >> We realize that is a bold statement. We humbly ask the members of the >> Kantara Initiative to review our approach: >> >> Digital credentials on NFC enabled smart phones will soon transform the >> world of identity management. >> >> The Trust Nexus is a startup company located in Austin, TX. We hold >> intellectual property rights that will enable us to build the infrastructure >> for secure identity in the digital age. Whoever controls the infrastructure >> for secure identity will also play a leading role in the emerging world of >> m-Commerce. >> >> The basic question is, how can trust be established in the digital age? If >> you and I have never met and I come to your website or place of business, >> how can you be confident that I am who I say that I am? The Trust Nexus >> answers this basic question regarding the establishment of trust. >> >> A key component of our infrastructure will be an easy to use digital wallet >> where credentials can be securely provisioned and transactions occur >> smoothly. This digital wallet will be the cornerstone of NFC technologies on >> mobile devices and provide the interface for identity, marketing and >> financial services. Every aspect of digital life that depends on identity >> and transactions will flow through the digital wallet. >> >> The digital wallet on NFC enabled smart phones will be one of the most >> valuable assets in the digital age. The digital wallet and supporting >> infrastructure will be based on industry standards that will enable the >> mobile network operators (MNOs) to meter services that flow through their >> networks and participate in new marketing/advertising models. >> >> The identity infrastructure we have designed will eliminate the possibility >> of identity theft for all participants, protect consumers and financial >> institutions from fraudulent transactions, greatly reduce cyber-crime and >> solve many of the systemic problems of the current Public Key Infrastructure >> system, especially the problems of certificate revocation lists (CRLs) and >> on-line status checking. >> >> Our solution is simple, practical and transparent to the consumer. Consumer >> acceptance will be rapid and widespread. Our solution secures identity, >> protects individual privacy and prevents the establishment of monolithic >> government control. Under our system, the user is always in control of >> his/her credentials. >> >> The essence of our approach is very different from the "Big Brother" >> approach recently announced by India. Rather than creating a centralized >> directory of private information, we will create a central repository >> containing a collection of institutional decisions which will establish an >> Institutional Web of Trust. >> >> Compared to a decentralized web of trust which creates a web of individuals >> with, "the expectation that anyone receiving [a list of signatures] will >> trust at least one or two of the signatures", we will create a system where >> trusted institutions legitimize individual identity. Additionally, the >> Institutional Web of Trust established by The Trust Nexus will have >> centralized controller processes that rely greatly on self-management and >> automation resulting in great efficiencies. >> >> Digital wallets on NFC enabled smart phones will enable users to secure >> their private keys and control/present their digital credentials. Because a >> user's identity will be authenticated by the processes of The Trust Nexus >> (not a trust authority) there is no need for a trust authority to issue and >> vouch for public/private keys for individual users. It is only necessary >> that the public key be registered and the private key be secured. Users can >> self-issue their keys. >> >> The Trust Nexus does not secure identity by, "making personal data harder to >> steal". Rather, identity is secured by self-managing logical >> inconsistencies within the system, resolving identity conflicts and >> preventing fraudulent transactions. >> >> As Bruce Schneier, author and security guru, pointed out, "Proposed >> [identity theft] fixes tend to concentrate on the first issue--making >> personal data harder to steal--whereas the real problem is the second >> [preventing fraudulent transactions]. If we're ever going to manage the >> risks and effects of electronic impersonation [identity theft], we must >> concentrate on preventing and detecting fraudulent transactions." [Solving >> Identity Theft] >> >> In essence, there are a limited number of institutions worldwide (measured >> in thousands) that truly matter when it comes to legitimizing identity. >> Digital wallets on smart phones will enable the efficient association of >> unique public/private keys to a specific legal identity (legal name and >> legal address). If there is a non-unique association, an inconsistency >> arises in the system. If the association is unique and verified by one or >> more legitimate institutions an individual's identity is secure (as long as >> the private key which he/she controls is secure). >> >> In the process of adding a credential to a user's digital wallet, the >> provisioning institution (government agency, bank, university, etc.) will >> calculate a secure hash value (numerical representation) of the credential >> combined with information from the user's primary credential (legal >> identity). This hash value will be encrypted with the user's private key >> and then encrypted again with the provisioning institution's private key; >> this encrypted hash value will then be stored in The Trust Nexus Repository >> representing an institutional validation of the user's identity. >> >> This dual encryption establishes that the credential was associated with the >> user during the provisioning process rather than simply asserting the >> association by a reference from the repository. Also, There is no need to >> store any specific information (account number, balance, etc.) about user's >> account. The user is in complete control of the information he/she presents >> and his/her privacy is maintained. >> >> When a user presents a credential from his/her digital wallet a transaction >> ID will be sent from the authenticating system to the user's digital wallet, >> be encrypted with the user's private key and sent back to the authenticating >> system. The user can be authenticated by decrypting the transaction ID with >> the user's public key from The Trust Nexus Repository. The credential can be >> authenticated by calculating the hash value of the credential and then >> decrypting the hash value stored in The Trust Nexus Repository with the >> institution's public key and the user's public key. >> >> In a variation of this process the provisioning institution does not store >> the encrypted hash value in The Trust Nexus Repository; rather, the >> provisioning institution itself maintains a repository and a reference to >> the repository is authenticated by an entry contained within The Trust Nexus >> Repository (through the institution's primary credential). In this way an >> institution could federate the identity of it's users (or a subset of its >> users) simply by adding (or modifying) a credential to each of it's user's >> digital wallets and creating an institutional reference within The Trust >> Nexus Repository. >> >> As part of the federation process, cooperating institutions will most likely >> create standard authorization levels for various services and provision >> these levels as part of a user's credential. For example, a coalition of >> universities may have authorization levels for library services that will >> enable users to access any library within the coalition; government >> organizations may provision security levels within a user's credential that >> enable inter-agency access to resources; etc. >> >> There is significant debate regarding the effectiveness of biometrics in >> identity management. When a user is not present (authenticating over a >> network) there are fatal problems with biometric authentication. Most >> significantly, "The main security problem with biometrics is the inability >> to create a new secret. If you allow your fingerprint to be digitized and >> sent across a network or scanned by a compromised scanner, it can be stolen. >> Then someone has a digital copy of your fingerprint." >> >> Even if a method of biometric identification proved to be completely >> reliable, security issues would still remain. There would be opportunities >> to steal someone's biometric signature and forge their identity credentials, >> especially if there was a massive store of private personal data; one >> successful attack could essentially render the entire system ineffective. >> >> When a user is present bio-metric data can be an effective authenticator. >> It will be possible to store bio-metric data within a user's credential (not >> within a central repository) when the credential is created by the >> provisioning institution. When a user presents the credential verifying the >> biometric data in the credential against the individual in real time will >> provide enhanced security along with verifying the encrypted transaction >> code against the user's public key in The Trust Nexus Repository and >> verifying the encrypted hash code of the credential against The Trust Nexus >> Repository. >> >> While there are many types of biometric identifiers, one of the simplest and >> most usable is a photograph of the human face verified by a human being. >> Any credential in a user's digital wallet that includes a photograph >> (driver's license, passport, bank debit card, etc.) will be highly reliable >> when a user presents the credential in person. >> >> Why would a major institution (bank, university, corporation, government >> agency, etc.) utilize The Trust Nexus Repository instead of its own internal >> system? When there is no need for an external third party to rely on a >> user's credential an institution may very well utilize its own internal >> repository. In this same case, smaller institutions, for reasons of >> convenience and cost, might still utilize The Trust Nexus Repository. >> >> Whenever a third party (a party other than the provisioning institution) >> must relay on a user's credential, the key services The Trust Nexus >> Repository provides are assurance that the user is unique and trustworthy, >> assurance that the provisioning institution is unique and trustworthy and >> assurance that the credential is trustworthy. Also, The Trust Nexus >> Repository creates a "data synergy effect" which establishes an >> Institutional Web of Trust (when multiple institutions validate a unique >> user's identity the identity becomes more secure and trustworthy). >> >> If a unique user has digital credentials for a state driver's license, a >> passport, a bank debit card, a university ID, insurance cards, credit cards, >> etc., all independently validated by trustworthy institutions, that user's >> identity is secure and highly trustworthy. Similar to credit ratings, both >> individuals and institutions will have "trust ratings" within The Trust >> Nexus Repository. A centralized notification service will also be provided >> when credentials are lost or stolen. >> >> The uniqueness test for legal identities within The Trust Nexus Repository >> helps to secure identity and prevent identity theft. If there is a >> non-unique association, an inconsistency arises in the system. Also, easy >> access for online status checking establishes the currency of a user's >> credentials in case the user's digital wallet is lost or stolen. And most >> importantly, The Trust Nexus creates a "data synergy effect" which >> establishes an Institutional Web of Trust. >> >> Additionally, our system provides the "Holy Grail" for single sign on. All >> computers will soon have an interface (USB plugin or internal card) that >> will enable NFC interactions with mobile devices. The digital wallet on a >> user's cell phone will be provisioned with credentials containing specified >> authorizations different systems and services. Rather than logging into a >> directory or utilizing a complex federated identity process, a user will log >> onto his/her cell phone with a PIN and a voice authentication signature. The >> user (or the authenticating system) will then select the appropriate >> credential for the specified system or service with no need to enter another >> user name or password (the user's private key will be used to encrypt a >> transaction ID). This approach also solves the "Keys to the Kingdom" problem >> where a single sign on to a directory service opens access to all the user's >> systems and services. >> >> We are confident we have a transforming technology and a clear vision of the >> future. No one has found a conceptual flaw in the system. Existing >> providers of identity management services should not see The Trust Nexus as >> a competitor; rather, they should see us as an infrastructure provider >> (similar to the electric power grid that has hundreds of energy providers). >> >> Best regards, >> >> Michael Duffy >> CEO / CTO ~ The Trust Nexus >> http://www.thetrustnexus.com >> >> >> >> >> >> >> _______________________________________________ >> Community mailing list >> Community(a)kantarainitiative.org <mailto:Community@kantarainitiative.org> >> http://kantarainitiative.org/mailman/listinfo/community >> >> >> > _______________________________________________ > Community mailing list > Community(a)kantarainitiative.org <mailto:Community@kantarainitiative.org> > http://kantarainitiative.org/mailman/listinfo/community > _______________________________________________ > Community mailing list > Community(a)kantarainitiative.org <mailto:Community@kantarainitiative.org> > http://kantarainitiative.org/mailman/listinfo/community > > > > > _______________________________________________ > Community mailing list > Community(a)kantarainitiative.org <mailto:Community@kantarainitiative.org> > http://kantarainitiative.org/mailman/listinfo/community > > > > > -- > Joni Brennan > IEEE-ISTO > Kantara Initiative > Program Director > voice:+1 732-226-4223 > email: joni @ ieee-isto.org <http://ieee-isto.org> > gtalk: jonibrennan > skype: upon request > > Join the conversation on the community@ list - > http://kantarainitiative.org/mailman/listinfo/community > > >

1 0

Re: [Kantara - Community] Institutional Web of Trust
by Joni Brennan 30 Jan '10

30 Jan '10

Hello, In the Kantara Initiative context, the Trust Framework discussions take place across a fair subset of the Kantara Work and Discussion Groups. But the best starting places would be... The Identity Assurance Work Group (IAWG) [1]. Privacy and Public Policy specific context discussions take place in the Privacy and Public Policy Work Group (P3WG) [2]. Relating to health care specific concerns one should see the Healthcare Identity Assurance Work Group (HIAWG) [3]. There are other groups that could, and should, be mentioned here but these 3 would make a good starting point. On each of the WG home pages you'll find links to review their mail archives and also to Join each group. To become a Participant in any of these groups follow the link to 'Join', indicate agreement to the group's IPR policy and submit the form. Start here: [1] http://kantarainitiative.org/confluence/display/idassurance [2] http://kantarainitiative.org/confluence/display/p3wg [3] http://kantarainitiative.org/confluence/display/healthidassurance - Joni On Sat, Jan 30, 2010 at 6:43 AM, Hal Warren <hwarren(a)openidsociety.org>wrote: > In spite of the inappropriateness of Michael Duffy’s message, it raises an > important question regarding the militation of trust. The answer impacts > all of our futures. > > Trusted digital identity requires engineering and deserves careful > consensus. There is no current single solution that meets the need to > jack-up the bandwidth of human-to-human communication. This engineering > problem needs to be solved by engineers. The standard for measurement > should be simple: that which increases the reliable throughput of > human-to-human transactions wins. It is all about the protocols and we need > to be a bit “protocol agnostic” and solution focused. > > The trust model presented by Michael falls far short. Trust should be > available from the location where it naturally occurs, be it my municipality > to validate my residency, my professional affiliations, my educational > institutions, my family affiliations, my religious affiliations, etc. This > requires a complex faceted framework through which such trusted claims can > be transmitted and validated. > > Where does the discussion on the architecture of the trust framework take > place? Who is there? > > Hal > > Hallie D. Warren, III > President > OpenID Society > 2020 Pennsylvania Ave., NW #364 > Washington, DC 20006 > phone: 202-640-1953 > email: hwarren(a)OpenIDsociety.org > > > > On Jan 29, 2010, at 2:13 PM, Joni Brennan wrote: > > Thanks Mike, > > It seems like you have a product and you're telling us about it. We don't > allow these types of messages here. So you have a few choices of how to > interact. > > 1 - Parse your email down to a very brief idea and some questions that the > group could respond to. (This mode is more aligned with the true nature of > the list.) Again - as it reads now it's a product advertisement which is > *prohibited. > * > 2 - Browse our groups list from the homepage here > http://kantarainitiative.org. You may find a group you could join and > then share your idea there. > > 3 - Start your own Work or Discussion Group to discuss your identity based > solutions ideas. If you're interested in this path please ping me directly > so we can discuss and I can learn more about your goals. From there I could > help you to determine if this is appropriate work material for Kantara or > not. > > Cheers - Joni > > On Fri, Jan 29, 2010 at 10:04 AM, Michael Duffy < > thetrustnexus(a)austin.rr.com> wrote: > >> My apologies. >> >> A member of your group actually suggested we post to the community list. >> >> Our goal was not to promote the company but to discuss the ideas related >> to an Institutional Web of Trust with the leading experts in the field of >> identity. >> >> Is there another existing list that would better suit this purpose? >> >> If not, perhaps Kantara could create such a list (e.g., >> ideas(a)kantarainitiative.org) >> >> Mike >> >> >> >> Roger Sullivan wrote: >> >> Let me echo Brett's sentiments. >> >> None of Kantara's lists are to be used for promotion of oneself or one's company. >> >> Please refrain from doing that. >> >> Roger Sullivan >> President, Kantara Initiative >> >> >> -----Original Message----- >> From: Brett McDowell [mailto:email@brettmcdowell.com <email(a)brettmcdowell.com>] >> Sent: Friday, January 29, 2010 11:04 AM >> To: Thomas Hardjono >> Cc: community(a)kantarainitiative.org >> Subject: Re: [Kantara - Community] Institutional Web of Trust >> >> That is certainly not its intent and if it becomes used in that way I >> fear we will see mass un-subscription which will undermine our ability >> to communicate with each other. So I would ask that all subscribers >> refrain from using this list for any form of advertising. >> >> Thank you, >> >> || Brett McDowell, Executive Director, Kantara Initiative >> >> On Fri, Jan 29, 2010 at 10:59 AM, Thomas Hardjono<standards(a)hardjono.net> <standards(a)hardjono.net> wrote: >> >> >> My apologies for asking this trivial question, >> >> but is this Kantara mailing-list allowed to be >> >> used for "advertising" emails? >> >> >> >> Regards. >> >> >> >> /thomas/ >> >> >> >> >> >> >> >> __________________________________________ >> >> Thomas Hardjono >> >> MIT Kerberos Consortium >> >> Massachusetts Institute of Technology >> >> 77 Massachusetts Ave W92-152 >> >> Cambridge, MA 02139 >> >> >> >> email: hardjono[at]mit.edu >> >> web: http://www.kerberos.org >> >> mobile: +1 781-729-9559 >> >> desk: +1 617-715-2451 >> >> __________________________________________ >> >> >> >> >> >> >> >> From: community-bounces(a)kantarainitiative.org >> [mailto:community-bounces@kantarainitiative.org <community-bounces(a)kantarainitiative.org>] On Behalf Of Michael Duffy >> Sent: Friday, January 29, 2010 8:47 AM >> To: community(a)kantarainitiative.org >> Subject: [Kantara - Community] Institutional Web of Trust >> >> >> >> We believe we have THE solution that will realize the vision of the Kantara >> Initiative: Ensure secure, identity-based, online interactions while >> preventing misuse of personal information so that networks will become >> privacy protecting and more natively trustworthy environments. >> >> We realize that is a bold statement. We humbly ask the members of the >> Kantara Initiative to review our approach: >> >> Digital credentials on NFC enabled smart phones will soon transform the >> world of identity management. >> >> The Trust Nexus is a startup company located in Austin, TX. We hold >> intellectual property rights that will enable us to build the infrastructure >> for secure identity in the digital age. Whoever controls the infrastructure >> for secure identity will also play a leading role in the emerging world of >> m-Commerce. >> >> The basic question is, how can trust be established in the digital age? If >> you and I have never met and I come to your website or place of business, >> how can you be confident that I am who I say that I am? The Trust Nexus >> answers this basic question regarding the establishment of trust. >> >> A key component of our infrastructure will be an easy to use digital wallet >> where credentials can be securely provisioned and transactions occur >> smoothly. This digital wallet will be the cornerstone of NFC technologies on >> mobile devices and provide the interface for identity, marketing and >> financial services. Every aspect of digital life that depends on identity >> and transactions will flow through the digital wallet. >> >> The digital wallet on NFC enabled smart phones will be one of the most >> valuable assets in the digital age. The digital wallet and supporting >> infrastructure will be based on industry standards that will enable the >> mobile network operators (MNOs) to meter services that flow through their >> networks and participate in new marketing/advertising models. >> >> The identity infrastructure we have designed will eliminate the possibility >> of identity theft for all participants, protect consumers and financial >> institutions from fraudulent transactions, greatly reduce cyber-crime and >> solve many of the systemic problems of the current Public Key Infrastructure >> system, especially the problems of certificate revocation lists (CRLs) and >> on-line status checking. >> >> Our solution is simple, practical and transparent to the consumer. Consumer >> acceptance will be rapid and widespread. Our solution secures identity, >> protects individual privacy and prevents the establishment of monolithic >> government control. Under our system, the user is always in control of >> his/her credentials. >> >> The essence of our approach is very different from the "Big Brother" >> approach recently announced by India. Rather than creating a centralized >> directory of private information, we will create a central repository >> containing a collection of institutional decisions which will establish an >> Institutional Web of Trust. >> >> Compared to a decentralized web of trust which creates a web of individuals >> with, "the expectation that anyone receiving [a list of signatures] will >> trust at least one or two of the signatures", we will create a system where >> trusted institutions legitimize individual identity. Additionally, the >> Institutional Web of Trust established by The Trust Nexus will have >> centralized controller processes that rely greatly on self-management and >> automation resulting in great efficiencies. >> >> Digital wallets on NFC enabled smart phones will enable users to secure >> their private keys and control/present their digital credentials. Because a >> user's identity will be authenticated by the processes of The Trust Nexus >> (not a trust authority) there is no need for a trust authority to issue and >> vouch for public/private keys for individual users. It is only necessary >> that the public key be registered and the private key be secured. Users can >> self-issue their keys. >> >> The Trust Nexus does not secure identity by, "making personal data harder to >> steal". Rather, identity is secured by self-managing logical >> inconsistencies within the system, resolving identity conflicts and >> preventing fraudulent transactions. >> >> As Bruce Schneier, author and security guru, pointed out, "Proposed >> [identity theft] fixes tend to concentrate on the first issue--making >> personal data harder to steal--whereas the real problem is the second >> [preventing fraudulent transactions]. If we're ever going to manage the >> risks and effects of electronic impersonation [identity theft], we must >> concentrate on preventing and detecting fraudulent transactions." [Solving >> Identity Theft] >> >> In essence, there are a limited number of institutions worldwide (measured >> in thousands) that truly matter when it comes to legitimizing identity. >> Digital wallets on smart phones will enable the efficient association of >> unique public/private keys to a specific legal identity (legal name and >> legal address). If there is a non-unique association, an inconsistency >> arises in the system. If the association is unique and verified by one or >> more legitimate institutions an individual's identity is secure (as long as >> the private key which he/she controls is secure). >> >> In the process of adding a credential to a user's digital wallet, the >> provisioning institution (government agency, bank, university, etc.) will >> calculate a secure hash value (numerical representation) of the credential >> combined with information from the user's primary credential (legal >> identity). This hash value will be encrypted with the user's private key >> and then encrypted again with the provisioning institution's private key; >> this encrypted hash value will then be stored in The Trust Nexus Repository >> representing an institutional validation of the user's identity. >> >> This dual encryption establishes that the credential was associated with the >> user during the provisioning process rather than simply asserting the >> association by a reference from the repository. Also, There is no need to >> store any specific information (account number, balance, etc.) about user's >> account. The user is in complete control of the information he/she presents >> and his/her privacy is maintained. >> >> When a user presents a credential from his/her digital wallet a transaction >> ID will be sent from the authenticating system to the user's digital wallet, >> be encrypted with the user's private key and sent back to the authenticating >> system. The user can be authenticated by decrypting the transaction ID with >> the user's public key from The Trust Nexus Repository. The credential can be >> authenticated by calculating the hash value of the credential and then >> decrypting the hash value stored in The Trust Nexus Repository with the >> institution's public key and the user's public key. >> >> In a variation of this process the provisioning institution does not store >> the encrypted hash value in The Trust Nexus Repository; rather, the >> provisioning institution itself maintains a repository and a reference to >> the repository is authenticated by an entry contained within The Trust Nexus >> Repository (through the institution's primary credential). In this way an >> institution could federate the identity of it's users (or a subset of its >> users) simply by adding (or modifying) a credential to each of it's user's >> digital wallets and creating an institutional reference within The Trust >> Nexus Repository. >> >> As part of the federation process, cooperating institutions will most likely >> create standard authorization levels for various services and provision >> these levels as part of a user's credential. For example, a coalition of >> universities may have authorization levels for library services that will >> enable users to access any library within the coalition; government >> organizations may provision security levels within a user's credential that >> enable inter-agency access to resources; etc. >> >> There is significant debate regarding the effectiveness of biometrics in >> identity management. When a user is not present (authenticating over a >> network) there are fatal problems with biometric authentication. Most >> significantly, "The main security problem with biometrics is the inability >> to create a new secret. If you allow your fingerprint to be digitized and >> sent across a network or scanned by a compromised scanner, it can be stolen. >> Then someone has a digital copy of your fingerprint." >> >> Even if a method of biometric identification proved to be completely >> reliable, security issues would still remain. There would be opportunities >> to steal someone's biometric signature and forge their identity credentials, >> especially if there was a massive store of private personal data; one >> successful attack could essentially render the entire system ineffective. >> >> When a user is present bio-metric data can be an effective authenticator. >> It will be possible to store bio-metric data within a user's credential (not >> within a central repository) when the credential is created by the >> provisioning institution. When a user presents the credential verifying the >> biometric data in the credential against the individual in real time will >> provide enhanced security along with verifying the encrypted transaction >> code against the user's public key in The Trust Nexus Repository and >> verifying the encrypted hash code of the credential against The Trust Nexus >> Repository. >> >> While there are many types of biometric identifiers, one of the simplest and >> most usable is a photograph of the human face verified by a human being. >> Any credential in a user's digital wallet that includes a photograph >> (driver's license, passport, bank debit card, etc.) will be highly reliable >> when a user presents the credential in person. >> >> Why would a major institution (bank, university, corporation, government >> agency, etc.) utilize The Trust Nexus Repository instead of its own internal >> system? When there is no need for an external third party to rely on a >> user's credential an institution may very well utilize its own internal >> repository. In this same case, smaller institutions, for reasons of >> convenience and cost, might still utilize The Trust Nexus Repository. >> >> Whenever a third party (a party other than the provisioning institution) >> must relay on a user's credential, the key services The Trust Nexus >> Repository provides are assurance that the user is unique and trustworthy, >> assurance that the provisioning institution is unique and trustworthy and >> assurance that the credential is trustworthy. Also, The Trust Nexus >> Repository creates a "data synergy effect" which establishes an >> Institutional Web of Trust (when multiple institutions validate a unique >> user's identity the identity becomes more secure and trustworthy). >> >> If a unique user has digital credentials for a state driver's license, a >> passport, a bank debit card, a university ID, insurance cards, credit cards, >> etc., all independently validated by trustworthy institutions, that user's >> identity is secure and highly trustworthy. Similar to credit ratings, both >> individuals and institutions will have "trust ratings" within The Trust >> Nexus Repository. A centralized notification service will also be provided >> when credentials are lost or stolen. >> >> The uniqueness test for legal identities within The Trust Nexus Repository >> helps to secure identity and prevent identity theft. If there is a >> non-unique association, an inconsistency arises in the system. Also, easy >> access for online status checking establishes the currency of a user's >> credentials in case the user's digital wallet is lost or stolen. And most >> importantly, The Trust Nexus creates a "data synergy effect" which >> establishes an Institutional Web of Trust. >> >> Additionally, our system provides the "Holy Grail" for single sign on. All >> computers will soon have an interface (USB plugin or internal card) that >> will enable NFC interactions with mobile devices. The digital wallet on a >> user's cell phone will be provisioned with credentials containing specified >> authorizations different systems and services. Rather than logging into a >> directory or utilizing a complex federated identity process, a user will log >> onto his/her cell phone with a PIN and a voice authentication signature. The >> user (or the authenticating system) will then select the appropriate >> credential for the specified system or service with no need to enter another >> user name or password (the user's private key will be used to encrypt a >> transaction ID). This approach also solves the "Keys to the Kingdom" problem >> where a single sign on to a directory service opens access to all the user's >> systems and services. >> >> We are confident we have a transforming technology and a clear vision of the >> future. No one has found a conceptual flaw in the system. Existing >> providers of identity management services should not see The Trust Nexus as >> a competitor; rather, they should see us as an infrastructure provider >> (similar to the electric power grid that has hundreds of energy providers). >> >> Best regards, >> >> Michael Duffy >> CEO / CTO ~ The Trust Nexushttp://www.thetrustnexus.com >> >> >> >> >> >> >> _______________________________________________ >> Community mailing listCommunity@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/community >> >> >> _______________________________________________ >> Community mailing listCommunity@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/community >> _______________________________________________ >> Community mailing listCommunity@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/community >> >> >> _______________________________________________ >> Community mailing list >> Community(a)kantarainitiative.org >> http://kantarainitiative.org/mailman/listinfo/community >> >> > > > -- > Joni Brennan > IEEE-ISTO > Kantara Initiative > Program Director > voice:+1 732-226-4223 > email: joni @ ieee-isto.org > gtalk: jonibrennan > skype: upon request > > Join the conversation on the community@ list - > http://kantarainitiative.org/mailman/listinfo/community > > > _______________________________________________ > Community mailing list > Community(a)kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/community > > > -- Joni Brennan IEEE-ISTO Kantara Initiative Program Director voice:+1 732-226-4223 email: joni @ ieee-isto.org gtalk: jonibrennan skype: upon request Join the conversation on the community@ list - http://kantarainitiative.org/mailman/listinfo/community

1 0

Re: [Kantara - Community] Institutional Web of Trust
by Michael Duffy 30 Jan '10

30 Jan '10

We *strongly agree* with Hal's statement: "Trust should be available from the location where it naturally occurs, be it my municipality to validate my residency, my professional affiliations, my educational institutions, my family affiliations, my religious affiliations, etc." This is exactly what the *Institutional Web of Trust *does. When a credential is provisioned to a user's digital wallet by a state driver's license agency, bank, municipality, professional association, educational institution, Internet community (there will be a World of WarCraft credential for maintaining levels and attributes) or even a village group, *a record of that localized decision* is stored in the *Institutional Web of Trust Repository*. *The **Institutional Web of Trust Repository** provides a service which makes localized decisions verifiable. *If my local bank provisions a debit card to my digital wallet the *Institutional Web of Trust Repository *will make it possible for anyone to verify that credential. Among other positive results, this system will greatly reduce financial fraud. Note: The "repository" will be a world wide collection of inter-connected repositories, most of which will be run under government supervision by a coalition of mobile network operators. We *strongly disagree* with Hal's statement: "This requires a complex faceted framework through which such trusted claims can be transmitted and validated." When it comes to technology systems, simplicity and elegance are far better than, "a complex faceted framework". As an Internet based protocol OpenID was ambitious in its scope; however, it failed to create a coherent security model (http://www.slideshare.net/itickr/open-id-security-issues-2468599) it failed to gain consumer support (How many of the more than two hundred million Yahoo users who have access to OpenID are using OpenID?) and most significantly it failed to take into account that, *"Digital credentials on NFC enabled smart phones will soon transform the world of identity management."* * *Best regards, Michael Duffy CEO / CTO ~ The Trust Nexus http://www.thetrustnexus.com Hal Warren wrote: > In spite of the inappropriateness of Michael Duffy’s message, it > raises an important question regarding the militation of trust. The > answer impacts all of our futures. > > Trusted digital identity requires engineering and deserves careful > consensus. There is no current single solution that meets the need to > jack-up the bandwidth of human-to-human communication. This > engineering problem needs to be solved by engineers. The standard for > measurement should be simple: that which increases the reliable > throughput of human-to-human transactions wins. It is all about the > protocols and we need to be a bit “protocol agnostic” and solution > focused. > > The trust model presented by Michael falls far short. Trust should be > available from the location where it naturally occurs, be it my > municipality to validate my residency, my professional affiliations, > my educational institutions, my family affiliations, my religious > affiliations, etc. This requires a complex faceted framework through > which such trusted claims can be transmitted and validated. > > Where does the discussion on the architecture of the trust framework > take place? Who is there? > > Hal > > Hallie D. Warren, III > President > OpenID Society > 2020 Pennsylvania Ave., NW #364 > Washington, DC 20006 > phone: 202-640-1953 > email: hal(a)OpenIDsociety.org <mailto:hal@OpenIDsociety.org> > > > On Jan 29, 2010, at 2:13 PM, Joni Brennan wrote: > >> Thanks Mike, >> >> It seems like you have a product and you're telling us about it. We >> don't allow these types of messages here. So you have a few choices >> of how to interact. >> >> 1 - Parse your email down to a very brief idea and some questions >> that the group could respond to. (This mode is more aligned with >> the true nature of the list.) Again - as it reads now it's a product >> advertisement which is *prohibited. >> * >> 2 - Browse our groups list from the homepage here >> http://kantarainitiative.org <http://kantarainitiative.org/>. You >> may find a group you could join and then share your idea there. >> >> 3 - Start your own Work or Discussion Group to discuss your identity >> based solutions ideas. If you're interested in this path please ping >> me directly so we can discuss and I can learn more about your goals. >> From there I could help you to determine if this is appropriate work >> material for Kantara or not. >> >> Cheers - Joni >> >> On Fri, Jan 29, 2010 at 10:04 AM, Michael Duffy >> <thetrustnexus(a)austin.rr.com <mailto:thetrustnexus@austin.rr.com>> wrote: >> >> My apologies. >> >> A member of your group actually suggested we post to the >> community list. >> >> Our goal was not to promote the company but to discuss the ideas >> related to an Institutional Web of Trust with the leading experts >> in the field of identity. >> >> Is there another existing list that would better suit this purpose? >> >> If not, perhaps Kantara could create such a list (e.g., >> ideas(a)kantarainitiative.org <mailto:ideas@kantarainitiative.org>). >> >> Mike >> >> >> >> Roger Sullivan wrote: >>> Let me echo Brett's sentiments. >>> >>> None of Kantara's lists are to be used for promotion of oneself or one's company. >>> >>> Please refrain from doing that. >>> >>> Roger Sullivan >>> President, Kantara Initiative >>> >>> >>> -----Original Message----- >>> From: Brett McDowell [mailto:email@brettmcdowell.com] >>> Sent: Friday, January 29, 2010 11:04 AM >>> To: Thomas Hardjono >>> Cc: community(a)kantarainitiative.org <mailto:community@kantarainitiative.org> >>> Subject: Re: [Kantara - Community] Institutional Web of Trust >>> >>> That is certainly not its intent and if it becomes used in that way I >>> fear we will see mass un-subscription which will undermine our ability >>> to communicate with each other. So I would ask that all subscribers >>> refrain from using this list for any form of advertising. >>> >>> Thank you, >>> >>> || Brett McDowell, Executive Director, Kantara Initiative >>> >>> On Fri, Jan 29, 2010 at 10:59 AM, Thomas Hardjono >>> <standards(a)hardjono.net> <mailto:standards@hardjono.net> wrote: >>> >>>> My apologies for asking this trivial question, >>>> >>>> but is this Kantara mailing-list allowed to be >>>> >>>> used for "advertising" emails? >>>> >>>> >>>> >>>> Regards. >>>> >>>> >>>> >>>> /thomas/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> __________________________________________ >>>> >>>> Thomas Hardjono >>>> >>>> MIT Kerberos Consortium >>>> >>>> Massachusetts Institute of Technology >>>> >>>> 77 Massachusetts Ave W92-152 >>>> >>>> Cambridge, MA 02139 >>>> >>>> >>>> >>>> email: hardjono[at]mit.edu <http://mit.edu/> >>>> >>>> web: http://www.kerberos.org <http://www.kerberos.org/> >>>> >>>> mobile: +1 781-729-9559 >>>> >>>> desk: +1 617-715-2451 >>>> >>>> __________________________________________ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> From: community-bounces(a)kantarainitiative.org <mailto:community-bounces@kantarainitiative.org> >>>> [mailto:community-bounces@kantarainitiative.org] On Behalf Of Michael Duffy >>>> Sent: Friday, January 29, 2010 8:47 AM >>>> To: community(a)kantarainitiative.org <mailto:community@kantarainitiative.org> >>>> Subject: [Kantara - Community] Institutional Web of Trust >>>> >>>> >>>> >>>> We believe we have THE solution that will realize the vision of the Kantara >>>> Initiative: Ensure secure, identity-based, online interactions while >>>> preventing misuse of personal information so that networks will become >>>> privacy protecting and more natively trustworthy environments. >>>> >>>> We realize that is a bold statement. We humbly ask the members of the >>>> Kantara Initiative to review our approach: >>>> >>>> Digital credentials on NFC enabled smart phones will soon transform the >>>> world of identity management. >>>> >>>> The Trust Nexus is a startup company located in Austin, TX. We hold >>>> intellectual property rights that will enable us to build the infrastructure >>>> for secure identity in the digital age. Whoever controls the infrastructure >>>> for secure identity will also play a leading role in the emerging world of >>>> m-Commerce. >>>> >>>> The basic question is, how can trust be established in the digital age? If >>>> you and I have never met and I come to your website or place of business, >>>> how can you be confident that I am who I say that I am? The Trust Nexus >>>> answers this basic question regarding the establishment of trust. >>>> >>>> A key component of our infrastructure will be an easy to use digital wallet >>>> where credentials can be securely provisioned and transactions occur >>>> smoothly. This digital wallet will be the cornerstone of NFC technologies on >>>> mobile devices and provide the interface for identity, marketing and >>>> financial services. Every aspect of digital life that depends on identity >>>> and transactions will flow through the digital wallet. >>>> >>>> The digital wallet on NFC enabled smart phones will be one of the most >>>> valuable assets in the digital age. The digital wallet and supporting >>>> infrastructure will be based on industry standards that will enable the >>>> mobile network operators (MNOs) to meter services that flow through their >>>> networks and participate in new marketing/advertising models. >>>> >>>> The identity infrastructure we have designed will eliminate the possibility >>>> of identity theft for all participants, protect consumers and financial >>>> institutions from fraudulent transactions, greatly reduce cyber-crime and >>>> solve many of the systemic problems of the current Public Key Infrastructure >>>> system, especially the problems of certificate revocation lists (CRLs) and >>>> on-line status checking. >>>> >>>> Our solution is simple, practical and transparent to the consumer. Consumer >>>> acceptance will be rapid and widespread. Our solution secures identity, >>>> protects individual privacy and prevents the establishment of monolithic >>>> government control. Under our system, the user is always in control of >>>> his/her credentials. >>>> >>>> The essence of our approach is very different from the "Big Brother" >>>> approach recently announced by India. Rather than creating a centralized >>>> directory of private information, we will create a central repository >>>> containing a collection of institutional decisions which will establish an >>>> Institutional Web of Trust. >>>> >>>> Compared to a decentralized web of trust which creates a web of individuals >>>> with, "the expectation that anyone receiving [a list of signatures] will >>>> trust at least one or two of the signatures", we will create a system where >>>> trusted institutions legitimize individual identity. Additionally, the >>>> Institutional Web of Trust established by The Trust Nexus will have >>>> centralized controller processes that rely greatly on self-management and >>>> automation resulting in great efficiencies. >>>> >>>> Digital wallets on NFC enabled smart phones will enable users to secure >>>> their private keys and control/present their digital credentials. Because a >>>> user's identity will be authenticated by the processes of The Trust Nexus >>>> (not a trust authority) there is no need for a trust authority to issue and >>>> vouch for public/private keys for individual users. It is only necessary >>>> that the public key be registered and the private key be secured. Users can >>>> self-issue their keys. >>>> >>>> The Trust Nexus does not secure identity by, "making personal data harder to >>>> steal". Rather, identity is secured by self-managing logical >>>> inconsistencies within the system, resolving identity conflicts and >>>> preventing fraudulent transactions. >>>> >>>> As Bruce Schneier, author and security guru, pointed out, "Proposed >>>> [identity theft] fixes tend to concentrate on the first issue--making >>>> personal data harder to steal--whereas the real problem is the second >>>> [preventing fraudulent transactions]. If we're ever going to manage the >>>> risks and effects of electronic impersonation [identity theft], we must >>>> concentrate on preventing and detecting fraudulent transactions." [Solving >>>> Identity Theft] >>>> >>>> In essence, there are a limited number of institutions worldwide (measured >>>> in thousands) that truly matter when it comes to legitimizing identity. >>>> Digital wallets on smart phones will enable the efficient association of >>>> unique public/private keys to a specific legal identity (legal name and >>>> legal address). If there is a non-unique association, an inconsistency >>>> arises in the system. If the association is unique and verified by one or >>>> more legitimate institutions an individual's identity is secure (as long as >>>> the private key which he/she controls is secure). >>>> >>>> In the process of adding a credential to a user's digital wallet, the >>>> provisioning institution (government agency, bank, university, etc.) will >>>> calculate a secure hash value (numerical representation) of the credential >>>> combined with information from the user's primary credential (legal >>>> identity). This hash value will be encrypted with the user's private key >>>> and then encrypted again with the provisioning institution's private key; >>>> this encrypted hash value will then be stored in The Trust Nexus Repository >>>> representing an institutional validation of the user's identity. >>>> >>>> This dual encryption establishes that the credential was associated with the >>>> user during the provisioning process rather than simply asserting the >>>> association by a reference from the repository. Also, There is no need to >>>> store any specific information (account number, balance, etc.) about user's >>>> account. The user is in complete control of the information he/she presents >>>> and his/her privacy is maintained. >>>> >>>> When a user presents a credential from his/her digital wallet a transaction >>>> ID will be sent from the authenticating system to the user's digital wallet, >>>> be encrypted with the user's private key and sent back to the authenticating >>>> system. The user can be authenticated by decrypting the transaction ID with >>>> the user's public key from The Trust Nexus Repository. The credential can be >>>> authenticated by calculating the hash value of the credential and then >>>> decrypting the hash value stored in The Trust Nexus Repository with the >>>> institution's public key and the user's public key. >>>> >>>> In a variation of this process the provisioning institution does not store >>>> the encrypted hash value in The Trust Nexus Repository; rather, the >>>> provisioning institution itself maintains a repository and a reference to >>>> the repository is authenticated by an entry contained within The Trust Nexus >>>> Repository (through the institution's primary credential). In this way an >>>> institution could federate the identity of it's users (or a subset of its >>>> users) simply by adding (or modifying) a credential to each of it's user's >>>> digital wallets and creating an institutional reference within The Trust >>>> Nexus Repository. >>>> >>>> As part of the federation process, cooperating institutions will most likely >>>> create standard authorization levels for various services and provision >>>> these levels as part of a user's credential. For example, a coalition of >>>> universities may have authorization levels for library services that will >>>> enable users to access any library within the coalition; government >>>> organizations may provision security levels within a user's credential that >>>> enable inter-agency access to resources; etc. >>>> >>>> There is significant debate regarding the effectiveness of biometrics in >>>> identity management. When a user is not present (authenticating over a >>>> network) there are fatal problems with biometric authentication. Most >>>> significantly, "The main security problem with biometrics is the inability >>>> to create a new secret. If you allow your fingerprint to be digitized and >>>> sent across a network or scanned by a compromised scanner, it can be stolen. >>>> Then someone has a digital copy of your fingerprint." >>>> >>>> Even if a method of biometric identification proved to be completely >>>> reliable, security issues would still remain. There would be opportunities >>>> to steal someone's biometric signature and forge their identity credentials, >>>> especially if there was a massive store of private personal data; one >>>> successful attack could essentially render the entire system ineffective. >>>> >>>> When a user is present bio-metric data can be an effective authenticator. >>>> It will be possible to store bio-metric data within a user's credential (not >>>> within a central repository) when the credential is created by the >>>> provisioning institution. When a user presents the credential verifying the >>>> biometric data in the credential against the individual in real time will >>>> provide enhanced security along with verifying the encrypted transaction >>>> code against the user's public key in The Trust Nexus Repository and >>>> verifying the encrypted hash code of the credential against The Trust Nexus >>>> Repository. >>>> >>>> While there are many types of biometric identifiers, one of the simplest and >>>> most usable is a photograph of the human face verified by a human being. >>>> Any credential in a user's digital wallet that includes a photograph >>>> (driver's license, passport, bank debit card, etc.) will be highly reliable >>>> when a user presents the credential in person. >>>> >>>> Why would a major institution (bank, university, corporation, government >>>> agency, etc.) utilize The Trust Nexus Repository instead of its own internal >>>> system? When there is no need for an external third party to rely on a >>>> user's credential an institution may very well utilize its own internal >>>> repository. In this same case, smaller institutions, for reasons of >>>> convenience and cost, might still utilize The Trust Nexus Repository. >>>> >>>> Whenever a third party (a party other than the provisioning institution) >>>> must relay on a user's credential, the key services The Trust Nexus >>>> Repository provides are assurance that the user is unique and trustworthy, >>>> assurance that the provisioning institution is unique and trustworthy and >>>> assurance that the credential is trustworthy. Also, The Trust Nexus >>>> Repository creates a "data synergy effect" which establishes an >>>> Institutional Web of Trust (when multiple institutions validate a unique >>>> user's identity the identity becomes more secure and trustworthy). >>>> >>>> If a unique user has digital credentials for a state driver's license, a >>>> passport, a bank debit card, a university ID, insurance cards, credit cards, >>>> etc., all independently validated by trustworthy institutions, that user's >>>> identity is secure and highly trustworthy. Similar to credit ratings, both >>>> individuals and institutions will have "trust ratings" within The Trust >>>> Nexus Repository. A centralized notification service will also be provided >>>> when credentials are lost or stolen. >>>> >>>> The uniqueness test for legal identities within The Trust Nexus Repository >>>> helps to secure identity and prevent identity theft. If there is a >>>> non-unique association, an inconsistency arises in the system. Also, easy >>>> access for online status checking establishes the currency of a user's >>>> credentials in case the user's digital wallet is lost or stolen. And most >>>> importantly, The Trust Nexus creates a "data synergy effect" which >>>> establishes an Institutional Web of Trust. >>>> >>>> Additionally, our system provides the "Holy Grail" for single sign on. All >>>> computers will soon have an interface (USB plugin or internal card) that >>>> will enable NFC interactions with mobile devices. The digital wallet on a >>>> user's cell phone will be provisioned with credentials containing specified >>>> authorizations different systems and services. Rather than logging into a >>>> directory or utilizing a complex federated identity process, a user will log >>>> onto his/her cell phone with a PIN and a voice authentication signature. The >>>> user (or the authenticating system) will then select the appropriate >>>> credential for the specified system or service with no need to enter another >>>> user name or password (the user's private key will be used to encrypt a >>>> transaction ID). This approach also solves the "Keys to the Kingdom" problem >>>> where a single sign on to a directory service opens access to all the user's >>>> systems and services. >>>> >>>> We are confident we have a transforming technology and a clear vision of the >>>> future. No one has found a conceptual flaw in the system. Existing >>>> providers of identity management services should not see The Trust Nexus as >>>> a competitor; rather, they should see us as an infrastructure provider >>>> (similar to the electric power grid that has hundreds of energy providers). >>>> >>>> Best regards, >>>> >>>> Michael Duffy >>>> CEO / CTO ~ The Trust Nexus >>>> http://www.thetrustnexus.com <http://www.thetrustnexus.com/> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Community mailing list >>>> Community(a)kantarainitiative.org <mailto:Community@kantarainitiative.org> >>>> http://kantarainitiative.org/mailman/listinfo/community >>>> >>>> >>>> >>> _______________________________________________ >>> Community mailing list >>> Community(a)kantarainitiative.org <mailto:Community@kantarainitiative.org> >>> http://kantarainitiative.org/mailman/listinfo/community >>> _______________________________________________ >>> Community mailing list >>> Community(a)kantarainitiative.org <mailto:Community@kantarainitiative.org> >>> http://kantarainitiative.org/mailman/listinfo/community >>> >>> >> >> _______________________________________________ >> Community mailing list >> Community(a)kantarainitiative.org >> <mailto:Community@kantarainitiative.org> >> http://kantarainitiative.org/mailman/listinfo/community >> >> >> >> >> -- >> Joni Brennan >> IEEE-ISTO >> Kantara Initiative >> Program Director >> voice:+1 732-226-4223 >> email: joni @ ieee-isto.org <http://ieee-isto.org/> >> gtalk: jonibrennan >> skype: upon request >> >> Join the conversation on the community@ list - >> http://kantarainitiative.org/mailman/listinfo/community >> >> >> _______________________________________________ >> Community mailing list >> Community(a)kantarainitiative.org <mailto:Community@kantarainitiative.org> >> http://kantarainitiative.org/mailman/listinfo/community >

1 0

Brett McDowell
by Roger Sullivan 28 Jan '10

28 Jan '10

Colleagues, It is with very mixed emotions that I inform you that Brett McDowell is resigning as Executive Director of Kantara Initiative as of February 10th to pursue another (great) employment opportunity. We are truly sad to see him go with all that he has contributed to both Liberty Alliance and Kantara Initiative over these past many years. Unceasingly positive, unfailingly energetic, and a walking encyclopedia about the Identity space, he has made our lives so much better for having walked (raced) with us on this journey. But, we are genuinely happy for him in this new opportunity and are confident that Brett will do very well indeed. Brett, on behalf of all of your friends at Kantara Initiative and beyond, congratulations and good fortune with your new adventure and thank you most sincerely for what you've done for us. Needless to say, we are looking for a new Executive Director for Kantara Initiative. The Board of Trustees has established a search committee to fill the position. If you or someone you know might be interested, please inquire at: HYPERLINK "mailto:ksearch@elists.isoc.org"ksearch(a)elists.isoc.org Best regards, -- HYPERLINK "http://www.oracle.com/" \nOracle Roger Sullivan | Vice President Phone: +1 781 744 0767 | Mobile: +1 978 828 3520 Oracle Identity Management 10 Van de Graaff Drive | Burlington, MA 01803 HYPERLINK "http://www.oracle.com/commitment" \nGreen Oracle Oracle is committed to developing practices and products that help protect the environment

2 1

Kantara Initiative Conference - March 9-11, 2010 in Oregon, USA
by Dervla O'Reilly 25 Jan '10

25 Jan '10

We look forward to you joining us for the second Kantara Initiative Conference, Tuesday-Thursday, March 9-11. Thanks again to Intel Corporation for hosting at their Hillsboro, Oregon campus. Early-bird registration is $195USD until Feb. 12, then $250 thereafter until March 9. Event information is available at our conference page - review the agenda, maps and nearby hotel details. We have a great rate per night for $105USD at the SpringHill Suites by Marriott - review the discount code details at our conference page We invite you to sign up for our open-for-all dinner is Wednesday, March 10, 6:45-8:15pm at Portland's Oba Restaurant. The price for the 3-course dinner including one beverage is $45USD. Please let me know if any questions regarding the Conference. Cheers, Dervla ________________________ Dervla O’Reilly Program Manager Kantara Initiative +1 415 731 4487 business +1 415 948 3650 mobile +1 509 757 4487 fax dervla[at]kantarainitiative.org http://www.kantarainitiative.org Register for Kantara's annual workshop March 1, 2010 at the RSA Conference free of charge - http://bit.ly/8rPWVM

1 0

UMA Webinar - Making the world safe for User-Managed Access, Jan 29, 8-9:30am PST
by Dervla O'Reilly 22 Jan '10

22 Jan '10

We invite you to join us for a UMA Webinar - Making the world safe for User-Managed Access on Jan. 29, 8-9:30am PST. To benefit from the increasing number of services accessible over the Web, we're forced to "hand over the data" -- data that's sensitive, valuable, and personal -- and we end up paying a price in both privacy and convenience. The new User-Managed Access web protocol promises to help web users share their data more selectively using a central digital footprint dashboard, while helping websites get access to fresher and better-quality data when they need it. This session will review UMA benefits, progress to date, and next steps. Register here: https://ieee-isto.webex.com/ieee-isto/j.php?ED=118302377&RG=1&UID=105807765… Note that a maximum of 25 participants is allowed for this webinar, therefore a first-come, first-serve basis for registration. Please feel free to invite colleagues and friends. If questions, please contact dervla (at) kantarainitiative (dot) org ________________________ Dervla O’Reilly Program Manager Kantara Initiative +1 415 731 4487 business +1 415 948 3650 mobile +1 509 757 4487 fax dervla[at]kantarainitiative.org http://www.kantarainitiative.org Register for Kantara's annual workshop March 1, 2010 at the RSA Conference free of charge - http://bit.ly/8rPWVM

1 0

Eve Maler presenting User-Managed Access update to LC
by J. Trent Adams 18 Jan '10

18 Jan '10

All - For those interested in the work taking place in the User-Managed Access (UMA) Work Group [1], Eve Maler will be presenting an update to the Leadership Council this week: * Date: Wednesday, January 20, 2010 * Time: 4pm PST | 7pm EST * Teleconference Options: o Skype: +9900827043671716 o US Dial-In: +1-201-793-9022 | Room Code: 3671716 This update will take place during the last 30 minutes of the regular LC teleconference (which starts one hour earlier at 3pm PST). We hope to be able to record this update and make it available via the Identity Community Update DG as an MP3, in case you're unable to attend. This is a great opportunity for you to catch up with the UMA work in case you've been unable to keep up with their fast pace. See you then, Trent [1] http://kantarainitiative.org/confluence/display/uma/ -- J. Trent Adams =jtrentadams Outreach Specialist, Trust & Identity Internet Society http://www.isoc.org e) adams(a)isoc.org o) 703-439-2149

2 1

Concordia DG Surveys on Assurance & Authorization
by Paul Madsen 15 Jan '10

15 Jan '10

All, the Concordia DG has created 2 short (~ 10 questions) surveys around assurance & authorization issues. Authorization is one of the hottest topics in computing security today. Great strides have been made in the area of authentication, but the ultimate purpose of authentication is to provide input to authorization decisions. Security product vendors are offering packages that can serve as centralized authorization systems, or Policy Decision Points (PDPs) and Policy Enforcement Points (PEPs) in XACML parlance. These products generally offer integration kits for various applications and platforms. Many organizations have or are beginning to architect XACML-based, logically-centralized authorization systems. The purpose of this survey is to generate data about both the business and technical drivers for authorization in the enterprise today. http://www.surveymonkey.com/s/authz_survey More and more, industries & governments are choosing a 'Level of Assurance' (LOA) model as a means to provide federation partners appropriate confidence in identity data received from external 3rd parties. But is the LOA model the only possible mechanism? This survey is intended to tease out real requirements of federated participants - perhaps answering this question. http://www.surveymonkey.com/s/outsourced_id_data Please consider taking the surveys yourself, and/or spread the word to partners, colleagues, etc not involved in KI. Regards Paul Madsen & Tatsuki Sakushima Co-Chairs - Concordia DG

1 0

Fwd: OIF RFI Package
by Brett McDowell 14 Jan '10

14 Jan '10

I'd like to publicly thank Don Thibeau, Drummond Reed and the members of the OIF JSC for including Kantara Initiative in their outreach. Don has already made the attached RFI package public over on the OIDF mailing lists but since I've started getting questions from members of Kantara Initiative asking to see the RFI package I realized I need to explicitly share it with our community since many of you are not subscribed to OIDF lists. As I reported to Don, my next step is to discuss this with the Assurance Review Board, the oversight body for our Identity Assurance Accreditation and Certification Program. If you have ideas, comments, recommendations, questions, or concerns please send them to me directly, or to this public mailing list, or to the ARB(a)kantarainitiative.org mailing list (depending on the level of disclosure you are comfortable with) -- and, yes ARB@ has SPAM controls so your message will go in queue momentarily, but it will be pushed through quickly. Note that due to the nature of the ARB being the deliberative body deciding who passes or fails accreditation and certification applications, they operate under terms of confidentiality and they will honor any request you have to keep your comments confidential if you call that out explicitly in your email. As a reminder, the ARB is comprised of representatives from Aetna, BT, GSA, KPMG, and SUNET. Thank you in advance for contributing to the process. Brett McDowell | http://info.brettmcdowell.com | http://KantaraInitiative.org Begin forwarded message: > From: "Don Thibeau $OIDF ED$" <don(a)oidf.org> > Date: November 22, 2009 7:05:44 PM EST > To: "'Brett McDowell'" <email(a)brettmcdowell.com> > Subject: OIF RFI Package > > Dear Brett: > Thanks for your interest in working with the OpenID and Information Card Foundations. Here is the latest chapter in our conversations that began in last spring. > Since March of this year, the OpenID and the Information Card Foundations have collaborated on responding to US Government request to participate in its “Open Identity for Open Government Initiative.” Together with Kantara and InCommon, we have contributed to the development of the U.S. General Services Administration (GSA) Identity, Credential, and Access Management (ICAM) identity standards and certification requirements. The impact of our work with the government can be seen in the first set of deliverables at www.IDmanagement.gov published in September. As you know, ICAM’s Trust Framework Provider Adoption Process (TFPAP) established a new way to enable citizens to easily and safely engage with government websites, and ICAM’s Identity Scheme Adoption Process (ISAP) laid the techical foundation for government-approved profiles of open identity specifications. ICAM’s profiles for OpenID 2.0 and IMI 1.0 Information Cards profiles we published shortly afterwards. > The OIDF and ICF have been collaborating to develop an open approach to trust frameworks that will meet the needs of our respective communities. Two weeks ago at the OpenID Summit and again in three different sessions at the Internet Identity Workshop (IIW), ICF Executive Director Drummond Reed and I presented this approach to the community at large and asked for feedback, challenges, and contributions. These sessions produced a wealth of invaluable input and a strong concensus that OIDF and ICF should proceed with this approach, which the community dubbed the Open Identity Framework (OIF), as quickly as possible. > Immediately after IIW, the Boards of Directors of OIDF and ICF agreed to form a joint steering committee (JSC) to refine strategic goals, investigate operational alternatives, and guide deployment planning for the OIF. The JSC is composed of four representatives of companies that are members of both foundations and four community representatives, including the Chairs of both foundation boards. > The JSC started by carefully considering the goals and objectives of the Open Identity Framework (OIF) and weighing the tradeoffs between what aspects should be outsourced vs. what aspects were strategic and thus should remain “in-sourced”. The JSC then asked Drummond and I to prepare the attached Request For Information (RFI) to initiate discussions with prospective outsourcing partners. Because the JSC wants to make recommendations to the OIDF and ICF boards and set a course of action by year’s end, it wants to fast-track this RFI review process and expects a report in 30 days. > The attached RFI has two objectives: 1) to solicit your informed collaboration and feedback about how best to achieve the objectives of the OIF, and 2) to identify the potential outsourcing partners with whom we should proceed with more detailed negotiations. We have attached supplemental material that fully describes our approach to the OIF with the hope that it will be of benefit to your plans regardless of whether you decide to respond as a potential outsourcing partner. > The JSC partner selection criteria focuses on cost efficiencies, execution synergies, and compatible business models. You are welcome to provide general feedback as well as respond specifically to any or all of the activities described in the Outsourced Program Elements section. For needs in that section where you feel your organization would be a good outsourcing fit, please be specific as to how you would fulfill those needs. Please include pricing estimates broken out for each outsourced program element—the more detailed the better. > Please note that the OIDF and ICF reserve the right to change the timeline or other portions of this RFI at any time, as well as to cancel or reissue the RFI at any time without obligation or liability. Also, please designate any information contained in your response that is proprietary or confidential. While we will we will treat the material provided as business confidential, please note that both the OIDF and ICF operate in a transparent, open source business environment, so some commentary, discussion, or speculation may occur on mailing groups, blog posts etc. > Please email your response as a word document attachment to don(a)oidf.org before midnight EDT on 12/01/09. Of course, feel free to contact either Drummond or myself with questions, and we would be happy to arrange telecons or in-person meeting to discuss it as time permits. > Thank you again for your interest. > Don Thibeau > don(a)OIDF.org > Executive Director > The OpenID Foundation > http://openid.net

2 6

Kantara Initiative Workshop at RSA Conference, March 1 2010
by Dervla O'Reilly 14 Jan '10

14 Jan '10

We invite you to join us for our annual workshop at the RSA Conference March 1, 8am-5pm. This free workshop will showcase deployers and providers showing why distributed applications are poised for Internet- scale adoption. Gain state-of-identity insight through a series of presentations, panels and demonstrations of common Cloud/SaaS scenarios from diverse market leaders. We encourage our Bay area community to join us at the Moscone Center, San Francisco. You can review the agenda here: http://kantarainitiative.org/confluence/display/GI/Kantara+Initiative+Works… Sign up for our free workshop here: http://www.emc.com/microsites/rsa-conference/2010/usa/registration-and-rate… . Please use the code: 1310KANEXPO for the Expo only pass and select Kantara Initiative from the 'Registration Package' page. This pass only allows access to Kantara Initiative workshop on March 1. Read details about the Conference events March 1-5 here: http://www.rsaconference.com/2010/usa/discount/prospects.htm?gclid=CLaTn4-n… We look forward to seeing you there. Dervla ________________________ Dervla O’Reilly Program Manager Kantara Initiative +1 415 731 4487 business +1 415 948 3650 mobile +1 509 757 4487 fax dervla[at]kantarainitiative.org http://www.kantarainitiative.org Read the current Kantara Initiative newsletter - http://bit.ly/4IxsnK

1 0