Thursday, April 28, 2011

Leveraging existing work to deliver on NSTIC

I was fortunate enough to sit in on a session at the Department of Defense IPM conference a couple of weeks ago that was given by Andy Ozment, the White House Director for cybersecurity policy. Andy was speaking on the just released NSTIC (National Strategy for Trusted Identities in Cyberspace).

Andy's talk was a general one that discussed the background, need, plan in general and the intended benefits. I will be upfront here in that I believe that NSTIC is a good idea, especially when combined with other initiatives that are being undertaken inside the Federal government today. NSTIC as a program is intended to move the bar forward by incentivizing industry to provide a better credential set to their users. Options will allow some vendors to have a highly interoperable credential that addresses a very broad range of services and these implementations will be created following guidelines that are created by the government and industry. This truly becomes a public-private initiative, government providing some base requirements to ensure interoperability and improved security and then providing a framework for credential providers and relying parties to use these credentials. At the same time the government will provide seed money for pilot programs where interoperability with government applications becomes the carrot for end users to also get involved.

Again I think this is a great idea and we need to make sure that this initiative leverages existing work that has been done and is underway. The existing PIV card is a good example of a federated credential and it's extension into PIV-I broadens the user base for that federation. The PIV and DOD CAC programs today cover somewhere less than a few million users, PIV-I is targeted at organizations that have a need for a well defined credential for physical and logical access that also allows for a high level of interoperability. This type of credential is well suited for medium to large corporations, first responders in all market segments and state and local governments. That is a very large user population.

Of course PIV and PIV-I are not credentials for the masses. Today people have varying levels of credentials that they use, some with a true identity linkage and others totally anonymous. Some of these credentials have second factor capabilities such as the ability to tie into Google Authenticator or tokens such as the eBay and PayPal tokens. As smartphones become more capable and secure we could also see expansion of the applications such as those offered by Visa and even Starbucks to capabilities that would allow interoperability with other relying parties.

The idea that a single relying party will accept credentials from multiple providers using multiple technologies may seem far-fetched but even today government applications such as NIH's PubMed allows use of different trust provider platforms for access to it's resources.

Of course as we extend the credential acceptance we need to remember that identification does not mean authorization. We need to make sure that while a federated identity makes things easy for the user, and in some regards easier for the relying party, since they do not need to be an identity provider as well, that we are aware that we need to know who we are letting perform transactions and why. Attribute exchange allows identity providers and relying parties to communicate to ensure that authorization decisions can be appropriately made at the relying party end. This capability could also allow for end users to better control what information they share with relying parties by giving them the ability to only release information in certain cases. Some examples - a blog I am commenting on does not need to know my real name; a online wine store does not need my birthdate only an assurance that I am 21. There are initiatives today, that I have previously discussed in other posts, that build the basis for this.

Again this is not a case of building something new but rather a case of taking what is out there, leveraging some updated policies and guidance and then architecting an interoperable system.

- Posted using BlogPress from my iPad

No comments: