Home Overview Future Potential FAQ Protocols Test Contact License
All those who are committed to federation technologies are like engineers in the 1890s working diligently to perfect the telegraph system; all their work will soon be eclipsed by a much better technology.
New Computer First Time Sign On >>> - page 1 - page 2 - page 3 -  
This is an incredibly simple one time process.
When a user signs on from a new computer for the first time he/she will see the
"TNX Secure Sign On ~ Initialize" page.
The user simply enters his/her email address and is transferred to the
"TNX One Touch Sign On" page.
In the background, the web browser contacts the server, gets the user's "userUuid", screenName" and stores these values along with the contactEmail" in cookies.
The authentication process takes place between the TNX One Touch Mobile App, and the servers within the TNX Secure Web Application not within the browser.  There is no danger that a "bad actor" could enter a user's contact email address and sign on from a random web page.
One Touch Sign On
Under the Trust Nexus it is possible for a user to touch one icon on his/her TNX One Touch Mobile App and securely authenticate to a web or mobile application.
When a user signs on to a new computer for the first time the user's "userUuid" along with the user's "screenName" and "contactEmail" address are stored as cookie values in the Internet browser.  When a user returns to the web application he/she sees the following message:
The user simply scrolls to the appropriate credential and touches the icon.
The user is notified, "Sign On Successful", and a, "Verification Code: DZG 422", is also displayed for the user in both the mobile app and the web browser.
When a user goes to the One Touch Sign On page in his/her web browser an asynchronous process is launched that reads the "userUuid" from a cookie value (initially set in the credential creation or initialization process).  This value is sent to the credential provider's server where a data base record is created.  This record contains the "userUuid" and a newly created "sessionUuid".  A check is also made to insure there are not duplicate sessions from the same user; this insures that a "bad actor" cannot hijack a valid user's session simply by manipulating the cookies on another computer.
An asynchronous process from the user's web browser then polls the credential provider's server every five seconds (configurable) and "asks" the question, "Has this user been authenticated?"  If the answer is yes, the "verificationCode" (created in the TNX One Touch Mobile App) is transmitted to the browser and displayed with a welcome message.
When a user touches the appropriate identity credential icon in the TNX One Touch Mobile App, the following information is sent to a server in the credentialProvider's infrastructure:
  • "userUuid"
  • "transactionUuid"
  • "transactionUuidSigned"
  • "verificationCode"
A "verificationCode" is generated by TNX One Touch Mobile App for each authentication.  This code is simply a visual cue for the user (displayed both in the mobile app and the web browser).  The "sessionUuid", transmitted securely from the credential provider's server to the user's web browser, provides the security check for a secure session.
The user's "transactionUuidSigned" is verified using the user's public key.  The only way the "transactionUuidSigned" can be verified is if it was created with the user's private key.  This process insures that when the user presents the credential (either in person or over the network) the receiver can be certain that either the credential and the user are valid or the user gave his/her mobile device and six digit HEX pin (1/16,777,216) to someone else.
It may seem that the Text Code Sign On process which requires a user to enter a code into his/her mobile device is much more secure than the One Touch Sign On process.  Mathematically, this is not the case; however, from a marketing standpoint the appearance of entering a code seems more secure.
In the Text Code Sign On process, the asynchronous process from the user's web page does a discovery against a combination of three factors:
  • "userUuid"
  • "sessionUuid"
  • "authenticationCode"
