| Basic Principles |
>>>
page 1
- page 2 - page 3
- |
 |
| Legal Identify Defined:
Under The
Trust Nexus a legal identity consists of a
"legal name" and an associated "legal address". A legal
identity
is unique for each user and shall be considered the primary
identity credential for each user. |
|
| A user's "legal address" will also be
defined by a geo-referenced location determined by an application on
the user's mobile device. |
|
| The
Trust Nexus will establish additional identity
credentials for a particular purpose (e.g., driver's licenses,
passports, debit cards, credit cards, insurance cards, corporate IDs,
etc.) and non-legal personas
for the purpose of discretion (just as users have "junk" email
addresses, they will have "junk" personas for specific purposes). |
|
| Under The
Trust Nexus a legal identity is established
when a user makes the initial primary claim on that identity.
In the process of establishing a legal identity a Public Key is
associated with the user's legal identity and both are stored in The
Trust Nexus Repository; a Private Key is securely stored in the user's
digital wallet on the user's cell phone. |
|
| The initial establishment of a legal identity and
the creation of public/private keys will be an automatic process that
will be transparent to the user. The
Trust Nexus services will be integrated into the user's
digital wallet which will be activated when a user sets up his/her
account on a new cell phone. 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. |
|
| There are no costs. The
Trust Nexus services will be free to the
consumer. |
|
 |
