My all-time favorite post from this blog is ‘Dr. Who and the Psychic Paper’.  After this long period of silence, I would like to focus a few posts on the concept and vision of the psychic paper and how today’s authentication, authorization, security and identity management initiatives fit within this vision. 

Over the next few weeks, I intend to discuss:

Authentication Initiatives: Security Assertion Markup Language, OAuth and Fast Identity Online Alliance (FIDO)Federated Identity Management and Trust Frameworks:  This includes the overall concept, as well as specific initiatives such as Kantara InitiativeFast Identity Online Alliance (FIDO), the National Strategy for Trusted Identity in Cyberspace (NSTIC) and Open ID.

Along the way, while describing these large initiatives, I will also cover other related topics such as passwords, biometrics, two-factor and back-end risk-based authentication solutions.

To set the stage, below I briefly define and discuss some of the current methods of authentication, authorization, security and identity management. 

Authentication:  Determination of the level of confidence that the user is the rightful owner of a credential.
An average consumer logs into dozens of different apps or sites every day, with most of them requiring a username and password in order to do so. To cope with this system, the majority of users will reuse passwords across many different sites and / or use easy-to-remember ones.  These two natural human behaviors make our credentials vulnerable to brute-force attacks and social engineering.
To overcome these limitations, a number of sites are starting to use two-factor and back-end risk-based authentication tools - such as Google and Facebook - but we are a long way from widespread adoption of these solutions.  In addition, are there more natural, less intrusive, ways to authenticate?  Does it make sense for each app and site to try to authenticate me or should they rely or one, or a number, of ‘authentication authorities’.Identity:  An individual’s uniqueness – the set of attributes (biological, biographical…) associated with a user.
A person can, and normally does, have many different online / virtual identities depending on the app or site with which she is interacting – a bank, a social network, a streaming site…  Each identity is normally created in isolation, with the amount of information shared and the number of times the identity is reused depending on the importance that trust, reputation and privacy have for each type of interaction.
Is there a better and easier way for consumers (and institutions) to create and manage identities?Authorization:  The specific access rights given to an individual’s identity.
Once a user has been authenticated and the credentials linked to her identity, the system can determine the actions she can take – check an account balance, make a purchase, post a comment, download a song…
The type of action allowed (make a transfer vs. post a comment) will determine the level of authentication required.Security:  Level of protection of the credential, identity and authorization messages.
There are two main paths to securing this information – Encrypting the communication channel – For example, with session level encryption via SSL.  One of the key flaws to this approach is that, although the message is protected while in the channel, it can be vulnerable as it enters and leaves the channel.  There may be points along the way of the transmission where data transitions out of one encrypted tunnel and into the next, at that point in time, the data is no longer in an encrypted session and is vulnerable to theft. 
Encrypting the data - In data-level encryption, the payload is encrypted. That is, encryption is applied to sensitive data elements.  The best-case scenario in this case would be to have end-to-end encryption, so that the data is protected every step of the way and unreadable to anyone other that the holder of the decryption key.
Data encryption requires considerations for key management, including who holds the keys, how they are generated / distributed / rotated and how the keys are protected when stored. Encrypting the data and the communication channel - When possible, it is best to utilize both levels of encryption together, that is to have the payload - or at least the sensitive parts of the payload - within the tunnel encrypted.  
This quick overview prepares us for a more in-depth discussion on specific technologies and initiatives.  I will start the next post of this series by covering SAML and OAuth in the next post.