The Trust Nexus: Process Flow Diagrams

Hide

All computers will soon have an interface (USB plugin or internal card) that will enable NFC interactions with mobile devices.

Users will "sign on" to their digital wallet on their NFC mobile device. Then credentials from their digital wallet will be used for authentication and authorization (effectively creating a single sign on system without the complexities of a federation process based on SAML).

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.

Step 1: When a user goes to a website to create an account for the first time, her public key, legal name, legal address and cell phone number (her primary identity credential) are sent from her NFC enabled cell phone to the Internet browser running on her computer and then to the website's application server.

Hide

Step 2: The website's credential provisioning system creates a digital credential for the user and calculates a hash value (unique numerical representation) of the credential; both the credential and the hash value are sent to the user's digital wallet.

Hide

Step 3: The user's credential is stored securely in her digital wallet. The hash value is encrypted with her private key and returned to the website's credential provisioning system.

Hide

Step 4: The website's credential provisioning system encrypts the hash value again with its private key and then stores this value in the Trust Nexus Repository.

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. There is no need to store any specific information about the user's account. The user is in complete control of the information she presents and her privacy is maintained.

In some cases the website's credential provisioning system might first check the user's "Identity Trust Score" (similar to a credit score) before provisioning the credential. If a user has several "Level 1 - In Person Authentication" entries in the Trust Nexus Repository, that user will have a very high "Identity Trust Score".

