• Skip to primary navigation
  • Skip to main content

Identity Woman

Independent Advocate for the Rights and Dignity of our Digital Selves

  • About
  • Services
  • Media Coverage
  • Podcast
  • Blog
  • Contact
  • Show Search
Hide Search

Trust Framework

Field Guide to Internet Trust Models: Introduction

November 30, 2014 By Kaliya Young 12 Comments

This is the first in a series of posts that cover the Field Guide to Internet Trust Models Paper. The paper was presented at the University of Texas at Austin ID360 Conference in 2013.
This paper was collaboration between myself and Steve Greenberg. I had an outline of all the Trust Models and worked with Steve Greenberg for several months to shape it into the paper.
The full papers is downloadable TrustModelFieldGuideFinal (see the bottom of this post for a link to a post on each of the models).
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.
Internet Scale
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.

“Bring your Own” Portable Identity: In the absence of any institutional agreement, service providers accept individual, user-asserted identities.

“Winner Take All” Three Party Model: Service provider wants to allow the requester to use an existing identity, but only accepts authentication from a single or very limited set of providers.

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.

Mesh Federations: These share a common legal agreement at the contract that creates permissible interoperability.

Technical Federations:  These share a common technical hub responsible for making the interoperability happen.

Inter-Federation Federations: This is what happens when one federation actually inter-operates with another federation.

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.
 

Field Guide to Internet Trust Models: The Sole Source

November 30, 2014 By Kaliya Young 8 Comments

Sole Source

A Sole Source is an organization that acts as identity provider (IdP) and relying party (RP) for itself. This organization issues all identities that it recognizes, and only trusts identities that it has issued.
An organization like this does not federate identities at all. Because it does not connect to anything else, this model is sometimes referred to as a Silo, an Identity Island, or a Standalone Domain. The service provider performs its own verification and dictates governance, privacy, and technical terms to all participants.
There is minimal – if any – negotiation between the requester and the service provider. The service provider manages the entire account lifecycle from creation through retirement.
Examples
Historically, this has been the most common identity model because it can be implemented simply and gives the service provider the most control. Large, consumer-facing services like eBay, Facebook, and Yahoo! were created with sole source identity, although many are adopting newer models as internet technology has evolves. Internal corporate services are often sole source, and only accept identities issued by the organization.
The Sole Source identity model
Financial services, and health insurance, are likely to remain sole source identity providers until a strong, multifactor identity gains momentum with consumers and liability questions are settled. There have been several attempts to do this, but none has yet achieved critical mass.
Being a sole source provider does not guarantee account security, as end users may simply give their account login and password to a third party. Tricking users into giving up account information is a common tactic used by “phishing” sites and other criminals, but legitimate services like Mint.com (a US-based financial service provider) also ask for credentials in order to combine information from sites that do not provide APIs.
When to Use
A service that maintains particularly confidential information or valuable assets, or that operates in an uncertain environment. If proper operation and risk management requires a high level of assurance, then consider being a sole source.
Advantages
The service provider can authenticate requesters to whatever level of assurance it desires before issuing an identity and does not depend upon third parties.
Disadvantages
The service provider bears the full management cost of the identity life cycle. The requirement to create a new identity may discourage potential users of the service. The service must provide a product attractive enough to justify asking the requester to create and manage a new account.
Ability To Scale
When the service provider does not need to integrate with any other services or when it is in a position to dictate terms, a sole source trust model can scale to very large systems. The requirement to create and remember new identity can be a barrier to growing the number of active users.


The full papers is downloadable [Field-Guide-Internet-TrustID] Here is a link to introduction of the paper and a at the bottom of that post is a link to all the other models with descriptions.  Below are links to all the different models.

Sole source, Pairwise Federation,  Peer-to-Peer,
Three-Party Model 1) “Bring your Own” Portable Identity 2) “Winner Take All” Three Party Model:
Federations 1) Mesh Federations 2) Technical Federations 3) Inter-Federation Federations
Four-Party Model, Centralized Token Issuance, Distributed Enrollment, Individual Contract Wrappers, Open Trust Framework Listing

Field Guide to Internet Trust Models: Open Trust Frameworks

November 30, 2014 By Kaliya Young 2 Comments

A Trust Framework is a specification that describes a set of identity proofing, security, and privacy policies. The framework is authored by subject matter experts, and is written with the intent that compliance can be assessed. The framework also lists the qualifications that an assessor must have in order to judge compliance.

A Framework Listing Service provides a publicly visible location where trust frameworks can be published and tracked. The listing service sets guidelines for acceptable frameworks and accredits assessors to verify that services implement the frameworks properly.

