Why is online identity such a hot subject? Thoughts on current trends.

Interesting trends are emerging in the Online Identity circles I travel. One trend is the shift away from formalized, enterprise, centrally-regulated Federations towards ad-hoc, consumption-driven, transaction-oriented architectures and policies.
On one hand, I see advancement in ‘formal Federation’, which I will loosely define as a pre-evaluated structuring of centrally defined requirements and criteria, realized as a collection of entities who share common policy, technology and security domain boundaries. It’s the ‘classic’ use case where one enterprise accepts a business partner enterprise’s user authentication.
On the other hand, there is a large thought-community emerging where the central concern is the ‘transaction’: the interaction between online service provider and online service recipient. The transaction-oriented requirements dictate that risk, qualifications and identification should be evaluated at ‘run time’ rather than at ‘design time’. Themes include Attributed Based Access Control, User-managed access, electronic consent notices, step-up authentication and other ‘assertion’ evaluation schemes.
This is a ‘frothy’ situation – there are no pervasive solutions and everyone is attempting to locate the critical problem space which needs fixing. Arguments and philosophical approaches erupt frequently – which is stimulating more energy and effort. A good thing.
One challenge that ‘pure’ Federation cannot address is the ad-hoc nature of online interactions. Predicting which identification authorities and policy enforcers are needed in advance is a wicked problem and is likely to be intractable. However, establishing common protocols and information sharing processes could possibly allow transaction participants to discover enough about their opposite number to do the risk/cost/benefit analysis that us purist security/identity practitioners claim that they always do. (of course nobody actually does this – they do stuff based on past experience and retain the right to investigate suspicious activity.)
OK, so what’s my point?
Simply the axiom that centralization is good for creating the nucleus of common practices required to build critical mass; but the scale and rapid expansion seen in internet-scale technologies and approaches can only occur when the common practices are subsumed into standards and the innovators are thus freed to do unexpected things upon a solid, standardized foundation.
A somewhat strange post, but I think the ‘identity’ industry is currently in the throes of transitioning from ‘central’ to ‘standardized’ even before fully developing what those common practices must be: and that’s why it is such an interesting space to be engaged.

Trust Framework as Information Sharing – A thought experiment

Over the last year, I’ve been thinking about the nature, structure and governance models of Trust Frameworks.

The work that I do with IDESG focused on establishing an ‘Identity Ecosystem’. Which, in effect, means finding ways for existing and new Identity federations, Trust Frameworks and standalone Identity Solutions (the Ecosystem Participants) to exchange information (assertions) with their partners. Ecosystem Participants need to evaluate the risks of accepting the information for use in their decision making processes.

I have closely examined the FICAM Trust Framework Solutions Trust Criteria, NIST standards, the Trust Framework Provider Acceptance Program and Approved Trust Framework Providers’ frameworks, to seek understanding of different approaches to evaluate transaction partners who might become Identity Federation partners. At root, these approaches define requirements that must be met, criteria for conformity evaluation, risk evaluation methods and assessment rules which must be considered when conducting Identity-related online transactions.

A couple years ago, I decided to examine the relationships between components of online Identity Solutions using a very particular lens: the Information Sharing lens. That analysis helped shape conversations with FICAM and Government of Canada about reference architectures and mechanisms to assign roles and responsibilities for identity-related transactions.

I have recently started to immerse myself in the InterPares Trust project:
“InterPARES Trust (ITrust 2013-2018) is a multi-national, interdisciplinary research project exploring issues concerning digital records and data entrusted to the Internet. Its goal is to generate theoretical and methodological frameworks to develop local, national and international policies, procedures, regulations, standards and legislation, in order to ensure public trust grounded on evidence of good governance, a strong digital economy, and a persistent digital memory.” These projects are researching ways to determine digital record authenticity, and other related information management subjects.

What if we look at Trust Frameworks through the information lens?

For this thought experiment, treat everything as an information transmission, processing or storage event. For example, if a user authenticates their credential/token with a verifier, information from the credential/token could be processed, an assertion of ‘logged in’ could be transmitted, and logs stored about the events.

When attempting to transact, subscribers to a Trust Framework seek to:

  • Understand what information is needed of them in order to perform the transaction
  • Do the functions needed to prepare that information and transmit it as needed
  • Specify what information they need, in a way that includes metadata about quality, source, encoding, etc.
  • Acquire the information they need to make transaction or risk decisions
  • Determine the authenticity and sufficiency of the information received, to the degree needed
  • Complete the transaction based on decisions made about the information processed

What if we use the paradigm of Information Sharing Agreements to codify the determinations and statements of ‘need’ in the bullets above?

In my next posts, I will try to look at the sequences of the overall transaction as it relates to information sharing. The information sharing to occur pairwise, under known terms and conditions. In this way, I hope to learn new things about the nature and structure of information sharing agreements covering these transactions.

In this way, I will try to lead the thought experiment through to what Federation Agreements do for participants today, and what model agreements would be of use in an ‘Ecosystem’ trust arrangement.