In other cases, some type of "out of band" verification process (e.g., a call to the user's cell phone) may be required.

In theory, if there is never a need for an independent third party to rely on the credentials that it issues, the website could store its own encrypted hash values of the credentials; however, it would then be "out of the loop" if a user's credentials were ever lost or stolen.

Hide

Step 5: A confirmation message is returned to the website's credential provisioning system.

Hide

Step 6: When the user returns to the website's sign on page an identifier key and transaction ID are automatically sent to her digital wallet through an NFC link.

Hide

Step 7: Through the identifier key the correct credential is automatically selected for the user's approval. The transaction ID is encrypted with her private key and along with her credential is sent back to the website through an NFC link.

Hide

Step 8: Through the website's credential system a request is made to the Trust Nexus Repository for the encrypted hash value of the user's credential and the user's public key.

Hide

Step 9: 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 website's public key and the user's public key.

If the two values match the website's credential system can validate that the credential associated with the user's unique legal identity was issued in a valid process by the website itself.

Credentials within the Trust Nexus system can contain biometric identifiers (one of the simplest and most effective biometric identifiers is a photograph of the human face). Authentication can be enhanced by real time verification of biometric identifiers (on line facial recognition, voice print, finger print, vein patterns, etc.). One of the most efficient processes will be an out of band call to the user's cell phones for a voice print authentication.

Hide

Step 1: A corporation (or other organization) contracts with a "Cloud Services" provider. In this process service definitions and authorization levels are agreed upon.

The corporation downloads a provisioning application from the "Cloud Services" provider, enabling the corporation to specify services for its members.

In this process there is no need for the corporation to provide a list of members to the "Cloud Services" provider. Also, the corporation could issue credentials with pseudo-names to hide the identity of its users.

Hide

Step 2: A user signs on to a secure internal network and accesses the corporate portal (the user's identity on this network is secured by the Trust Nexus).

The user is notified that "Cloud Services" are now available and he is given the option to create a credential for "Cloud Services". He clicks "Create".

The corporation's credential provisioning system creates a digital credential for the user for "Cloud Services" (with specified services for his position) and calculates a hash value (unique numerical representation) of the credential; both the credential and the hash value are sent to the user's digital wallet.

Hide

Step 3: The user's credential is stored securely in his digital wallet. The hash value is encrypted with his private key and returned to the corporation's credential provisioning system.

Hide

Step 4: The corporation's credential provisioning system encrypts the hash value again with its private key and then stores this value in the Trust Nexus Repository.

It is very likely a large corporation or institution will create its own repository for storing credentials. Smaller corporations or institutions, for reasons of convenience and cost, will likely utilize the Trust Nexus Repository.

Hide

Step 5: A confirmation message is returned to the corporation's credential provisioning system.

Hide

Step 6: When the user goes to the "Cloud Services" sign on page an identifier key and transaction ID are automatically sent to his digital wallet through an NFC link.

Hide

Step 7: Through the identifier key the correct credential is automatically selected for the user's approval. The transaction ID is encrypted with his private key and along with his credential is sent back to the "Cloud Services" application through an NFC link.

Hide

Step 8: Through the "Cloud Service's" credential system a request is made to the Trust Nexus Repository for the encrypted hash value of the user's credential and the user's public key.

Hide

If the two values match the "Cloud Service's" credential system can validate that the credential associated with the user's unique legal identity was issued in a valid process by the corporation contracting for the "Cloud Service".

Hide

Step 1: A group of universities forms a research consortium and agrees to share documents electronically. In this process document types and authorization levels are agreed upon.

Each of the universities creates an institutional account within the Trust Nexus Repository and downloads a provisioning application, enabling it to create credentials for its students and faculty.

Hide

Step 2: A student signs on to a secure internal network and accesses his university portal (the student's identity on this network is secured by the Trust Nexus).

The student goes to the research consortium page and is notified that "Electronic Document Sharing" with member universities is now available; he is given the option to create a credential for "Electronic Document Sharing". He clicks "Create".

The university's credential provisioning system creates a digital credential for the student for "Electronic Document Sharing" (with specified services determined by his faculty adviser) and calculates a hash value (unique numerical representation) of the credential; both the credential and the hash value are sent to the student's digital wallet.

Hide

Step 3: The student's credential is stored securely in his digital wallet. The hash value is encrypted with his private key and returned to the university's credential provisioning system.

Hide

Step 4: The university's credential provisioning system encrypts the hash value again with its private key and then stores this value in the Trust Nexus Repository.

This dual encryption establishes that the credential was associated with the student during the provisioning process rather than simply asserting the association by a reference from the repository. There is no need to store any specific information about the student's account. The student is in complete control of the information he presents and his privacy is maintained.

Hide

Step 5: A confirmation message is returned to the university's credential provisioning system.

Hide

Step 6: When a student goes to the research consortium page at another university in the consortium an identifier key and transaction ID are automatically sent to his digital wallet through an NFC link.

Hide

Step 7: Through the identifier key the correct credential is automatically selected for the student's approval. The transaction ID is encrypted with his private key and along with his credential (which contains authorizations for document types and levels of service) is sent back to the university application through an NFC link.

Hide

Step 8: Through the university's credential system a request is made to the Trust Nexus Repository for the encrypted hash value of the student's credential and the student's public key.

Hide

Step 9: The student can be authenticated by decrypting the transaction ID with the his 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 provisioning university's public key and the student's public key.

If the two values match the university credential system can validate that the credential associated with the student's unique legal identity was issued in a valid process by his university.

Hide

Step 1: The sender selects his digital debit card from his digital wallet and then selects the integrated option, "Mobile Money Transfer".

The "Mobile Money Transfer" interface is displayed and the sender enters the amount to be sent and the cell phone number of the recipient then clicks send.

Hide

Step 2: The Money Transfer Service Provider receives the request from the sender and then sends a request to the Trust Nexus Repository for the encrypted hash value of the sender's digital debit card, the institution's public key, the sender's public key and the primary identity credential of the recipient (available by phone number).

Hide

Step 3: The Trust Nexus Repository sends the encrypted hash value of the sender's digital debit card, the sender's public key and the primary identity credential of the recipient to the Money Transfer Service Provider.

Hide

Step 4: The Money Transfer Service Provider sends a transaction ID and the primary identity credential of the recipient to the senders digital wallet.

Hide

Step 5: The sender verifies the primary identity credential of the recipient. The transaction ID is encrypted with the sender's private key and is sent sent back to the Money Transfer Service Provider.

Hide

Step 6: The sender can be authenticated by decrypting the transaction ID with the sender'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 sender's public key.

If the two values match the Money Transfer Service Provider can be highly certain that the debit card associated with the sender's unique legal identity has been verified by her bank with a "Level I ~ In-Person Verification".

The Money Transfer Service Provider then sends a request to the sender's bank through the ACH network.

Hide

Step 7: The bank transfers the funds to the Money Transfer Service Provider.

Hide

Step 8: The Money Transfer Service Provider notifies the recipient that the funds are ready for pickup. Along with the notification message, a transaction ID is sent to the recipient's Mobile Money Transfer application in the recipient's digital wallet.

Hide

Step 9: The recipient picks up the funds (either at a physical location or through a digital process; see the next diagram: "Mobile Money Pickup ~ Process Flow").

Hide

Step 10: The sender is notified the funds have been picked up by the recipient.

Hide

Step 1: After receiving notification of a funds transfer, the recipient selects his digital wallet application, then selects the integrated option, "Mobile Money Transfer", then selects his digital debit card (as the account to receive the funds) and then clicks send.

The transaction ID that the recipient received during the notification process is encrypted with the recipient's private key. This encrypted value, along with the recipient's digital debit card is sent to the Money Transfer Service Provider.

Hide

Step 2: The Money Transfer Service Provider receives the request from the recipient and then sends a request to the Trust Nexus Repository for the encrypted hash value of the recipient's digital debit card, the institution's public key and the recipient's public key.

Hide

Step 3: The Trust Nexus Repository sends the encrypted hash value of the recipient's digital debit card, the recipient's public key and the institution's public key to the Money Transfer Service Provider.

Hide

Step 4: The recipient can be authenticated by decrypting the transaction ID with the recipient'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 recipient's public key.

If the two values match the Money Transfer Service Provider can be highly certain that the debit card associated with the recipient's unique legal identity has been verified by his bank with a "Level I ~ In-Person Verification".

The Money Transfer Service Provider then processes a transfer from its holding account to the recipient's bank through the ACH network.

Hide

Step 5: The bank transfers the funds to the recipient's account and sends a notification message to the Money Transfer Service Provider.

Hide

Step 6: The Money Transfer Service Provider sends a notification message to the recipient that the funds have been transferred to his bank account.

Hide

Step 7: When the notification message is accessed by the recipient the Mobile Money Transfer application automatically sends a notification message to the Money Transfer Service Provider.

Hide

Step 8: The Money Transfer Service Provider sends a notification message to the sender that the recipient has acknowledged the transfer of funds.

Hide

Step 9: When the notification message is accessed by the sender the Mobile Money Transfer application automatically sends a notification message to the Money Transfer Service Provider.