cloud – Nicole Roy

I’ll give you a hint: it’s not about using NFC to exchange business cards, and it’s not even primarily about mobile payments. Why does Google want the TPM/NFC module in your phone integrated into the phone, and Verizon wants it in the SIM card? Simple: Identity ecosystem lock-in. Verizon and Google both have a huge vested interest in providing you with an electronic identity which you can use to execute high-stakes transactions. The only good way to do that for the general public is by putting a TPM chip in everyone’s phone and wirelessly provisioning high-assurance credentials to it via their trusted service manager of choice (much like “The Highlander,” there can be only one in control of the keys for each TPM, and they each want it to be theirs).

Why do I think this? Take a look at the OIX-certified FICAM Trust Framework-approved list of identity providers. What do you notice? Verizon is LoA 1, 2 and non-crypto 3 approved, and Google is LoA 1 approved but likely wants to be at LoA 2 and 3. Why is Verizon at LoA 2 and 3? Because they have a very well-established business relationship with their customers. They know, with a high degree of assurance, who they are. How will Google establish this high-assurance relationship with their customers? Google Wallet, Google Voice and their controversial “Real Names” policy.

So why do these companies want to be your default high-assurance identity provider? Simple: vendor lock-in. Can you imagine a more powerful lock-in effect for a specific platform than the one created when you not only use it for all your financial transactions, but also to open all the high security physical doors you use? With the advent of cloudsourced security, we aren’t just talking the front door of your house or starting your car. Your workplace will likely soon move to outsourced identity for login to your workstation, access to the VPN, and even the doors to the data center. Why? It’s much cheaper and easier (and less risky) to sign a contract with Verizon or Google to provide this service than to hire the people and purchase the infrastructure to manage it yourself. It’s also much less cumbersome to use a phone which everyone in the company normally already carries, than to set up some kind of expensive and cumbersome smart card system.

So which vendor will companies buy high-assurance identity from? The one with the largest installed base.

My new pet peeve is cloud service providers who assume that they can and should use email address as a primary key for customer identities. This is a terrible idea for a large number of reasons. Here are some:

email addresses are name-based.
Names change (usually in the most personally sensitive situations, where they must change: marriage, divorce and witness protection or court ordered separation).
Not everything that looks like an email address is a deliverable email address (e.g. userPrincipalName, eduPersonPrincipalName).
If it looks like an email address you will be tempted to assume that it is an email address.
You could be wrong – it might not really be an email address.
Do you really need to know someone’s email address?
Why do you need to know someone’s email address?
Most people have multiple email addresses.
Which one do you need to know?
How are you going to make the person remember which one they used?
What if they don’t know?
What if they leave the {school, business, non-profit, government, etc} where they had their email account? Most best practices require deprovisioning of email for people who don’t {attend, work at} that place any longer.

The worst case scenario is that you, as a cloud service provider, have not been clear with your customer about your use of primary keys for identity, and specifically your use of email address as a primary key. The customer will then blindly deliver this to you and when customer identities’ email addresses change, someone else could end up with access to protected resources that should be owned by a different person.

Many small customers (likely the customers small enough to be looking for your cloud service in the first place) are not in a position to think about the security implications of this use. You should do that thinking for them, and bring them up-to-speed with the problems and pitfalls associated with using email address as a key. Sure, since most people have an email address, it’s a convenient piece of information that you can additionally use for delivery of things like password reset requests, confirmations and workflow messages. On the other hand, you can use other things (that don’t change and aren’t re-assignable to other people) as a shared primary key, and still ask for email address for use in sending email.

I have seen a large number of cloud service providers ask for email address as an identity attribute and not disclose its use as a key- this is the worst of all possible situations, because you are making assumptions about the nature of the customer’s email address that aren’t true, and you aren’t allowing them the opportunity to understand that because of lack of disclosure. I’m not a lawyer, but lack of disclosure of this kind of thing, leading to an unintended release of information via change of email address (situations in which someone else gets a previously used email address do happen) seems to open the door to legal action.

An ideal solution on the part of a cloud service is to make the primary key for identity very flexible (very long max length, any format alpha, numeric, etc). You should then develop an interview process that you use to find out what types of keys your customer can provide, and be able to map one or more of them into the key field in your service. Use a surrogate key within the service that’s hidden from the customer, and expose an API that allows the customer to update their users’ identity keys if necessary. Some suggestions for things that might make good keys:

Employee ID (not SSN)
Student ID (not SSN and not name-based)
Identity Management System (IdMS – if they have one) surrogate key
Unix UID (if the customer is using a centrally-managed UNIX-type system)
Network ID (if it doesn’t change- ask the customer if they do. If the customer wants to use this, allow them to rename via an API)
Scoped Network ID (scoped to the customer’s DNS domain name- ask the customer if these change, don’t use if they do, or allow renames via an API)

Cloud service providers: please stop asking your customers for email address as a shared primary key, and work to educate your customers on the danger of using email address as a key for access control.