Examples: The Open Identity Exchange (OIX), Kantara Initiative, and InCommon operate framework listing services. A Framework Creator authors a trust framework that specifies identity validation policies and publishes it to a Framework Listing Service. The framework may also specify the qualifications required in order to be a valid assessor of the policy.

When to use: This should be used by networks who share a common set of technology and policy needs but are not in the business of creating technology networks or accrediting compliance.

Advantages: Standard, publicly available specifications that are designed by subject matter experts. Assessors can verify that the frameworks are implemented properly.

Disadvantages: Not broadly supported, evolving model.

Ability to scale: Because each component can be independently updated, a network based on open trust frameworks could potentially scale to be very large.

 


The full papers is downloadable [Field-Guide-Internet-TrustID] Here is a link to introduction of the paper and a at the bottom of that post is a link to all the other models with descriptions.  Below are links to all the different models.

Sole source, Pairwise Federation,  Peer-to-Peer,
Three-Party Model 1) “Bring your Own” Portable Identity 2) “Winner Take All” Three Party Model:
Federations 1) Mesh Federations 2) Technical Federations 3) Inter-Federation Federations
Four-Party Model, Centralized Token Issuance, Distributed Enrollment, Individual Contract Wrappers, Open Trust Framework Listing

Field Guide to Internet Trust Models: Technical Federation

November 30, 2014 By Kaliya Young 4 Comments

In addition to contract terms, a Technical federation also provides a central service that acts as a clearinghouse for identity operations. It routes authentication requests from the service back to the requester’s chosen identity provider, translating protocols as needed. The existence of a central service lowers the technical and administrative costs of participating in the network. For contrast, a federation network where the participants connect directly with one another rather than going through a central clearinghouse is called a Mesh.

Examples: WAYF provides federated single sign-on to Denmark’s higher education, research institutions, and libraries.

When to Use: A large entity is available to act as an identity clearing house.

Advantages: Encourages use of digital identity by providing a central clearinghouse for authentication. Service providers only need to integrate with a single identity provider. Requesters can choose from a variety of identity providers.

Disadvantages: Requires substantial investment that may only be available to very large institutions or states.

Ability to Scale: Can scale to support national identity programs.


The full papers is downloadable [Field-Guide-Internet-TrustID] Here is a link to introduction of the paper and a at the bottom of that post is a link to all the other models with descriptions.  Below are links to all the different models.

Sole source, Pairwise Federation,  Peer-to-Peer,
Three-Party Model 1) “Bring your Own” Portable Identity 2) “Winner Take All” Three Party Model:
Federations 1) Mesh Federations 2) Technical Federations 3) Inter-Federation Federations
Four-Party Model, Centralized Token Issuance, Distributed Enrollment, Individual Contract Wrappers, Open Trust Framework Listing

Field Guide to Internet Trust Models: Individual Contract Wrappers

November 30, 2014 By Kaliya Young 1 Comment

Individual Contract Wrappers

When providing information to a service, the requester also provides terms for how that information can be used. Service providers agree to honor those terms in exchange for access to the data, and compliance is enforced through contract law. Terms might include an expiration date, limits on whether the data can be re-sold, or whether it can be used in aggregate form. This model is the mirror image of the Sole Source.

Examples: Personal.com offers a service that provides end users with a place to store personal data. Service providers agree to abide by a set of agreements in order to use this data.

When to use:

Advantages: Provides an incentive for the requester to provide clear, correct, and up-to-date information. In exchange for accepting limits on how the data can be used, the service provider gains access to better quality and more complete data.

Disadvantages: Emerging technology with evolving standards, not widely supported yet.

Ability to scale: It has a high ability to scale but it is almost a reverse architecture of the Sole Source and some of the same challenge.


The full papers is downloadable [Field-Guide-Internet-TrustID] Here is a link to introduction of the paper and a at the bottom of that post is a link to all the other models with descriptions.  Below are links to all the different models.

Sole source, Pairwise Federation,  Peer-to-Peer,
Three-Party Model 1) “Bring your Own” Portable Identity 2) “Winner Take All” Three Party Model:
Federations 1) Mesh Federations 2) Technical Federations 3) Inter-Federation Federations
Four-Party Model, Centralized Token Issuance, Distributed Enrollment, Individual Contract Wrappers, Open Trust Framework Listing
 

  • Go to page 1
  • Go to page 2
  • Go to page 3
  • Go to page 4
  • Go to Next Page »

     Copyright © 2021 Identity Woman  evelurie.com/web design/develop     

  • Terms of Use
  • Privacy Policy
  • Sitemap
  • Contact