This article explains more about the different parts of the British Columbia Citizen Consultation about their “identity card’ along with how it is relevant and can inform the NSTIC effort. [Read more...]
This is the first in a series of posts that cover the Field Guide to Internet Trust Models Paper.
The post for each of the models is here – full papers is downloadable [Field-Guide-Internet-TrustID]
The decreasing cost of computation and communication has made it easier than ever before to be a service provider, and has also made those services available to a broader range of consumers. New services are being created faster than anyone can manage or even track, and new devices are being connected at a blistering rate.
In order to manage the complexity, we need to be able to delegate the decisions to trustable systems. We need specialists to write the rules for their own areas and auditors to verify that the rules are being followed.
This paper describes some of the common patterns in internet trust and discuss some of the ways that they point to an interoperable future where people are in greater control of their data. Each model offers a distinct set of advantages and disadvantages, and choosing the appropriate one will help you manage risk while providing the most services.
For each, we use a few, broad questions to focus the discussion:
- How easy is it for new participants to join? (Internet Scale)
- What mechanisms does this system use to manage risk? (Security)
- How much information the participants require from one another how strongly verified?
(Level of Assurance -not what I think assurance is…but we can talk – it often also refers to the strength of security like number of factors of authentication )
Using the “T” Word
Like “privacy”, “security”, or “love”, the words “trust” and “identity”, and “scale” carry so much meaning that any useful discussion has to begin with a note about how we’re using the words.
This lets each link the others to past behavior and, hopefully, predict future actions. The very notion of trust acknowledges that there is some risk in any transaction (if there’s no risk, I don’t need to trust you) and we define trust roughly as:
The willingness to allow someone else to make decisions on your behalf, based on the belief that your interests will not be harmed.
The requester trusts that the service provider will fulfill their request. The service provider trusts that the user won’t abuse their privileges, or will pay some agreed amount for the service. Given this limited definition, identity allows the actors to place one another into context.
Trust is contextual. Doctors routinely decide on behalf of their patients that the benefits of some medication outweigh the potential side effects, or even that some part of their body should be removed. These activities could be extremely risky for the patient, and require confidence in the decisions of both the individual doctor and the overall system of medicine and science. That trust doesn’t cross contexts to other risky activities. Permission to prescribe medication doesn’t also grant doctors the ability to fly a passenger airplane or operate a nuclear reactor.
Trust is directional. Each party’s trust decisions are independent, and are grounded in the identities that they provide to one another.
Trust is not symmetric. For example, a patient who allows a doctor to remove part of their body should not expect to be able to remove parts of the doctor’s body in return. To the contrary, a patient who attempts to act in this way would likely face legal sanction.
Services and APIs change faster than anyone can manage or even track. Dealing with this pace of change requires a new set of strategies and tools.
The general use of the term “Internet Scale” means the ability to process a high volume of transactions. This is an important consideration, but we believe that there is another aspect to consider. The global, distributed nature of the internet means that scale must also include the ease with which the system can absorb new participants. Can a participant join by clicking “Accept”, or must they negotiate a custom agreement?
In order to make this new world of user controlled data possible, we must move from a model broad, monolithic agreements to smaller, specialized agreements that integrate with one another and can be updated independently.
A Tour of the Trust Models
The most straightforward identity model, the sole source, is best suited for environments where the data is very valuable or it is technically difficult for service providers to communicate with one another. In this situation, a service provider issues identity credentials to everyone it interacts with and does not recognize identities issued by anyone else. Enterprises employing employees, financial institutions, medical providers, and professional certifying organizations are commonly sole sources. Because this is the most straightforward model to implement, it is also the most common.
Two sole sources might decide that it’s worthwhile to allow their users to exchange information with one another. In order to do so, they negotiate a specific agreement that covers only the two of them. This is called a Pairwise Agreement and, while it allows the two parties to access confidential resources, the need for a custom agreement makes it difficult to scale the number of participants. This is also a kind of federated identity model, which simply means that a service accepts an identity that is managed someplace else.
As communication technology became more broadly available, the number of institutions who wanted to communicate with one another also increased. Groups of similar organizations still wanted to issue their own identities, but wanted their users to be able to interact freely with one another. The prospect of each service having to negotiate a custom agreement with every other service was daunting, so similarly chartered institutions came up with standard contracts that allow any two members to interact. These groups are called Federations, and there are several different kinds. Federation agreements and membership are managed by a Contract Hub.
When the federation agreement limits itself to policy, governance, and common roles, but leaves technical decisions to the individual members, it’s referred to as a Mesh Federations. Individual members communicate form a mesh, and can communicate directly with one another using whatever technology they prefer.
Alternatively, a Technical Federation defines communication methods and protocols, but leaves specific governance and policy agreements to the members. In some cases, the technical federation may also route messages between the members.
As the number of services has increased, so has the problem of managing all of those usernames and passwords. Users might decide to reuse an existing identity rather than creating a new one. In recent years, some organizations have made identities that they issue available to other services. Service providers accept these identities because it lowers the cost of user acquisition. When the same entity provides identities for both the requester and the service provider, it is referred to as a Three Party Model.
If the requester and the service provider have provider have separate but compatible identity providers, it is called a Four Party model. This is present in highly dynamic models, such as credit card processing,
Peer-to-peer networks are for independent entities who want to identity assurance, but who lack a central service that can issue identities to everyone. To get around this, the participants vouch for one another’s identities.
Individual contract wrappers are an innovation to enable complex connections between services where the terms and conditions of using the data are linked to the data.
Common Internet Trust Models
Sole source: A service provider only trusts identities that it has issued.
Pairwise Federation: Two organizations negotiate a specific agreement to trust identities issued by one another.
Peer-to-Peer: In the absence of any broader agreement, individuals authenticate and trust one another.
Three-Party Model: A common third party provides identities to both the requester and the service provider so that they can trust one another.
“Good Enough” Portable Identity: In the absence of any institutional agreement, service providers accept individual, user-asserted identities.
Federations: A single, standard contract defines a limited set of roles and technologies, allowing similar types of institution to trust identities issued by one another.
Four-Party Model: An interlocking, comprehensive set of contracts allows different types of entity to trust one another for particular types of transaction.
Centralized Token Issuance, Distributed Enrollment: A shared, central authority issues a high-trust communication token. Each service provider independently verifies and authorizes the identity, but trusts the token to authenticate messages.
Individual Contract Wrappers: Manage how personal data is used rather than trying to control collection. Information is paired contract terms that governs how it can be used. Compliance is held accountable using contract law.
Open Trust Framework Listing: An open marketplace for listing diverse trust frameworks and approved assessors.
Personal Cloud + Agents: An Individual has a personal Cloud and delegates agents it trust to work on their behalf.
The Identity Ecosystem Steering Group is a multi-stakeholder organization (See this post about how join.) Technically You can participate on lists even if you are not members but it is better that you go through the process of joining to be “officially” part of the organization.
If you join the IDESG it is good to actively participate in at least one active committee because that is where organization work is done by committees – any person or organization from any stakeholder category can participate.
The committees have mailing lists – that you subscribe to (below click through where it says Join Mailing list and put in the e-mail address you want to use, share your name and also a password).
On the list the group chats together on the list and talk about the different work items they are focused on. They have conference calls as well to talk together (these range from once a week to once a month). You can also contact the chair of the committee and “officially” join but that is not required.
If you are reading this and getting involved for the first time – read through this list and pick one of the committees that sound interesting to you. They are friendly folks and should be able to help you get up to speed – ask questions and ask for help. This whole process is meant to be open and inclusive.
My response, two years ago to the NSTIC (National Strategy for Trusted Identities in Cyberspace) Program Office issued Notice of Inquiry about how to govern an Identity Ecosystem included a couple of models that could be used to help a community of companies & organizations in an ecosystem co-create a shared picture. A shared co-created picture is an important community asset to develop early on because it becomes the basis for a real conversation about critical issues that need to be addressed to have a successful governance emerge.
The Privacy Committee within NSTIC has a Proactive Privacy Sub-Committee and before I went on my trip around the world (literally) a month ago. I was on one of the calls and described Value Network Mapping and was invited to share more about the model/method and how it might be used.
Value Network Maps are a tool that can help us because both the creation of the map and its subsequent use by the companies, organizations, people and governments that are participating strengthens the network. This is important because we are dealing with a complex problem with a complex range of players. In the map below we are in the top left quadrant – we NEED strong networks to solve the problems we are tasked with solving. If we don’t have them we will end up with Chaos OR we will have a hierarchical solution imposed to drive things towards the complicated and simple but …given the inherent nature of the problem we will NOT fully solve the problem and fall off the “cliff” on the edge between simplicity and into chaos.
So – what is a Value Network Map?
It models technical & business networks by figuring the roles in any given system and then understanding the value that flow between different roles. Value flows include payment for the delivery of goods or services (these are tangible deliverables) but also intangible deliverables such as increased level of confidence because information was shared between parties (but was not contractually obligated and no payment was made).
Drawing from Verna’s book/site that lays out how to do it. There are four steps to a value network map.
1. Define the scope and boundaries, context, and purpose.
2. Determine the roles and participants, and who needs to be involved in the mapping.
4. Validate it is complete by sequencing the transactions.
I’ve worked on several value network mapping projects.
I worked with the Journalism that Matters to document he old and new journalism ecosystem.I have lead several community Value Network Mapping efforts.
This projects highlights how the method can be used to talk about a present/past state about how things happen “now”. How do people today or 20 years ago share verified attributes with business and government entities one does business with? If we understand the roles that exist in a paper based version/world How do those roles change in a future enable with technology and how do the value flows change and what new roles are created/needed?
A value networm map can be used to map the flow of rights and duties between different roles in an ecosystem can also be considered along with the flow of monetary and other value.
Two years ago I went with Verna Allee (the innovator of the method) to the Cloud Identity Summit to work on a map for my organization the Personal Data Ecosystem Consortium focused on the “present state” map to explain what currently happens when someone visits a website and clicks on an add to go buy something and then is asked to provide identity attributes.
We took this FCC submitted map that has the individual at the center and data flows to the businesses, government and organizations they do business with and is sold on to Data Brokers and then Data Users buy it to inform how they deal with the individual all without their awareness or consent.
Our hope was to do this and then work on a future state map with a Personal Cloud provider playing a key role to enable new value flow’s that empower the Individual with their data and enabling similar transactions.
This is best viewed in PDF so if you click on the link to the document it will download.
Creating this map was an interactive process involving involved two dozen industry professionals that we met with in small groups. It involved using large chart paper paper and post-it notes and lines on the map. We came into the process with some of the roles articulated, some new roles were added as we began mapping with the community.
An example to give you a sense of what it looks like when you do it in real life is this map that shows how trust frameworks & the government’s reduction of risk in the credit card system.
This was a small piece of the original map for the Personal Data Ecosystem (it did not end up getting included in the PDF version). The roles are the orange flowers and the green arrows are tangible value flows and the blue arrows are intangible value flows.
So how could the Proactive Privacy Sub-Committee use this method?
At an IIW11 one of the practitioners of value network mapping came to share the method and we broke up into smal groups to map different little parts of an identity ecosystem. We had a template like this picking four different roles and then beginning to map.
The exercise is written about here on Verna’s website.
Scott David was a community member there and really saw how it was a tool to understand what was happening in systems AND to have a conversation about the flow of rights and responsibilities flow.
The method is best done face to face in small groups. It helps if the groups are diverse representing a range of different perspectives. A starting point is a use-case a story that can be mapped – what are the roles in that story and then walking through the different transactions.
So how do we “do” it. Well a starting point is for those interested in helping lead it to identify themselves in the context of the pro-active privacy committee. We should work together to figure out how we lead the community using this process to figure out the privacy implications and see where the money flows for different proposed solutions.
We can try to do a session at the upcoming July or October plenary.
We could also organize to do some meetings at:
- conferences in the next few months were we can identify 5-10 interested IDESG members to participate in mapping an ecosystem chunk for an hour or two.
- in cities around the country where we identify 5-10 folks who want to spend an hour or two mapping an ecosystem chunk.
It would be great if we decide to do this that the Secretariat lead by Kay in her role as Executive Director of the IDESG can support us in organizing this (That is why we are paying htem 2.5 million buck s to help us do the work of organizing in a meaningful way.
I am friends with Verna Allee and can ask her for advice on this however I think the kind of help/advice we need to really use this method and do it WELL would behove us to actually use NSTIC IDESG moneys to hire Verna to engage with us in a serious way. When I wrote my NSTIC NOI I did so thinking that their would finally be monies available to pay people to do community conference building work like this. Perhaps it is not to late to do so.