Tag: google

Posted on

Why Are Google and Verizon Fighting Over The TPM Chip In Your Phone?

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.

Posted on

Putting Two And Two Together

So in the course of my evening of NFC/ISO 14443 smartcard/platform/API “literature” review, I put Steve Yegge’s rant together with an analysis piece about what Google thinks about NFC, and came to an unfortunate conclusion.  Google’s lack of NFC APIs, combined with them being the current best hope for getting NFC-enabled, ostensibly open smartphones into the mainstream, does not bode well.  My project must be tempered with realism.

Posted on

(Good) Middleware Takes Time

“The Golden Rule of Platforms, “Eat Your Own Dogfood”, can be rephrased as “Start with a Platform, and Then Use it for Everything.” You can’t just bolt it on later. Certainly not easily at any rate — ask anyone who worked on platformizing MS Office. Or anyone who worked on platformizing Amazon. If you delay it, it’ll be ten times as much work as just doing it correctly up front. You can’t cheat. You can’t have secret back doors for internal apps to get special priority access, not for ANY reason. You need to solve the hard problems up front.”  -Steve Yegge, from his now famous accidentally public-facing Google+ rant on platforms

For some time, I have argued that spending the time to do a good service-oriented architecture is the right thing to do, especially in the identity management space.  It takes a very long time to do this right, and the QA, health checks and iteration become more time-consuming than defining and writing the initial service.  The monitoring for a good SOA becomes the unit tests, mocks, etc, and you end up doing right by your customers by eating your own dogfood.  The problem is, in academic higher ed, a lot of time, there seems to be no extra time to spend.  You have to do what you can with the time and resources you have.  So you try to do the best job you can, and you try to use exiting service frameworks where you can, and make your own where none exist, if you can find the time to do it.  That’s one of the reasons I like working where I do- I think people get why services and platforms are good, which you might think is truly amazing to find in a state-funded higher ed institution.  The more amazing thing is that I think a lot of state-funded R1 universities get this, and they are getting it more all the time.  See: Shibboleth, Grouper and COmanage.

It’s interesting that Google, Facebook, Amazon, Apple and even Microsoft seem to be doing “sexy” things that get a lot of attention.  But the academic research institutions are doing a ton of work here, too, and while it’s not glamorous, it’s changing the world for the better.