Requirements for a trustable cloud identity
provider ("bring your own identity")
The reason we all have so many usernames and passwords
is that there is no third party trustable federated identity provider. So each
site manages its own identity system (occasionally trusting a few federated
identity providers such as Facebook, Google, and Yahoo).
Can you name a single
trustable identity provider? We couldn't. That's why we started OneID.
A trustable identity provider means that the trust in the identity is due to the
architecture of the system and not operational policy. So code changes at OneID
canít assert someoneís identity. Compare that to any other consumer identity
provider were a simple code change could allow a person to assume someone elseís
We made a list of 34 requirements for a trustable
federated identity provider. OneID meets all the requirements below. Most other
federated identity providers (such as Facebook or Google) meet just a few.
Facebook isn't safe or trustable. For example,
Facebook says 600,000 facebook accounts are compromised each day.
Google isn't safe or trustable. When Stratfor was breached, the
hackers used passwords there to break into thousands of accounts at Google and
Existing federated identity providers are all vulnerable
to mass breaches, either at the identity provider itself, or any
other large identity provider, can jeopardize accounts at other identity
providers. In addition, any of today's federated Identity Providers (such as Facebook and Google) can make a simple code
change and pose as anyone they assert identity for.
A trustable identity provider must do two important
- It must be trustable itself (relying on system
architecture to ensure trust rather than policy)
- It must provide identities that can be trusted by
relying parties (i.e., identity assertions that are end-to-end secure and that
extremely difficult to breach at either end)
It is interesting to note that:
- With a traditional IdP, you can breach an identity
at either end (user, IdP, or RP)
- With a OneID, you can breach an identity at
Here's a list of 34 requirements that we think a trustable
cloud identity provider needs to demonstrate:
Identity can't be asserted without express consent
of the user. This is the single most important requirement. It means that an
identity system relying on a single assertion by a centralized identity
provider fails this test because that service can be compromised which
causes a mass compromise of all identities from that service. To meet this
requirement, the identity protocols must require active involvement of at least one user device (and proof at the RP of 2
independent devices required for high assurance). Other than OneID, no
consumer identity provider can meet this claim because all the IdPs use
centralized assertions; you may authenticate using two factors to the IdP,
but the IdP isn't trustable because it controls the assertion to the RP and
the IdP can be compromised.
No point of mass compromise (e.g., at the IdP or the
Externally auditable 24x7. Any code that touches your
identity is always in plain sight, not behind a firewall (like every other
identity provider you can think of). So the protocols themselves must be
trustable, and they must be fully visible to the user (if he looks). There
must be complete transparency.
If malware is present inside the IdP that can read
everything that the IdP sees and sends it out to an attacker, nothing bad
can ever happen.
No shared secrets (for example, there is no database at
either OneID or any RP that, if compromised, would be useful). This applies
to the proof to the RP of the user's identity, as well as proof to the IdP
that the user knows the proper PIN or password. All of these must use
asymmetric cryptography for proofs. In particular, even if the user doesn't
have a smartphone, logins should never share secrets with the IdP (we
designed a clever new patent-pending way to achieve this).
End-to-end secure authentication and authorization
so the assertion is re-hashed on each device signed by the user's device(s) and verified by the RP;
there is no centralized IdP providing the identity assertion (which means public key crypto is required
on the user's device). Protocols that require centralized IdP such as
SAML, OpenID, Oauth can't be used. PKI such as
X.509 should not be used since
both the CA's can be compromised and so can the private signing keys
associated with the certificate (as
Adobe found out when Adobe's signing key was compromised). This means
that YubiKey and hard and soft tokens can't be used since they don't sign
the transaction... they are vulnerable to MITM, MITB attacks.
Support authentication, authorization, info sharing,
and asserting and proving digital claims (such as "I am over 21").
Minimum LoA can be elevated by user or RP to at least
LoA levels must include both 2-factor in-band (i.e.,
single device) as well as 2-factor out-of-band (two devices)
Privacy and security must be guaranteed by architecture
(not operational policy). This includes keeping personally identifiable
information secure (so it is not possible for OneID to decrypt and so it is
never stored on any of the user's devices), using opaque, unidirectional
identifiers with RPs, and ensuring that OneID can't track what RP's you've
visited and the RP's can't track where you have your identity stored.
No Single Point of Compromise (SPOC) for any identity so attacking the
cloud or a user device can't compromise an identity
Easy to use; all the crypto must be hidden from the
user so OneID appears to be as easy to use as Facebook
Recovery must require high entropy secret stored at
endpoints (never in a central location) combined with a second factor known
only to the user (such as a PIN code). The architecture has to guarantee it
is impossible for the OneID service to "reset" your password or email you a
Available for desktop, mobile, and web applications
Password optional. The identity shouldn't require the
user to have to use a password (user's choice).
Something you "know" (PIN and/or password) can't be
offline grindable on the user's device or by the IdP. This requires that all uses
of passwords and PINs must be combined with a local salt and then used
as a digital signing key.
Consumer provisioned and managed identity so users
could create it themselves, and "bring your own identity" (BYOI) to services
that would trust it.
The identity must be permanent. You should never be
able to lose your identity or have it stolen in a way you cannot recover it
and lock the attacker out. The public keys on file at each RP should never
have to be changed no matter what happens. For example, if a device is lost
or stolen, the user should be able to disable the device from any other
device they have (or provision a new one). There would never be a need to go
to individual RPs to notice them of a change since that would be unmanagable.
Support all modern day browsers without requiring a
download (so can be used on mobile browsers such as Safari on iPad and
Must support a user model of login to browser (or the
mobile app if using with mobile apps) rather than individual websites or
mobile apps so a user authenticates once to OneID once at the start of a
session and can log off at the end (or use a timeout).
Must support two classes of user devices with each
maintaining unique private
signature keys so that RPs can keep a permanent set of 2 or 3 public keys on
file to authenticate a user (they keep 3 public keys on file if the RP
requires high assurance). The minimum is two public keys: the primary device
and the OneID repository. A third signature is used when the out-of-band
device is used (the OneID Remote app). The two user device classes must
share a symmetric key so that the primary device can communicate (via the
OneID repository) the original transaction to the secondary device without
the OneID repository knowing the contents of the transaction (so the OneID
repository signature is always a "blind" signature because it can
never see the transaction; the repository signature indicates approval that
the devices are authorized and the transaction LoA's have been satisfied,
e.g., PIN code verified by the repository).
Transactions had to require at least two independent
digital signatures (low assurance uses) and 3 signatures for high assurance
Users would have their choice of which vendor hosts
their identity and can easily move their identity to a different provider
(of the identity) at any time
Interoperable so that if you need to assert your
identity to a relying party requiring SAML or OpenID or Shibboleth, that the
identity system would accommodate that use (and without requiring extra
Users would be able to control the level of assurance (LoA)
for signing into their devices and websites, and for approving transactions
over a cumulative dollar amount (subject to being overridden by the relying
party if the relying party requires an even higher LoA).
User devices must obtain the secrets to the user's
identity before being used through a one-time authorization process that
securely (without ability for OneID to snoop the secrets) transfers the digital secrets from an authorized device to a new
device. The OneID service is used to facilitate the transfer but in such a
way that OneID can never learn the secrets of a user's identity. The OneID
service alone cannot be used to authorize a new device; the user must bring
a high entropy secret to the pairing process.
Should work with devices a user already has.
If a device is lost, the owner should be able to
disable or remove it from his identity. Also, if there are sufficient
consecutive authentication failures (such as 5 bad PIN or password entries),
the device should disable itself from the identity without any explicit
action from the user so that the device cannot be used with any relying
Should never lock out a user from his identity (take a
look at what happened when
Facebook locked Chris Leydon out of his account).
Should never remove two-factor requirements without
proof. For example, Google violates this: if you add two-factor and
complain, they will remove the two-factor requirements. Their focus is on
user retention, not security. OneID is focused on secure identity.
If a relying party needs an out-of-band two factor,
there must be no way for the IdP to assert that. It must be proved with an
additional digital signature.
If malware compromises your machine, your identity
shouldn't be jeopardized. For example, if an attacker gains access to one of
your systems which was logged in, it should be possible to instantly disable
that access. For example, with OneID, you simply disable the device. But if
you used a username/password system and had your 1Password, LastPass, or
RoboForm broken into, all of your accounts will have to manually be reset.
Should not allow account reset based on email
confirmation of the reset. OneID can't do this since it requires a high
entropy secret that is never seen or stored at OneID. Most other identity
systems allow this.
You should be able to instantly disable any lost or
stolen device so it can't be used to assert your identity anywhere. For
example, if you are using usernames/passwords or SSO, you can't do this.
The login credentials should never ever be phishable or
keyloggable, even in the lowest assurance mode.
There are cases when a user completely loses control of
his an account to an attacker so there must be a way for the user to reclaim
his identity without sharing any secrets with the IdP. For example, the IdP
should be able to restore the identity on the IdP to a point earlier in time
if the user has provided sufficient proof that he is the true owner of the
The system must be immune to XSS attacks, e.g., by
See also How Twitter could
permanently end password breaches especially the comments at the end.
more information, see OneID documentation