Pragmatic Cybersecurity unpublished

Pragmatic Cybersecurity unpublished

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

Exploring Identity; it's more interesting than you may think.

Now, discussions of identity can rapidly descend into unproductive philosophy.  But at the same time it is important that we all have an understanding of what is meant by identity and, in particular, that a digital identity is distinct from the physical real-world entity to which it relates.  Identity is not as straightforward as you may think when you start to dig into what we tend to mean by the term…
Kim Cameron wrote a seminal blog entry around identity a few years back – his Laws of Identity.  Within the Laws of Identity he defined digital identity as “a set of claims made by one digital subject about itself or another digital subject”.   This is important.   Identity is defined as a set of claims.  Not a set of indisputable facts grounded in solid reality.  Identity is a set of claims – I am Lee Newcombe.  If you want me to prove it to you then I will show you my passport or my driving license to validate my claim – perhaps both!  This validation only works though because you trust the authorities that issue passports and driving licenses and the claims that they make that the person in the photograph is actually Lee Newcombe.  Furthermore you doubt my ability or desire to forge the documentation, buy forged documentation off someone else or else go to the effort of creating or hijacking an identity to enable me to obtain legitimate documentation with respect to a false identity.  At the end of the day, you either directly trust the claim that I make or you directly trust the claim of the authorities issuing the documentation that I use to validate my own claim.  It all comes down to trust and the willingness to accept a reasonable level of doubt.
Now, as if Identity was not complicated enough you tend to find that we all actually have separate identities, or personas, that we use in different contexts.  Sometimes those contexts and the claims that we make to verify that the personas belong to us overlap.  Sometimes they don’t.  The bullets here list a set of possible personas that I could claim are mine:
  • Employee
  • Husband
  • Father
  • Elven Wizard
  • Citizen
  • Customer
  • Shadowy criminal mastermind
At least one of these is not actually true!  But in the context of school meetings, I am a parent.  In the context of HMRC I’m a taxpaying citizen.  In the context of Capgemini, I’m an employee.   In each context I would use a different set of claims to verify my identity.
So far, so verging on philosophy.  Why do we actually need these identities and personas?
Primarily – to establish relationships.  If Amazon are going to ship me a PS4 before the end of the year, then they need to know who I am, where I live and details of my payment card to verify my claim that I can afford to pay for it!  If HMG are going to pay me benefits once Capgemini realise that I’m a fraud then, again, I will need to be able to prove to HMG that I am entitled to the benefits that I am claiming.   Certain sectors have stronger requirements in this space, e.g. financial services firms have strong requirements to know their customers as part of anti-money laundering regulations.
But, as I stated earlier on, we all have multiple personas and it is not necessary for any one party with whom we wish to establish and maintain a relationship to know all of the claims that we can make about all of our different personas.  I’m sure I’d cause a quizzical look or two if I presented my claim as a level 72 wizard when verifying my right to a UK passport.
So, what we can do is to maintain our personas in different places – different Identity Providers. We can then store claims relating to different personas in different Identity Providers for use in different contexts.    That’s fine from an individual perspective.  From a corporate perspective, you then need to pick and choose which Identity Providers you are willing to trust to provide access to your corporate or customer-facing systems.
But we can be more granular about this.  Do we always need to present an entire persona?  Sometimes it’s only necessary for individuals to be able to demonstrate one particular claim.  Age is usually a good example.  An establishment selling alcohol only needs to know that I am over the age of 18 – they don’t need to know who I am.  Age in this example is an attribute.  We have other attributes – do I have a valid driving license for example?  Sometimes it may be that the users of identities, i.e. those providing us with a service, need independent verification of our claims and would prefer these attributes to be provided directly by the issuing authorities.  Such authorities are known as Attribute Providers.    Of course, it all comes down to trust again.  If an attribute provider is willing to assert that I am tall, dark and handsome (never mind wealthy) then I would suggest that they are no longer worthy of your trust!
So, that’s the theory done and dusted.  I’ll likely write a future post about how these concepts apply when you start thinking about using federated identity management to control access to your applications and data.  In the meantime, if you’re looking for more detail about how to actually go about verifying and validating a claimed identity then you could do an awful lot worse than looking at the Cabinet Office documentation produced as part of the Citizen Identity Assurance Programme over at:
Until next time…

About the author

Ian Cole
Ian Cole
Ian has been employed with Capgemini since 2006 and during this period has been assigned on a number of public and private sector projects within the various market sectors. Ian’s security interests are in information assurance/protective security; he also has a penchant for deciphering security speak to simple English targeted at a CxO level. Ian is a Security Cleared consultant with over 15 years experience in information security. He has an MSc in IT Security and is a member of CESG’s Listed Advisor Scheme (CLAS), an Associate Member of Institute of Information Security Professionals (IISP), a Certified Information Systems Security Professional (CISSP), a Certified Information Systems Auditor (CISA) and an ISO27001 Lead Auditor.

Leave a comment

Your email address will not be published. Required fields are marked *.