In the One Touch Sign On process, the asynchronous process from the user's web page does not include an "authenticationCode" in the discovery.
In most cases the "authenticationCode" will be a four character string (e.g., "HQWK") which has 331,776 possible combinations (all upper case, eliminate "I" and "O").  An eight character string (e.g., "HQWK GPIM"; which is probably the limit for user convenience) has 110,075,314,176 possible combinations; however, in comparison to a UUID, 110 billion is trivial.
A UUID is represented by 32 hexadecimal digits (e.g., 550e8400-e29b-41d4-a716-446655440000).  The number of possible UUIDS is 340,282,366,920,938,463,463,374,607,431,768,211,456 (16^32).  The discovery process is already protected by a UUID (session ID) so adding a four or eight character string does not enhance security to a great degree.  Also, the discovery process communication takes place over a secure SSL/TLS connection which means the values cannot be intercepted by a "man in the middle attack".  In the final analysis, the security of the authentication process comes from the "transactionUuidSigned" which depends on the user's private key not on any of the codes or IDs used in the discovery process.
The flow chart below provides an overview of the One Touch Sign On process.
Downloading a Three Party Credential
The key difference between creating an identity credential and downloading a three party credential (e.g., drivers licenses, passports, financial credentials, insurance credentials, etc.) is that in creating an identity credential most information is uploaded to the credentialProvider while in downloading a three party credential most information is downloaded from the credentialProvider.
Similar to creating an identity credential, the first step in downloading a three party credential is to enter the "authenticationCode".
Prior to sending the request data to the credential provider, the TNX One Touch Mobile App makes a request to the TNX Secure Web Application for a "transactionUuid".  The TNX Secure Web Application records the request, associating the "userUuid" with the "transactionUuid" then sends the "transactionUuid" to the TNX One Touch Mobile App.
Along with the requested data the TNX One Touch Mobile App sends the credential provider the "transactionUuid" signed with the user's private key.  Once the data is received, the credential provider requests the user's recently recorded "transactionUuid" and public key from the TNX Secure Web Application.  The credential provider can then check the signature of the "transactionUuid".  If the "transactionUuid" is valid and the signature is valid the credential provider can be certain that a user associated with the given "userUuid" has sent the request data.
The credential provider will have a process that insures the request to down load the credential is valid.  This process will include both a secure method for sending the user the "authenticationCode" and a check against the information uploaded by the user.
The process for "Creating an Identity Credential" can also be applied in a secure setting where identity is verified (e.g., the issuance of corporate identity credentials at a security station or the issuance of financial credentials at a bank).  This secure "identity proofing" represents a high level institutional validation.  Within the Trust Nexus the user's identity is verified in a valid institutional process determined by the institution issuing the credential.
The NFC capabilities of mobile devices will enable a seamless process with no need for "authenticationCodes" in the process of Downloading a Three Party Credential at a physical location ("Touch and go. Your credential has been provisioned.").
Additionally, under the Trust Nexus once a financial institution has provisioned a credential to a user's mobile device in a valid institutional process, the user can conduct secure financial transactions without revealing any information about the details of the financial credential or the user.  Through secure cryptographic processes the user's mobile device will receive the transaction details from the seller's web application (or retail POS terminal).  The user's financial credential UUID will be added to these transaction details which will be cryptographically signed with the user's private key and returned to the seller's web application.  The seller's web application verifies the data packet, signs the data packet with the seller's private key and sends the data packet, the user's signature block and the seller's signature block to the payment processor.  The payment processor verifies both signature blocks (with public keys on file) then sends the information to the financial institutions to processes the debits/credits.
When a financial institution receives a request for payment containing the data packet (which includes the user's financial credential UUID) and the user's signature block, the financial institution can easily verify the the legitimacy of the request because the financial institution created the original financial credential UUID (and the association with the user's UUID and public key) when the credential was provisioned to the user's mobile device in a valid institutional process.
When everything is done and the seller receives payment, the seller only knows that there is an association between the user's financial credential UUID and the user's public key.  All other information could remain private at the user's discretion.  The fact that the user's private key is secured on his/her mobile device and that the financial credential was provisioned in a valid institutional process, means that the seller, payment processor and financial institution can be certain that the financial credential and the user are valid or the user gave his/her mobile device and six digit HEX pin (1/16,777,216) to someone else.
Maintaining the associations ("users/credentials/public keys"; "sellers/financial accounts/public keys") will be the essential functionality of a worldwide identity infrastructure for financial transactions and other three party credentials (driver's licenses, passports, insurance credentials, etc.).  Paradoxically, this worldwide identity infrastructure will contain no personal data.
Authenticating a Three Party Credential
How is it possible for a third party to trust a credential issued by a credential provider to a user?
When a financial credential or other three party credential is created, it is treated as an unalterable uniform block of data within the Trust Nexus.  This block of data consists of "name/value" pairs describing the attributes of the credential.  When the credential is downloaded to the TNX One Touch Mobile App it is encrypted as a uniform block with the user's "userSecurityKey" and stored securely.  When the credential is needed it is decrypted and transmitted as a uniform block of data.
Prior to downloading the credential to the user, the credential provider creates an SHA-512 message digest of the data block.  This digest is signed with the credential provider's private key; that signature, along with other credential data is stored within the TNX Secure Web Application.
When the TNX One Touch Mobile App first receives a credential it creates an SHA-512 message digest of the data block.  This digest is signed with the user's private key; that signature, along with other credential data is stored within the TNX Secure Web Application.
This dual signature of the credential data enables a third party to trust the process under which the credential was created.
We expect the TNX Secure Web Application to be a network of "identity/financial" grids that will be run in cooperation with governments worldwide.  Any organization that provides three party credential will register the signatures of these credentials with the TNX Secure Web Application (the most likely scenario is that credential providers will fully utilize the services of the TNX Secure Web Application).
When a third party receives the credential the message digest can be recalculated and the signatures of the credential provider and the user can be validated.  With validation of the signatures the third party can be confident that the credential is valid.
When a third party receives the credential the third party also receives a "transactionUuid" signed with the user's private key.  If this signature can also be validated with the public key associated with the "userUuid" the third party can be confident that the user presenting the credential is the same user who created the credential.
Within each credential there is an attribute for "trustLevel".  The exact specifications for these levels will be determined at a later date.  "Level 0" might be a web based provisioning process; "Level 1" might be some type of out of band provisioning process; "Level 2" might be an in person provisioning process; etc.
When a three party credential is provisioned to a user, especially when the provisioning process involves a very high "trustLevel" (e.g, provisioned in person by the user's personal banker of twenty years), that credential represents an Institutional Validation of the user's identity.  A collection of these validations represents an Institutional Web of Trust which establishes and secures a user's identity.
Within the Trust Nexus if another institution, say the IRS, wanted to rely on a user's bank credential as proof of the user's identity, it would simply check the credential's signed SHA-512 message digest against the user's public key and the bank's public key.  The IRS would also check a transaction UUID that had been signed with the user's private key insuring that the user presenting the credential is the same user who created the credential.
This would be a one time process for the IRS.  Once this process is complete there would be an IRS credential provisioned to the user's mobile device which would only need to interact with the IRS's authentication system for all future authentications (no repeated reliance on trusted third parties).  In a very consumer friendly process the user would be able to touch the IRS credential icon on his/her mobile device and be securely signed on to the IRS's website or mobile application.  
This process will form the foundation of a reprovisiong process if a user's mobile device is ever lost or stolen.  The user would go through a high level identity proofing for an "uber" credential (bank credential, passport, driver's license, etc.) once that credential is provisioned other credentials could rely on that credential for reprovisioning.  
Current Approaches to Federation
The current standard for federated identity is the Security Assertion Markup Language (SAML). 
"The Security Assertion Markup Language (SAML) is an XML-based open standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. SAML is a product of the OASIS Security Services Technical Committee. SAML dates from 2001; the most recent update of SAML is from 2005." [ref]
The primary SAML use case for Web Browser Single Sign-On (SSO) is non-trivial:

The page count for the SAML V2.0 specification documents exceeds four-hundred pages.  As one system administrator stated in his blog, "SAML is like building a mini nuclear reactor to power a light bulb in your office."
The Shibboleth project provides a reference implementation for SAML.  Shibboleth began as an "Internet2 Middleware activity" in 2000.  The project contains seven components, each with its own extensive documentation and code resources.
Even if the SAML approach to federation was not complex, it is highly problematic that business organizations would be willing to outsource their customer identities to an "Identity Provider".  Customer identities are the "Crown Jewels" for most businesses.
The following can be stated as an axiom: Unless there is a high degree of collaboration, organizations will be unwilling to federate their identity systems.
SAML has achieved its greatest success within the academic community (most notably with the InCommon trust framework).  This makes perfect sense because the academic community is a highly collaborative community unfettered by the constraints of economic competition.
Even within the government it is highly unlikely that agencies that depend on high levels of security will be willing to federate their identity.  Will the military, the FBI, the NSA, etc. be willing to externalize their authentication?
There are currently two primary alternatives to SAML for federation and single sign on:  OpenId and OAuth.  Both have significant problems.
OpenID Connect is an attempt by some to solve the problems of OpenId and OAuth. 
"OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol.  It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner...  OpenID Connect performs many of the same tasks as OpenID 2.0, but does so in a way that is API-friendly." [ref]
Will it be possible to create a simplified and elegant process out of a conglomeration of two bad protocols?  It seems unlikely.
In all the existing federation processes the user experience is similar:  The user goes to an authentication page and selects from a list of identity providers.  The user is then passed to the identity provider's authentication page where he/she enters his/her user name and password.  This process establishes a single point of failure.  If a bad actor can obtain a user's username and password the bad actor can access all the user's accounts ("keys to the kingdom" attack scenario). 
The major problem with OpenID Connect and other single-sign-on protocols is that identity proofing is delegated to a third party.  Will any organization concerned with security delegate its identity proofing process to a third party like Facebook? 
Taking responsibility for identity proofing is a key competitive advantage for most business organizations; and their consumer data represents the "crown jewels" for most business organizations.  That is why no financial institution has ever allowed access to its systems through OpenID Connect or any of the other of the SSO schemes.  That is why Amazon, Facebook, Google, Yahoo and other major providers of Internet goods and services will gladly provide an OpenID Connect service based on their users signing into other services (providing more consumer data points to the SSO service provider) but would never allow their applications to be accessed through another SSO provider.
With increased complexity comes increased costs.  Are the benefits of implementing any single sign on (SSO) protocol worth the costs?  Do most organizations really care about single sign on (SSO)? 
Most of the federation protocols have their roots in the early 2000s when users first started to struggle with multiple usernames and passwords.  The single sign on (SSO) problem is very different from the problem of secure authentication.  Will organizations be willing to implement complex and costly protocols to solve a problem that is not their main concern?  Stated emphatically:  Most organizations do not care about the single sign on (SSO) problem; they care about secure authentication.
All those who are committed to federation technologies and single sign on are like engineers in the 1890s working diligently to perfect the telegraph system; all their work will soon be eclipsed by a much better technology.
Simplified Federation
The Trust Nexus provides a greatly simplified approach to federation for organizations that wish to collaborate.
There are three key components in the process of Federated Identity:
  • Identity Proofing
  • Authentication
  • Authorization
Participants in a federated identity system are trusting that someone else has done the due diligence in proofing a user's identity.  They are also trusting that the authentication process is valid.  In most cases participants must also establish some prearranged agreement regarding authorization (what the user is allowed to do).
Assume that The Ohio State University, the University of Texas and the University of Colorado want to enable their students to access digital research archives from all three universities.
Mike, a student at the University of Texas simply goes to The Ohio State University authentication web page.  Because he does not have a cookie value on his system for OSU, the Initialize page is displayed.
Because Mike does not have a credential with OSU the Create Credential page is displayed.  The create credential process is identical to every other credential Mike has created.
From the credential provider's viewpoint (OSU) the only difference between creating a standard credential and creating a federated credential is that the new credential provider (OSU) will make a simple REST call to a credential provider (UT) in the federation or to an agreed upon federation server where essential user information is shared.  The REST call will return a "transactionUuidSigned" by the user's credential provider (UT) and also return a data package (user profile, public key, etc.) regarding the user associated with the email address.
If the user's mobile device returns a valid "transactionUuidSigned" by his/her private key than the new credential provider (OSU) can be certain that the user has gone through an identity proofing process with UT.
Once the credential has been issued the user can authenticate to OSU's system through the "One Touch Sign On"™ process just like any other digital credential. 
Once the credential has been issued, in all future authentications OSU will most likely make a REST call to UT to insure the user still has a valid credential. 
Authorization information (what the user is allowed to do) can be returned in the initial REST call or during subsequent authentications.
Utilizing signatures by private keys secured to a user's mobile device is a far more secure process than having a user select an identity provider and enter user name / password values.
Reestablishing Credentials
What happens if a user looses his/her mobile device containing all his/her digital credentials?
Many credential providers will have their own "out of band" process for reestablishing a credential.  For example, a bank may require users to come into their branch office and have their identity verified in person; the department of motor vehicles will most likely do the same.  The State Department may set up a system where digital passports can be issued/re-issued at a local post office.  Application providers with relatively low security needs (Netflix, Facebook, GMail, etc.) may rely on credentials from organizations providing high level institutional validations (e.g., if a user has a new digital credential issued by a bank with the same legal address and phone number as his/her existing Netflix account then a new credential can also be issued from Netflix).
The Trust Nexus opens up several new possibilities for reestablishing credentials.
The Trust Nexus enables secure authentication through mobile devices.  Within the Secure Mobile Identity Ecosystem all cybersecurity problems associated with user names and passwords (identity theft, hacking, phishing, fraudulent financial transactions, and other types of online fraud) are eliminated.  Privacy will be protected.  Single sign on will be a reality.  The ecosystem does not require that a federated architecture be imposed on all players.  The ecosystem also enables a greatly simplified (compared to SAML) federation architecture for organizations that wish to collaborate.  The code base for the ecosystem will be open source.
A system is secure if the plans for the system are public, and the bad actors can still not break in.
Final Note: The TNX Cryptographic Protocols will eventually include an Ultra process for storing the user's "userSecurityKey" "somewhere" in a distributed network, perhaps even on another user's mobile device. [ref]
>>> - page 1 - page 2 - page 3 -
© Copyright 2017 ~ Trust Nexus, Inc.
All technologies described here in are "Patent Pending".