Last week was the first Internet Identity Workshop on the east coast. Having IIW in DC is especially timely given the identity-related activity here inside the Beltway.
NSTIC: Worst. Card game. Ever.
I’d estimate that about half of the un-conference sessions touched on NSTIC – the Nation Strategy for Trusted Identity in Cyberspace. Now, you may have read the NSTIC strategy document which has been available to the public here for a few months. What you likely haven’t ready is the implementation guide which only a few people outside of the authors have seen. There were a few people who had in fact seen (one even had a copy of it with him) of the implementation guide. The rest of us were left to play NSTIC Go Fish:
Ian: Does it mention OAuth?
Person with NSTIC Implementation Guide: No, go fish.
Ian: Does it describe healthcare and health IT?
Ian: Does it solely focus on cybersecurity scenarios?
Person: No, go fish.
And on and on it goes. Unfortunately, people directly involved with NSTIC did not attend IIW East, even I and other people encouraged them to do so. I consider this a missed opportunity to talk directly to the a large swath of the identity community directly.
One of the biggest questions that rose out the NSTIC discussion was: what is NSTIC’s real purpose? It appears to attempt to meet two different desires – one being the desire to protect critical infrastructure and one being the desire protect consumer and citizen identity through use of things other than username/password.
Overloading NSTIC, attempting to fulfill such different desires is a very bad idea. To the author I say separate the concerns of both the strategy and implement guide, open the implementation guide up to comment, and be clear to whom NSTIC is meant to speak.
LOA: Assured of what?
The other big conversation related to FICAM, levels of assurance, and government’s relationship to an emerging marketplace for identities. There were definitely some interesting conversations on this – I recommend Anil’s write up of his “Government as Identity Oracle” session.
I did pick up on a disturbing trend. People seem to use level of assurance (and here we are talking OMB 04-04 / NIST 800-63 LOA) as an indicator of overall trustworthiness of the organizations handling those credentials. LOA was being used as a token for the quality of IT operations.
Let’s be clear here – LOA refers specifically to the strength of and issuance process of digital credentials. LOA doesn’t stand for Level of Aptitude. You could be a horribly bad IT shop and still issue higher levels of assurance credentials. (I recommend looking up a scene in Chris Farley’s Tommy Boy for an example of the previous sentence, keywords: guarantee, box, quality.) In fact, you may have a system that requires LOA-4 credentials but that in no way means that you have security controls in place to protect that system.
This is where trust framework providers and their assessor come into play. The assessment process for a credential issuer has to include an assessment of their IT controls and practices. I’d like to see a similar assessment of relying parties as well – and this is something that could happen as communities form using this trust framework pattern. A given community could easily dictate (and more importantly, assess) the controls and practices of both the credential issuer and relying parties. That information then can be presented to individuals so that they can make informed decisions about the organizations issuing and consuming identity credentials.
It was great to see so many new faces at an IIW. There was no shortage of session topics. Let’s face it – DC is a great identity and privacy town and it needs IIW-like events more often. What do you say? Should we try to organize an identity and privacy happy hour in October as a start?