Month: May 2012

Posted on

A Shift

The world still looked the same, but it was different
He walked from the gym, back to where he parked his car
There were still cars here, and people, dirt and beauty
He could smell the bar-b-que cooking down the street

It was the same old world, but the underpinnings of it had been replaced in the night
Everyone was talking to themselves – no, they were talking to thin air
But the thin air was everyone else

The old rules faded into the background, burning away like ground fog at 6 o’clock on a sunny spring morning

The guts of the plane had been changed while the plane was in flight
The re-tooling of the world system had taken place before anything could have been done

At every point on the curve, it looks like the curve is going straight up from here
But things still seem pretty normal

Posted on

Self Interest Doesn’t Scale

I’ve been thinking about the commonalities of a lot of patterns I’m seeing in the world lately:

  1. The “Arab Spring” and its coordination via social media
  2. The “Great Firewall of China”, China’s (failing) attempt to keep things like Twitter at bay
  3. Iran wants to create its own Internet (a contradiction in terms) to prevent stuff like Stuxnet and (more importantly) social media-based revolts from happening there
  4. Artificial borders and internecine conflicts everywhere are becoming permeable on all levels: from nation-state policy to transnational corporate hegemony all the way down to city council meetings and managerial turf wars.
  5. How long can places like the NSA keep employees from bringing cell phones into the work place?  How about when the “cell phones” are built in to our heads and we can’t really function without them?  Are we heading toward a world where there’s going to be a policy filter at the door of the NSA that shuts off or limits the capabilities of neural prostheses?
  6. The kids don’t care about privacy or policy – they use whatever works to communicate and share, the tools are getting better every day, and the tools and the kids don’t care about any of the above limits.  They definitely don’t care about your BYOD policy.

Let me say that I’m not an anarchist. I’m not even a libertarian. You could call me a social liberal and economic conservative, with some libertarian tendencies thrown in on stuff that’s about personal freedom, not infrastructure and the commons.

So what’s the unifying factor among all the items in my list?

I think it’s self interest and control. More accurately, it’s that the structures, frameworks and artifices of control, working on behalf of selfish individuals (everyone is selfish), are starting to crumble under the weight of the network effect inherent in social media. We are becoming less about the individual and more about the set of all humans.  This is just one more step in the long history of technology overcoming evolutionary forces.

Everyone sees and deplores the recent killings in Syria, and the governments of the world have no choice but to condemn them. The George Zimmerman/Trayvon Martin case probably never would have gone to trial if it weren’t for social media-reinforced pressure.

So what happens? Of course it looks like the control structures and the individuals they serve are pushing back. I think they are going to fail as humanity becomes increasingly interconnected.  Let’s face it: if evolution can’t win, how is power going to?

What does the singularity look like? Maybe it’s a bunch of angry kids flashmobbing a tyranny they can’t take any more. What’s the path of least resistance? Tear down the walls faster.

Posted on

An Idea For Remote Proofing and InCommon Silver

The InCommon Silver assurance profile has a section that allows for remote proofing of identity subjects. Many people I’ve asked about this are saving this section for “later” and aren’t going to try to do remote proofing to begin with. Someone said something to me the other day about the availability of notaries that makes me think this is possible to do in a not too terribly difficult way. Here’s the relevant section of the assurance profile:

4.2.2.4.3 Remote proofing
1. The RA shall establish the Subject’s IdMS registration identity based on
possession of at least one valid government ID number (e.g., a driver’s license or
passport) and either a second government ID number or financial account
number (e.g., checking account, savings account, loan or credit card) with
confirmation via records of either number.
2. The RA verifies other information provided by the Subject using both of the ID
numbers above through record checks either with the applicable agency or
institution or through credit bureaus or similar databases, and confirms that:
name, date of birth, and other personal information in records are on balance
consistent with the application and sufficient to identify a unique individual. If
this appears to be the case, the RA authorizes issuance of Credentials.
3. If the record checks do not confirm the Address of Record, it must be confirmed
as described in §4.2.2.5 below.

Note that it says if you can’t confirm the information provided via record checks, you have to register the subject via the address of record. Everyone seems to be focusing on the technical problem of verifying the source document numbers via Equifax or other credit bureaus, and/or state motor vehicle registries. I think people are so shocked by this requirement that they’re misdirected away from the critical pieces here:

1) You only need to register the facts of the documents presented – you can do that via notaries public that are available free of charge for customers at all banks in the US.

2) You can confirm the identity of the individual by delivery of a registration secret to an address of record. What is an address of record?

Conveniently, section 4.2.2.5 (2)(b) says:

For an electronic Address of Record, the RA confirms the ability of the Subject to receive telephone communications at a telephone number or e-mail at an e-mail address.

So you can just e-mail them a short-lived registration bearer token after you receive their notarized paper form containing their identity documentation back. Can it really be that simple?  An idea for some legalese to include on the form (I am not a lawyer) might be:

I hereby declare that the e-mail address supplied on this form by me is a valid email address that is acceptable for use in official communications with me.  I am the only person who has access to this email address.

Update: 5/30/2012: Thanks to Mark B. Jones for this interesting international tidbit on consular services and the notary function: http://travel.state.gov/law/judicial/judicial_2086.html

Posted on

Just Stop

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:

  1. email addresses are name-based.
  2. Names change (usually in the most personally sensitive situations, where they must change: marriage, divorce and witness protection or court ordered separation).
  3. Not everything that looks like an email address is a deliverable email address (e.g. userPrincipalName, eduPersonPrincipalName).
  4. If it looks like an email address you will be tempted to assume that it is an email address.
  5. You could be wrong – it might not really be an email address.
  6. Do you really need to know someone’s email address?
  7. Why do you need to know someone’s email address?
  8. Most people have multiple email addresses.
  9. Which one do you need to know?
  10. How are you going to make the person remember which one they used?
  11. What if they don’t know?
  12. 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:

  1. Employee ID (not SSN)
  2. Student ID (not SSN and not name-based)
  3. Identity Management System (IdMS – if they have one) surrogate key
  4. Unix UID (if the customer is using a centrally-managed UNIX-type system)
  5. 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)
  6. 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.