|
| While the initial setup with the cell phone company
provides a basic identity check (and prevents systemic fraud), whether
or not a claimed legal identity is truly a valid identity is determined
by logical processes and resolutions within The
Trust Nexus. There are no
elaborate bureaucratic methodologies for making an initial claim on a
legal identity or resolving conflicting claims. |
|
| The first user to claim an identity is assumed to
be making a valid claim. This assumption leads to great
efficiencies and makes a world wide system manageable. If
every user's identity had to be verified upon sign up and biometric
information had to be stored, the verification process would require
enormous resources and this process itself would be a focal point for
attacking the security of the system. |
|
| After the initial setup of the digital wallet, when
a user goes to add a new credential (credit card, insurance card, state
driver's license etc.), the issuing institution will have established
procedures (phone calls, in person verification, etc.) depending on the
requirements of the credential. These "Trusted Institutions"
will substantiate a user's claim and establish an institutional web of trust
for valid users. |
|
| The more institutional validations a user has, the
more secure his/her identity will be. It is very likely that
similar to credit ratings, consumers will have trust
ratings measuring the security of their
identity. The
Trust Nexus will manage consumer trust
ratings. |
|
| 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. |
|
|
|
| As a specific example, assume user Bob Smith living
at 123 Main St. in Austin, TX purchases a new NFC enabled cell phone
that is pre-loaded with The Trust Nexus's Digital Wallet. In
the activation process of his cell phone, Bob creates the primary
identity credential for his digital wallet. In this process
Bob's legal identity and his public key are registered with The
Trust Nexus Repository; his private key is stored securely on his cell
phone. |
|
| Because The Trust Nexus
Repository shows that no one else has made a claim on Bob's
legal identity there are no inconsistencies in the system and Bob can
now use his registered identity. |
|
| Bob decides he wants to add his bank's debit card
to his digital wallet. Because his bank maintains a high
level of security, Bob is required to make a trip to his bank in order
to establish his primary debit card in his digital wallet.
His personal banker, who has known Bob for years, asks Bob to place his
cell phone in the NFC docking port of the bank's computer.
The banker approves the addition of Bob's debit card to his digital
wallet. The entire process takes seconds to complete. |
|
| Bob’s banker sees that Bob has not yet added a
photo ID to his digital wallet. The banker suggests that Bob go to the
banks online banking system and add a photo of his choice. A verified
photo ID has been and will continue to be a valid security credential. |
|
| In the process of adding his debit card to Bob's
digital wallet, the bank will calculate a secure hash value (numerical
representation) of the debit card combined with information from Bob's primary
credential (legal identity). This hash value will be
encrypted with Bob's private key and then encrypted again with the
bank's private key; this encrypted hash value is stored in The Trust Nexus
Repository and represents an institutional
validation of the Bob's identity. |
|
| This dual encryption establishes that the debit
card was associated with Bob's primary
credential (legal identity) during the verification process
rather than having the association asserted by a reference from the
repository. Also, there is no need to store any specific
information (account number, balance, etc.) about Bob's
account. Bob is in complete control of the information he
presents and his privacy is maintained. |
|
| When Bob selects his debit card from his digital
wallet a transaction ID will be sent from the authenticating system to
his digital wallet, be encrypted with his private key and sent back to
the authenticating system. Bob can be authenticated by decrypting the
transaction ID with his public key from The
Trust Nexus Repository. The debit card can be authenticated by
calculating the hash value of the debit card and then decrypting the
hash value stored in The Trust Nexus
Repository with the bank's public key and Bob's private
key. If the two values match the merchant can be certain that
the debit card associated with Bob's unique legal identity has been
verified by his bank with a "Level I ~ In-Person Verification". |
|
| Assume Bob also has a credit card with a $5,000
limit that he wishes to add to his digital wallet. He goes to
his computer and places his cell phone in the NFC docking port and logs
onto the website of his credit card company. The system at
the credit card company "sees" that Bob has already completed a Level I
verification with his bank so they place a call to Bob's cell phone and
establish the credit card in his digital wallet with a "Level II ~ Out
of Band Verification". |
|
| Later, Bob decides to add his state
drivers license, insurance policies, medical records and all other
identity based records to his digital wallet. These
additional institutional verifications further secure Bob's identity. |
|
|
|
| Assume that Ted Jones attempts to steal Bob's
identity. Ted buys a cell phone equipped with a digital
wallet that follows The Trust Nexus's APIs. In the activation
process of the cell phone Ted creates a stolen identity for Bob Smith.
This identity record is automatically registered with The
Trust Nexus Repository. At the end of the registration process
Ted receives a message from The Trust Nexus
Repository stating that Bob Smith at the specified legal
address is already registered. The smart criminal would
probably stop there; however, Ted is not very bright but very
persistent
so he goes online and attempts to create a credit card account with the
identity he established for Bob Smith. |
|
| The system at the credit card company receives
information from The Trust Nexus
Repository that Bob Smith living at 123 Main St. in Austin,
TX has two identity accounts: one has a very high consumer
trust rating, the other, recently created by Ted has no institutional
verifications. The credit card company denies Ted's
request. The Trust Nexus
Repository sends a notification to Bob that someone may be
attempting to steal his identity. Bob sends a notification to
all of his digital accounts requesting "high alert" monitoring. |
|
| Because Ted/Bob has received an
authentication rejection, The Trust Nexus
Repository sends a message to Ted/Bob notifying him that he
needs a "Level I ~ In-Person Verification" within the next ten days or
his primary identity card will be removed from the repository. |
|
|
|
| If Bob should loose his cell phone he will be able
to notify each of the institutions through The Trust Nexus
Repository. The institutions will each have their
own process (phone, web, email, etc.) for verification. Once
verified each institution will place a revocation notice on Bob's
record in The Trust Nexus Repository. Bob can then
purchase a new cell phone and reestablish his accounts. |
|
| Currently,
the weak link in this system
is the possibility that a user's mobile device is lost or
stolen.
If the mobile device is secured by a PIN or voice ID, the data still
may
be accessible under current technology. This is a solvable
problem which we will leave to the manufacturers of mobile devices (The
Trusted Platform Module (TPM) has
generally solved these problems on the desktop.). |
|
| Even
without some type of cryptographic
key destruction system, the fact that an identity thief would need to
steal and hack into a physical device is a vast improvement over
current technology. |
|
|
| >>> page 1 - page 2 - page 3 - |
|
