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.

Who Sez? An Alternative ID Ecosystem Viewpoint

A debate continues to simmer in IDESG about the nature of an Identity Ecosystem; there are many points of view and opinions. For an organization like IDESG, a unified concept must emerge.

Approaches to define the Identity Ecosystem include: setting a baseline of requirements that must be met by ecosystem participants; definition of trust marks; Internet nutrition labels; establishing a formal certification process; creating the ability for ecosystem participants to advertise their security, privacy and other capabilities; functional models; interaction models; protection levels; assurance levels; self-selection; independent attestation; and the list goes on.

Let me suggest and explore another way to perceive and describe an ID Ecosystem aligned with the NSTIC Guiding Principles.

A common thread that links the above-listed approaches together is that each one declares one or more Authorities that determine if the prospective ecosystem participant’s policies, technologies and operations are compatible with the NSTIC Vision.

Following this line of thought, envision a governance structure that seeks to influence the behaviour of the Authorities that grant rights of access and recognition to ecosystem participants. Rather than IDESG attempting to define and quantify every action, implementation or intent in the entire ecosystem, why not define the rules of being an Authority and certify those entities wishing to be Authorities?

What would an Authorities-driven Identity Ecosystem look like?
(and, remember that what follows is a rosy view biased to my ways of conceptualizing the ecosystem)

  • Authorities exist that can certify or recognize ecosystem participants that adhere to that Authority’s rules
    • Authorities create and manage rules that are compatible with NSTIC Principles
  • Authorities become authoritative when a) they demonstrate rule compatibility to an IDESG Authority and b) entities decide to follow their rules and ‘join’
  • Each Authority would decide how to certify or recognize their participants – some might use formal Trust Framework Provider methods, others might allow self-declaration: the choices would be defined in their rules
  • Each ecosystem participant, including the Authorities, is accountable to the Authorities whose rules they follow

Some issues remain:

  • Who sez that the IDESG Authority has any sway over any other entity?

Is this description simply a description of the current internet using different words?

I think it is a new thing because it focuses on approaches to make the IDESG organization and members credible and influential in the internet space.

In order for an IDESG Authority to have any value, a critical mass of significant influential entities must join and put their weight behind the organization. If a critical mass of interesting organizations choose to acknowledge this web of authorities and ways to align to the NSTIC Principles, we begin the positive cycle.

It’s a big ‘IF’. And it’s one of the key assumptions under which IDESG, Inc. was formed.

My opinion: focus the work of IDESG on making it easy for organizations and individuals to demonstrate support for NSTIC. NSTIC’s vision is a good one. Build on existing goodwill to build a source of co-recognition. Reinforce the positive actions that IDESG members take: by getting certifications; by doing regular assessments; by actively protecting privacy and security. IDESG should use inclusive selection methods to increase membership and to create a self-enforcing or peer-enforcing environment:

  • Delegate and distribute ‘authority’ to the communities, federations and other self-identifying groups
  • Avoid over-specification, bureaucracy, self-limiting approaches, command-and-control centralization
  • Educate participants, develop and give them the tools to make informed decisions about the agreements and interactions they wish to use. Make it easier for others to educate about good practices and dangers. Make the safest options easiest.
  • Minimize barriers to entry
  • Reinforce positive behaviours
  • Build goodwill and peer value

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.

New cloudy horizons

Getting going with a new adventure – Cloud Computing interoperability and federation standards. Goes with the theme of learning new things and pushing the brain-case into a new configuration.

Two full days of meetings coming up, setting up a plan, schedule and scope for building a cloud computing testbed to explore new stuff. I’m the project manager for an IEEE initiative.

Having been to a few cloud conferences so far this year, I’m learning that the view that the “cloud” is all about moving enterprise data centres into virtual locations is naive. Yes, virtualization is front and centre. But the hardware, how things are physically wired up, the virtualization software configuration, the data centre location on the planet, and other factors directly impact what the paying customer a) is able to ask for and b) receives. Compute and Storage resources are tailored for specific requirements. ‘Big Data’ analytics require certain configurations, Software as a Service needs others.

The commonality appears to be massively distributed resources. Keeping a very large application set in sync is massively difficult. Cloud providers do not give customers instrumentation or visibility into the virtual-physical interface. Rolling out uniform code to non-uniform hardware must be a nightmare to troubleshoot. But it is necessary.

In any case, I’m working with a team that is looking at how cloud service providers could federate and interoperate in the background – sharing resources to meet demand without customers having to handle the complexity of multi-provider resources.

Every day is a new adventure. It’s the best thing about diving into new waters. Stay tuned.