OneID Q&A

Has do you envisage an enterprise adopting this type of solution (perhaps having them run their own OneID signing servers? I absolutely see the point of this part being intrinsically separate, but I also know that some enterprises will not want their users bringing their own identity (even a bloody secure one) and would rather issue them one whereby they control all components of the authentication stack and have complete control over that availability of it. Backwards thinking? Probably, but could you accommodate this type of scenario?

Yes, that is backwards thinking.

The corporation has complete control over what it puts in my OneID and whether to accept my OneID for use with any corporate resource. So the corporation is not missing out on control aspects at all.

By using OneID with Dell's XACML product (Quest One Identity Manager and Quest One Authorization Policy Server), corporations can have finer grain control than they've ever been able to have before. They are currently in the process of integrating OneID with this.

The only thing the enterprise doesn’t have is the ability to hold my identity hostage from being used other parties.

I was wondering, is there an inventory of the types of device/technology integrations you allow as secondary id for OneStop?  For example, can you interface with IVR and voice print/ voice recognition?  What about out of band OTP (using SMS)?

 Yes, to all of these, the possibilities are really endless.

We haven’t implemented them due to lack of a customer that has requested it (since we are just launching now people are starting to ask about this).

For these sorts of things the OneID service makes the call and signs the assertion. So you’d have two signatures, not three. The OneID service would simply sign the original request that it was fulfilled. You wouldn’t get a separate DIGITAL signature back from those systems because those systems are NOT controlled by the user so the user’s signature key would never be given out to them.

So the relying party would see two digital signatures: one from the user, one from OneID. The signature from OneID attests that they talked to the IVR system, verified that the voiceprint matches the voiceprint associated with the OneID (registered earlier when the person logged into the IVR system and associated the OneID with the voiceprint), and received the correct response from the IVR system.

SMS OTP can be done as well. The OneID service can send a random number which the user then enters in the browser instead of a password in the OneID popup that appears.  I would ONLY use this if the doctor doesn’t have a supported phone that can't run the OneID Remote app.

How could OneID be integrated into an existing Shibboleth/SAML/InCommon SSO infrastructure? 
We are working on a Shibbolth plug-in that would allow you to take a OneID credential instead of a username and password.

So the shibboleth login page that users get redirected to would have a OneID login button which could be used instead of a username/password.

The only remaining item is which identity to use. Using a OneID identity would be too much of a paradigm shift too fast.

Therefore, it is much easier to use OneID as an identity token to the existing Shibboleth identity, rather than to replace it.

So after login with a username and password, the user should have the option to associate his OneID to his identity by hitting the OneID link button.

From that point on, he should be able to login using his OneID because the plug-in will keep his public keys on file (e.g., put them in an LDAP directory for that identity), so that future logins into the Shibboleth can validate the login and associate it with the correct identity.

Similarly, if the user hits the OneID button first and there isn't a Shibboleth identity linked to that OneID, the user can be prompted for his username and password so that the linkage to the identity can be established.

How would a browser without Javascript enabled, or without support for HTML 5 local storage, be handled (if at all)?
It wouldn't be. Those users who choose not to upgrade to a modern day browser will not be able to benefit from OneID and should stick to username and passwords.

What protection is there for a shared computer environment, where the browser's local storage could be accessible by others?
Users of shared computers where a single browser is shared with many users should use a password (or higher LoA) for device login on shared devices. This prevents anyone from logging in as that user. Five attempts to guess that user's password will disable the device. The password cannot be grinded locally, even with an infinite amount of computing resources.

If there is malware on the shared computer, that malware could copy the device secrets and user's password. There is cloning detection to detect this case, but it isn't guaranteed.

If the shared computer uses different login accounts, there is no issue if the environments are truly separated.

What support will there be for non-browser clients?
Yes, we are working on desktop clients for PC and Macintosh and Unix variants so that applications can authenticate with OneID. We've done the bulk of this work already.

For example, Using OneID with SSH shows our desktop client at work on a Linux machine that is the ssh server. This is very easy to set up and allows you to do two-factor authentication to any machine that runs the SSH server.

We will also be enhancing the OneID Remote app to provide authentication services for mobile apps so that iPhone, iPad, iOS, and Android apps can call the OneID app to sign an identity challenge from the application (which it in turn got from the service provider). So for example, if you write a Wells Fargo banking app for the iPhone, the Wells app will try to login to wellsfargo.com which will send a challenge back to the Wells app and the Wells app will forward the challenge to the OneID app to sign and return to the callback URL, bypassing the app for security reasons (to avoid a man in the middle attack).

What support is there (or will there be) for delegation (n-tier environment)?
There are several ways to do this, but the simplest is to use the existing Shibboleth N-tier support (derived SAML assertions, e.g., see Shibboleth N-Tier Support).

If service provider SP trusts assertions from IdP1, then logging into IdP1 from an approved IdP2, should allow IdP1 to vouch for the identity.

If OneID were to be supported natively by the service providers, there are a lot more options. For example, you could use digital claims to avoid the delegation entirely. The simplest is to ask for the verified email address of the user and compare that to a list of supported campuses. Another is to store a login certificate in the browser to the effect of "the person asserting public key sets A,B,C is approved by MIT.edu  for the next 24 hours ---signed MIT.edu." The RP could send a challenge, and then ask for the signed challenge and the certificate, where the signature of the challenge is done using the private keys associated with the public keys in the certificate.

There are probably more ways. It's really gated by the support in the RPs.

Can the PIN be swiped by malware on the desktop when the OneID is first created?

No, because the PIN is NEVER entered on the desktop. It is ONLY entered on the phone and is immediately erased after creating the signing keys. So it is on the phone for a fraction of a second.

Protection against malware  is why there are two independent classes of user devices. The desktop uses a password; the phone uses a PIN.  To compromise your identity, you’d need to compromise two independent computers.

The phone would have had to have been heavily compromised before the software was installed with a key logger and the attacker would have to be looking for this. It’s a very low probability attack, which even if successful, wouldn’t be very useful because you still wouldn’t know what the salt was that is stored in the app. So you’d have (the PIN) which by itself is pretty useless. My PIN is 1200. Good luck with that!

For more information see:
OneID documentation guide