Portable Identity Information and Interoperable Credentials: How will we shift the burden of complexity away from your mom’s keyboard?

Often-cited target states for federated identity and credential solutions include statements like: “Credentials must be interoperable”; “Identity Information must be portable”; “Users must have choice in number, type and source of credential”; “User must have control over disclosure and use of identifying information”; “Usage of credential must not be traceable back to the user, if the user requires it”.

It occurs to me (and I’m certainly not the first person to realize this) that there is a heavy burden of complexity and risk inherent in solution spaces for those kinds of requirements.

Let me explain:

Today’s nasty conglomeration of multiple username/password silos, 2-step authentication systems, 2-factor authentication systems, attribute verifiers (a.k.a. data brokers) and nascent federated credential solutions actually satisfies many of the requirements statements above.

We are witnessing the rise of the “mega-ID Provider”:  Google, Amazon Web Services, PayPal, Salesforce, Facebook, Twitter and other massive companies are turning up authentication interfaces for consumption by other eService Providers and Relying Parties. They are not particularly interoperable – the NASCAR user interface used to pick your Authentication Provider is proof of this. (Sidebar: I was just informed that the NASCAR is called the NASCAR because of the long line of logos streaming down the UX – I found this tragic and funny at the same time)

What solutions are being promoted to shift the burden of complexity and non-secure credentials away from your mom? (this list is not pure – I’ve shifted some definitions to suit my purposes)

Hubs: an interconnection point that does protocol and information format conversions between many Relying Parties and many ID Providers. This might possibly be IDaaS.

Brokers: a Hub that also offers anonymizing services – directed identifiers provided to RP and IDP in a way that makes it very difficult to capture a comprehensive picture of where a user credential has been used, even with some collusion.

Federated Credentials: IDP and RP using a commonly-agreed set of protocols, policies and trust rituals. Very Enterprise-y where a user is bound to an IDP but in return is able to authenticate anywhere in the Federation.

Active User Agents: User Centric solutions that keep the keys, authorization policies and other complex stuff close to the user. User Agents could collect up a bunch of different ‘identities’ and credentials for use in whatever pattern the user desires.

Personal Clouds: Bits of Personal Cloud functionality could be the Active User Agent role, but cloud based.

So what’s it going to be?

Is the price of convenience and security for you as an Online Consumer-Citizen going to be a transfer of the ‘hard parts’ and complexity over to big Broker/Hubs that promise to do no harm? This might address the harder problems of discovery and provisioning – centralizing integration points is easier to deploy.

Or, will the complexity simply be shifted just a little bit further away from your chair into a User Agent that is under your direction? This gives you more (apparent) control, but makes it harder to get seamless, simple services connected when and where you want them – and decentralized integration will be prone to the problems of today with provisioning, deprovisioning and broken linkages.

What’s in a Trust Framework?

I’ve been having long email discussions over the last month or so about the nature of “Trust Frameworks”. “Trust Framework” is one of those terms that everyone loves to use in the Federated Identity world, but when asked, are hard pressed to come up with a reasonable explanation of what they are and how they work. Equally puzzling is the difficulty in discerning a difference between a Trust Framework and Federated Identity agreements.

There are a few characterizations that I like, especially the American Bar Association Identity Task Force one that a Trust Framework is a set of Operating Rules that include Technical, Business and Legal rules.

I am currently working on a set of white papers that dig into this topic for the Kantara Initiative Identity Assurance Working Group (KI IAWG)

The questions under examination are:

Does the Kantara Identity Assurance Framework (KI IAF) address the needs of service providers seeking Approval under the Kantara Trust Framework?

If not, then what could or should be changed in the Assessment Scheme, the Service Assessment Criteria or Rules of Assessment that would make the KI IAF more flexible or modular in ways that still make sense for Trusted Identity Federations.

Along the way, I have been sidetracked to learn more about Trust Frameworks, Identity Federations and Federated Access Control patterns and architectures. I’ll be sharing bits and pieces of this over the next few blog posts.

But for now, I’ll leave you with a crappy diagram. This diagram is a hypothetical representation of the relationship between the Kantara IAF, Federated Identity models and the assessment criteria that are derived from the underlying models. The premise is: there exist many Federated Identity models. For each model, a set of assessment criteria can be developed. If a service provider demonstrates  conformity to the criteria, then it adheres that that model. It may be possible to describe a “Root” or “Core” model with “Root” or “Core” assessment criteria which form a part of every other model and criteria in that family tree of Federated Identity Models.

In this discussion, it is important to remember that there is more than one way to model Federated Identity. In the circles that I travel at the moment, the US E-Authentication Program (OMB M-04-04 and NIST SP 800-63-2) and the Government of Canada Identity Management models are prevalent. These share common elements such as having 4 Assurance Levels and have differences such as the assignment of functional roles to IDP or RP. However, it is quite simple to describe a common root model with distinct model options and assessment criteria profiles that encompasses both.

Hypothetical relationship between Federated Identity Model and Trust Framework

TF Root Model and SAC