In Context

March 21, 2010

ICF input to NS-SOT

Filed under: — paul @ 6:13 pm

At RSA Ely Kahn (Director of Cybersecurity Policy at National Security Staff) and some of his contractors/staff met with members of the ICF board as well as with members of the OIDF and OIX boards. During the meeting the foundations were asked to respond to a questionnaire that was designed inform the “National Strategy for Secure Online Transactions” (NS-SOT) –a name chosen to sidestep the big brother alarm raised whenever words like identity management are used by the feds. He mentioned that Obama would be announcing this strategy in June.

Instead of answering the questionnaire the ICF board decided to write and send this NS-SOT ICF Response to Ely. Ely is one of the good guys, so I’m glad to spend time on this sort of thing. The jist of the paper is that relatively small, short term (not FY12 !) investment in turning a few Federal agencies into buyers of federated/externalized identities would jump-start an entire ecosystem. It would be particularly good for i-cards and OpenID.

4 Comments »

  1. I’m developing a detailed submission on the NS-SOT and the fit between the OIX model and the needs of e-business and e-government. But can I please test one of my concerns first in this forum?

    Something about the word “open” has never sat well with me in the context of “open identity”. I wonder if the open identity community has coopted the word and subconsciously twisted it a little? “Open standards” and “open government” are obviously good things, and “open source” has a lot of goodness attached to it. But what exactly does “open” mean in open identity?

    There is a strong implication in “open identity” that identities issued by different entities can be (nay, should be) treated equally. But when I look at any of the ’serious’ identities used when transacting with business and with government, there is almost always a natural preferred issuer for each of them. Banks issue credit card numbers; health agencies issue health identifiers; governments issue SSNs, tax file numbers and passports; employers issue employee IDs; medical registration bodies issue doctor’s credentials.

    So these types of identities aren’t actually “open” on the issuer side.

    So, if there is usually a one-to-one relationship between a type of identity and the natural issuer of that identity (or in other words, if there is usually just one obvious issuer for each given identity), then isn’t a great deal of the open identity framework overly complicated?

    I think to make progress in identity frameworks, we need more simplifying assumptions, and fewer complicating generalisations.

    Cheers,

    Steve Wilson, Lockstep, Australia.

    [Reply]

    paul Reply:

    I think of open identity as being about open standards over the wire (e.g. IMI), open standards for the format of security tokens (e.g. SAML), open source implementations of all necessary components (including active clients).

    I agree with you that any given identifier will only come from a single source, but identifiers are not the same as identities. If you think of an identity as a set of claims, then an identifiers is only a specific kind of claim. If you look at non-identifier claims (e.g. age-over-18, is-heart-surgeon, credit-score-over-650, etc.) you see that they can come from an “open” set of providers.

    [Reply]

    Stephen Wilson Reply:

    All true.

    And yet I’ve seen far too many attempts (in Australia at least) to try and economise on the number of “identities” each user carries by letting them re-use “identities” issued by one organisation when transacting at other organisations.

    I put the magic word in quotes because I think what’s happening is that governments, vendors, commentators etc. are blurring the difference between identity and identifier.

    An identifier is a proxy for your identity in a given context. And your identity in a context loses some or all of its meaning when presented in another context. If I possess an identifier (and a tangible identifying gadget like an OTP or a smartcard) then it’s a beguiling idea that any number of relying parties ought to be able to “trust” that identifier instead of having to issue their own. But this intuition glosses over the fundamental need for each relying party to know the *identity* of the user in their own context, and the reality that no identity in context A can be automatically proxied by the identifier of the user issued in a different context B.

    I am afraid that the casual phrase “open identity” is being misinterpreted, perhaps innocently, by many government and business managers to mean more than standards. They think it means they will be able to deal seamlessly with users on the basis of identities issued to them in other contexts. A casual reading of the Identity Metasystem certainly gives this impression. But it turns out that banks especially really don’t want their OTPs being used by customers to assert “identity” without constraint in other contexts, because they cannot manage the risk. It reminds me of the contractual privity problem that bedevilled early PKI, a problem which I think can only be solved in closed PKI (which is why closed PKI is such a good thing, even if it’s not sexy).

    My experience is that the work and cost required to set the necessary contraints for re-using an identity in other select contexts is much higher than the cost of issuing local identities.

    Cheers,

    Steve Wilson.

    [Reply]

    Stephen Wilson Reply:

    Hi Paul,

    I’ve been thinking more about another point:

    “If you look at non-identifier claims (e.g. age-over-18, is-heart-surgeon, credit-score-over-650, etc.) you see that they can come from an ‘open’ set of providers”.

    I reckon that the set of natural providers of these types of assertions is not actually ‘open’ to a very great degree. I would look to drivers licence bodies, healthcare registration bodies, and credit agencies respectively to vouch for the examples you cite. These bodies are limited in number to such a degree that if they were aligned to CAs, one could readily compile “trust lists” good enough to anchor maybe 95% of transactions.

    This goes to one of my concerns about U-Prove. This was claimed to uniquely prove “unanticipated identity assertions”, and that might well be true. But I don’t get the importance of *unanticipated* assertions.

    Take “is-heart-surgeon” for instance. There might be a few dozen recognised authorities that could realistically make this assertion. So if I’m trying to transact with someone on the basis of there being a heart surgeon (that is, my system *anticipates* that I will need to know whether or not a Subject is a heart surgeon for a given transaction), then it’s really very simple to manage this. We don’t need anything as complex as an open identity architecture (or U-Prove). If a surgeon has a digital certificate issued by a recognised authority, the CA trust list needed in the relying party software is quite small, stable and manageable. Extra manageable when you think about the fact that relying party software in a bounded community like healthcare transactions can easily be configured in advance to know about the small set of relevant CAs and Certificate Policies.

    So I guess I am appealing to planners and architects to make better use of mature PKI processes and components for credentialling, before we re-write everything (including legal contracts) to adopt the identity metasystem and its ilk.

    I presented a paper that touched on the untapped power of closed PKI at the NIST IDtrust workshup two years ago: http://bit.ly/a6IFWw.

    Cheers,

    Steve Wilson, Lockstep, Australia.

    [Reply]

    Comment by Stephen Wilson — April 11, 2010 @ 7:22 am

RSS feed for comments on this post. TrackBack URI

Leave a comment

Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

(required)

(required)


Powered by WordPress