OneID unique features
-
No usernames
-
Usage of a password is optional (you don't need one to
create a OneID account; you'll be required to create (and use) a password to
protect your recovery URL; you are not required to use a password otherwise
unless you choose to configure password protection on a device, website or
transaction)
-
Two-factor on a single device. A OneID login that appears to be a single-factor (e.g.,
requiring a password) is actually a two-factor login because OneID has
fingerprinted the device
-
Can be implemented on an RP site in as little as 3
hours for authentication and as little as 5 minutes for form-fill
-
A OneID identity is permanent; no matter what happens,
it cannot be permanently compromised by an attacker
-
Identity can’t be phished
or keylogged
-
Stolen devices are automatically disabled worldwide
without the user having to do anything. When a thief has made 5 consecutive
invalid password or PIN guesses or incomplete pairing attempts, that device
is instantly disabled and cannot be used with any relying party. The user
can re-enable the device at anytime. No configuration changes or notices to
any relying party are required.
-
Identity can only be recovered through use of a high
entropy secret (AES-128) combined with a password or PIN code (depending on
which secret you are trying to recover). The high entropy secret
is never available to OneID (it is generated on the user's device and
emailed from the user to the user) and is kept by the user (or friends of the user)
so it is distributed. An attacker needs to get the key and know the
secret so it is two-factor account recover. No one at OneID can ever
"recover" someone's account because OneID never sees the recovery symmetric
key or knows the PIN or password verifiers (there is a clever technique so
that the PIN and password salts aren't revealed to an attacker either).
-
Identity recovery (which involves recovering crypto
secrets that are found only on the user's devices) is only necessary if a
user loses all his devices. It requires that the user remember his password
and PIN code
and have a high entropy secret.
-
Because passwords and PINs aren't recoverable, the user
can define password and PIN hint text (or leave it blank). These hints are
only able to be displayed on pre-authorized devices since it requires the
crypto secrets on those devices to display the hint. This makes it easy for
the legitimate owner to recall his password or PIN. An attacker must gain
control of the device to learn the hint, but because OneID will only allow
less than 10 guess per day (and only from authorized devices), this creates
an almost impossible burden for an attacker.
-
OneID is based on unidirectional identifiers so it
supports "directed identity." Each relying party maintains a unique set of
public keys for a given user.
-
You can't login as me if you aren't using a
pre-authorized device. So an attacker can't "guess" passwords or lock
someone out of their account unless the attacker is able to control a user's
device. And even if that happens, the number of password guesses from a
given pre-authorized device is strictly limited.
-
Shared secrets are
replaced by ECC public key crypto
-
Crypto secrets only
stored @ endpoints (and OneID server)
-
3 ECC signatures required
for high assurance (2 independent endpoint signature + OneID server)
-
No single point of
compromise (SPOC); breaking into any device or OneID server doesn't allow
assertion of identity, snooping of secrets, brute force PIN or password
attacks (no offline grinding if you only have one device), etc.
-
Pre-authorized devices
before you can use them
-
LoA is based on max LoA
requested by user, RP
-
User can set LoA on
device, site, transaction type and amount
-
User manages devices
-
Cloud repository can’t be
decrypted by OneID service provider
-
Cloud repository can’t
see where user went
-
RP can’t see which cloud
provider is used by the user
-
RP’s can’t correlate
users (unique pub keys for each RP)
-
Cloud provider can never
assert user’s identity by itself (requires participation by at least one
user device)
-
Impervious to most all
attacks
-
Two distinct device
classes each with its own unique secrets (browser and OneID app)
-
True OOB 2-factor, not
just 2-factor
-
Supports LoA with
2-factor in-band as well as 2-factor out-of-band
-
Crypto secrets, PIN, and
password are never revealed to OneID service provider. They are verified by
repo using asymmetric crypto
-
Secure method to transfer
secrets between peer devices
-
All-in-one complete
identity system (not just authN or authZ)
-
End-to-end secure transactions since signed by the
user's device and directly verified by the relying party.
-
First NSTIC-compliant
digital identity system (we comply with all of the key goals of an NSTIC
identity provider)
- Support for multiple
cloud providers (not just OneID)
-
OneID service providers
can set look and feel
-
User can change cloud
providers w/o impacting keys @ RPs
-
OneID protect the high
value assets (e.g., large purchases or wire transfers) with higher LoA than
is required normally (e.g., for sign in)
-
PIN and password are not
grindable if you break into the OneID repository or user device (because
they are salted on the user's device and used as a signing key which is then
verified by public keys stored in the repository which will only allow a
certain number of verification requests per day)
-
OneID Remote secret is
only shared with other Remotes via direct QR code scan so even if everything
else is compromised, all identities are safe for high value transactions
-
Device IDs allow stolen
devices to be removed easily w/o changing public keys at RPs so the
registered public keys at the RPs never need to be changed
-
User can start at RP with
2 keys and define the 3rd key later so can register at a site
without involving the OneID Remote
-
QR code and secure
numeric pairing is used to provision new devices (not to log in)
-
No download required for
use with browser; works on any modern browser
-
OneID can tell the site
the likelihood that the user is a spammer.
-
It's free to users
-
It's a general purpose identity, not a specialized,
single purpose identity like RSA tokens.
-
Works with existing hardware, nothing new to purchase
or carry
-
Browser sign in user model (so you effectively
authenticate the browser)
-
OneID is a very general purpose identity that preserves
privacy and is very secure and extensible.
-
RP can store RP-defined attributes in the user's
identity (such as a medical board certificate) which can then be read by the
user and given to other RP's. You can see this at
rx.tryoneid.com and
doctor.tryoneid.com. Use the Rx
link first to try to write a prescription. Then use the "doctor" link to get
your credentials into your OneID. Then you can go back to the Rx site to
write a prescription.
-
A single stable identifier that a person can use for
tying certifications to. This identifier can be shared among relying
parties, or be unique to each relying party. In either case, it never needs
to be changed (just like the public keys stored at each RP site) and is
end-to-end secure (it doesn't involve using a CA which violates end-to-end
security). This enables certifications to be tied to a stable-for-life
digital identity that is end-to-end secure (i-numbers aren't end-to-end
secure because the i-number database could be attacked).
-
A OneID user can pick any password he wants...there are
no password standards like Google and other IdPs have. This is because if
you have to have password standards to secure an account, your system is
fundamentally not very secure. Our system is secure. My password is "x." Go
try to break into my account.
-
We never lock out a user from his identity (see what
happened when
Facebook locked Chris Leydon out of his account). That's because we are
a pure identity system. Facebook is a social network and an identity. When
you join, you agree that they can kick you off their network.
Future capabilities
-
A digital claims architecture (not yet available on the
production servers) that allows users to prove a claim using a real time
signature from an authority, but without the authority knowing who is doing
the asking (which would violate the user's privacy). The relying party only
gets what they need, e.g., "Prove your birthyear is less than 1960 by
sending me a signed assertion of that fact from a recognized authority" vs.
"Prove you were born in 1952." Arbitrarily complex assertions can be proved,
e.g., "Passport number=12345 and birthyear<1960").
OneID documentation guide
|