• 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

Kaliya Young · November 30, 2014 · 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

Kaliya Young · November 30, 2014 · 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

Kaliya Young · November 30, 2014 · 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

Kaliya Young · November 30, 2014 · 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

Kaliya Young · November 30, 2014 · 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
 

Field Guide to Internet Trust Models: Four Party Model

Kaliya Young · November 30, 2014 · 6 Comments

Four-Party Model

A four-party model provides a comprehensive set of interlocking legal contracts that detail roles, responsibilities, and technical methods. In order to take part in the network, each party must agree to one of the contracts in a given framework. Identity providers specialize in providing support for particular roles.

Examples: The credit card networks, such as Visa and Mastercard, are implemented as four party networks. These represent a large collection of individuals and institutions, each of which must routinely trust participants they’ve never encountered before.

Parties of all types continually join and leave the network, making it impractical for any single organization to track them all. By creating a standard set of well defined roles that work together, the Visa and Mastercard enable risk assessors to specialize.

Because of the vast difference in the size of the entities involved (anywhere from an individual person to a multi-national corporation), and the complexity of governing law, no single contract could be both complete and understandable by all parties.

To solve this problem, the network created a comprehensive, interlocking set of contracts that lay out all of the roles that entities can play. For each role, the appropriate contract specifies the interactions and responsibilities. The network design allows for multiple identity providers, each of whom can specialize in managing risk for a particular set of users. Risks are managed at the system level.

When to use: Closed network where all parties can be expected to sign a contract to join.

Advantages: Enables a network where participants of different sizes can interact smoothly with one another. Allows for specialization of risk management in a complex, constantly changing network where participants frequently join and leave.

Disadvantages: Depends upon the ability to create comprehensive contracts. Risk management can impose substantial costs on the network.

Ability to scale: Four party models can scale to a large number of participants.


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: Inter-Federation Federations

Kaliya Young · November 30, 2014 · 3 Comments

[Image Coming]

Inter-Federation Federations

When organizations are unable to communicate directly with one another because of legal limits or national boundaries, existing federations can negotiate inter-federation federations which allow members of different federations to interact with one another.

Examples: REFEDS, eduGAIN, and Kalmar2 are inter-federation programs for research institutions and higher education.

When to use: Institutions are unable to form direct relationships with one another because of legal or national boundaries, but have existing federations that can negotiate on their behalf.

Advantages: Federations can act as agents, negotiating for members to simplify the complexity of getting agreement among a large number of institutions.

Disadvantages: The complexity of negotiating inter-federation agreements slows the process and may limit the interactions that are covered.

 


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: Mesh Federation

Kaliya Young · November 30, 2014 · 6 Comments

Mesh Federation

A Mesh Federation provides a legal and policy umbrella so that institutions can interact with one another but does not specify technical methods. Each member organization issues digital identities for its people and the federation agreement provides the legal framework for them to use one another’s resources. The federation agreement might specify governance, policy, or roles, but the member institutions are free to implement using whatever technologies they like. This is referred to as a mesh because participating services connect directly with one one another in order to authenticate identities. For contrast, a federation network that provides a central identity clearing house is referred to a Technical federation (discussed below).

Examples: Mesh federations were pioneered by educational institutions. Universities already had a culture of cooperation and realized that the interest of students and research goals of faculty were best served by the free flow of information. NRENS (National Research and Education Networks) around the world include InCommon in the US, SurfnNET in the Netherlands, and JISC/Janet in the UK.

When to use: Large institutions wish to share resources and can agree on roles and governance, but do not need a central point for authenticating identity.

Advantages: Federation participants don’t need to negotiate custom agreements with every other member.

Disadvantages: Because of the need to gather broad adoption, mesh federations may be limited to the most common roles and might not cover complex use cases.

Ability to Scale: Because the mesh federation provides a standard contract, it scales to a large number of members.


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: Federations

Kaliya Young · November 30, 2014 · 4 Comments

Federations

A Federation provides a standard, pre-negotiated set of contracts that allow organizations to recognize identities issued by one another. A federation agreement might specify user roles, governance, security and verification policies, or specific technical methods. The federation is organized around a Contract Hub, which is responsible for the agreements. Organizations with similar goals or structure create a standard agreement rather than negotiating individually.

When to Use: A large number of organizations can agree upon roles and governance, and can create a standard contract.

Advantages: Organizations can recognize identities that one another issue without having to negotiate individual agreements with every party.

Disadvantages: Not customized for individual member organizations. Because of the need to create an agreement that a large number of parties can agree to, the federation might be limited to lowest common denominator roles.

Ability to Scale: Very high.


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: Winner Take All

Kaliya Young · November 30, 2014 · 5 Comments

3Party

“Winner Take All” Three Party Model

A special case of the three party model where the service provider wants to allow the requester to use an existing identity, but only accepts authentication from a defined set of providers. Participants sign an agreement with the identity provider, which also allows them to talk to one another.

Examples: Apple completely controls the channel between app vendors and iPhone users, deciding which applications are available and which users are allowed to use them. Spotify and Zynga games depend upon Facebook for authentication.

When to Use: The service provider wants to take part in a large, established channel, or requires a high level of assurance.

Advantages: The requester can use an existing identity, which lowers the amount of effort required to use a new service. The service provider gets access to the users of an identity network without having to manage the accounts itself. Some identity providers offer higher security than the service could practically provide on its own.

Large three-party model identity providers like Facebook, Google, and PayPal dedicate substantial resources to security.

Disadvantages: Because participants can only interact if they have been authenticated by a single identity provider, that provider wields substantial power. The identity provider effectively controls the requester’s ability to use other company’s products. For instance, a requester who loses their account with the identity provider also loses all of the services where they used that identity. If you use your Facebook to sign in to other products then you also lose those other products if your Facebook account is closed.

Conversely, a service provider that depends on a single third party identity provider leaves themselves open to the third party deciding to change its terms.

Ability to Scale: Difficult to get started because it is only interesting to service providers when it has consumers, but only interesting to consumers if it can offer interesting services. Once they are established and functioning, however, a successful identity provider can build a very large network.


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: Bring Your Own Identity

Kaliya Young · November 30, 2014 · Leave a Comment

A special case of the three party model where the service provider specifies the technical methods that it will accept, but allows the requester to choose any identity service they like. The service provider does not set details for identity verification or authentication and simply assumes that the requester has chosen one that’s good enough for their purposes. The service provider and requester agree to terms, the requester and the identity provider agree to terms, but the service provider does not make any agreement with the identity provider.

Examples: The most common Bring Your Own Identity technologies are SAML, OpenID, and email address verification.

When to Use: The service provider does not want to bear the cost of managing the requester’s identity, or wants to simplify account creation and sign-in.

Advantages: The requester can use an existing identity rather than having to create a new one for this service. If the requester chooses a good identity provider, the service gets the benefit of higher security with no additional cost.

Disadvantages: The account is only as secure as the authenticating service. The service provider depends on the user to select a trustworthy identity service.

Designing a user interface that allows the user to specify an identity provider has proved to be difficult. Consumers don’t generally have the experience to know a good identity provider from a bad one so, in practice, they depend upon seeing a familiar brand. When OpenID was first introduced, supporting sites attempted to help by listing a large set of brands so that the user could choose a familiar one. The resulting products ended up so festooned with logos that they were likened to NASCAR cars, and ended up being more confusing than helpful.

Ability to Scale: Very high.


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: Three Party Model

Kaliya Young · November 30, 2014 · 3 Comments

Three Party Model

A trusted third party provides identities to both the requester and service provider. In order to interact with one another, both must agree to trust the same identity provider.

Examples: Google, Facebook, American Express, Paypal, Amazon, iTunes App Store


 

There are two broad types of Three Party Model. If one (or both) of the parties insists on a particular identity provider, we refer to it as a Winner Take All network because other identity providers are locked out. If only technical methods are specified and the requester is free to specify any identity provider they like, we refer to it as a Bring Your Own Identity network.

When to Use: An identity provider may choose to offer a three party model when it can provide identities more efficiently than the requester or service provider can on their own. Requesters and service providers may choose to implement a three party network for access to an existing market.

Advantages: Separates identity management from the service being provided. In cases where a shared third party is available, this model simplifies the process of exchanging trusted identities. Malicious actors can be identified and isolated from the entire network. Requesters can use a single identity with many service providers, and service providers can trust requesters without having to verify each one.

Disadvantages: Because participants can only interact if they have been authenticated by a single identity provider, that provider wields substantial power. The identity provider effectively controls the requester’s ability to use services and the services’ ability to work with requesters.

For instance, a requester who loses their account with the identity provider also loses all of the services where they used that identity. If you use your Facebook to sign in to other products then you also lose those other products if your Facebook account is closed.

Ability to Scale: Very difficult to get started because a three party network is not interesting to service providers until it has users, but only attracts users if it has interesting services. Once they are established and functioning, however, a successful three party network can grow extremely 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: Pairwise Agreement

Kaliya Young · November 30, 2014 · 7 Comments

Two institutions want to trust identities issued by one another, but there is no outside governance or policy framework for them to do so. They negotiate a specific agreement that covers only the two of them. Each institution trusts the other to properly manage the identities that it issues.

Examples: A pairwise agreement can specify governance, security and verification policies, or specific technical methods.

Businesses might negotiate pairwise agreements with large supplier. Educational institutions may craft specific research agreements.

When to Use: Business or institutional partners want to grant one another access to confidential systems or information, but no standard contracts or umbrella organizations exist.

Advantages: Organizations can grant one another access to scarce resources and confidential information. Highly customized for the specific situation and participants.

Disadvantages: Time consuming and complex to negotiate, expensive. Difficult to scale.

Ability to Scale: Pairwise federations do not scale well, because each additional party will need to make a custom agreement with every other party.


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: Centralized Token Issuance, Distributed Enrollment

Kaliya Young · November 30, 2014 · 2 Comments

A special case peer-to-peer network. Participants want to establish trusted identities that can be used securely for ongoing, high-value communication among organizations. A trusted, central provider issues identity tokens which are then enrolled independently by each service provider. Service providers are not required to cooperate or accept one another’s enrollments.

Examples: The most common examples are RSA SecurID and SWIFT 3SKey. Hardware tokens are issued by a trusted provider, which are then used to authenticate individual identities.

Each service will require the user to enroll separately, but once the user has registered they can use the token for future interactions.

When the requester wants to use a service, they’re authenticated using the token.

When to use: Strong Authentication across a range of business entities who may have different enrollment requirements.

Advantages: Can provide a high level of identity assurance to institutions spread across legal and national boundaries.

Disadvantages: Can be expensive and complex to implement. Depends upon the existence of a trusted third party who can issue and ensure the security of hardware tokens. Hardware tokens can be lost.

Ability to scale: Can scale to large networks.

 


 

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: Peer-to-Peer Trust and Identity

Kaliya Young · November 30, 2014 · 2 Comments

Peer-to-Peer Identity

When no central identity provider or governance agreement is present, participants assert their own identities and each individual decides who they trust and who they do not. Each participant is a peer with equal standing and each can communicate with anyone else in the network.

Examples: The most familiar peer-to-peer network is probably e-mail. An internet host can join the e-mail network with little more effort than updating its DNS entry and installing some software. Once a host has joined the network, individual e-mail addresses are easily created with no requirement for approval by any central authority. This flexibility and ease of account creation helped spur the growth of the internet, but also allows spam marketers to create false emails.

The best known secure peer-to-peer identity networks on the Internet have been implemented using public key cryptography, which allows participants to trust messages sent over insecure channels like email. Products like PGP and it’s open source counterpart gpg are the most common implementations of public key messaging tools.

When To Use: No central identity provider is available but network participants can exchange credentials.

Advantages: No dependence on a central identity provider. No formal agreement needed to join the network. Participants can assert any identity that they want. Secure peer-to-peer technologies can provide a high degree of confidence once identities have been exchanged. Peer-to-peer models are very flexible, and can support a wide range of trust policies.

Disadvantages: No governing agreement or requirement to implement any policies. Secure deployment requires a high degree of technical sophistication and active management. Individually verifying each participant can be labor intensive. Tracking identities that have been revoked can be complex and error prone.

Ability to Scale: If security requirements are low, peer-to-peer networks can grow very large because new members can join easily. Higher levels of security can be complex to deploy and operate, and can impose a practical limit on the size of the network.


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

Starting on the OASIS IDtrust member steering committee

Kaliya Young · September 12, 2011 · Leave a Comment


I started a new “job” last week, serving on the OASIS Identity and Trusted Infrastructure (IDtrust) Member Section, member steering committee.  I was elected to a 2 year term on this 5 member board.  This was my candidate statement and remains as my profile. On my first call as a member of the committee I was part of approving 8K of money including sponsoring the upcoming Interent Identity Workshop.
I shared with my fellow board members

  • Peter Alterman – National Institute of Health
  • Bruce Rich – IBM
  • John Sabo – CA Technologies – Chair
  • Anil Saldhana – Red Hat

in my introductory call that I was keen to link this work with other work that is related and ongoing at other standards efforts like the W3C where I have been participating in the Federated Social Web work.  There is also independent efforts like OpenID and OAuth happening within IETF.  One of our next tasks at Personal Data Ecosystem Consortium is to outline the core standards relevant to personal data.  We are not going to invent anything new – rather help what is be found and adopted and adapted.
Why Does participation in an International Standards body matter?

If “code is law,” then standards are like the Senate.  – Bruce Sterling, commenting on the April 2011 Augmented Reality Standards gathering

[Read more…] about Starting on the OASIS IDtrust member steering committee

Google+ and my "real" name: Yes, I'm Identity Woman

Kaliya Young · July 31, 2011 · 25 Comments

When Google+ launched, I went with my handle as my last name.  This makes a ton of sense to me. If you asked most people what my last name is, they wouldn’t know. It isn’t “common” for me.  Many people don’t even seem to know my first name. I can’t tell you how many times I have found myself talking with folks at conferences this past year and seeing ZERO lighbulbs going off when I say my name “Kaliya”, but when I say I have the handle or blog “Identity Woman” they are like “Oh wow! You’re Identity Woman… cool!” with a tone of recognition – because they know my work by that name.
One theory I have about why this works is because it is not obvious how you pronounce my name when you read it.  And conversely, it isn’t obvious how you write my name when you hear it.  So the handle that is a bit longer but everyone can say spell “Identity Woman” really serves me well professionally.  It isn’t like some “easy to say and spell” google guy name like Chris Messina or Joseph Smarr or Eric Sachs or Andrew Nash. I don’t have the privilege of a name like that so I have this way around it.
So today…I get this

I have “violated” community standards when using a name I choose to express my identity – an identity that is known by almost all who meet me. I, until last October, had a business card for 5 years that just had Identity Woman across the top.

Display Name – To help fight spam and prevent fake profiles, use the name your friends, family, or co-workers usually call you. For example, if your full legal name is Charles Jones Jr. but you normally use Chuck Jones or Junior Jones, either of these would be acceptable. Learn more about your name and Google Profiles.

[Read more…] about Google+ and my "real" name: Yes, I'm Identity Woman

Trust is at all time low in they West….why leading with "trust frameworks" might not work

Kaliya Young · July 28, 2011 · 1 Comment

The ID Coach has this quote at the top of her current blog post:

…trust indices in the Western world are at an all time low. We don’t trust our lawyers, or accountants — they shred lots of documents. Many believe that bankers recently brought the world economic system to its knees in the crisis of 2008 and subsequent recession. Most people aren’t too enamored of politicians, either.

It is from the current issue of the Harvard Business Review in an article about trust.
It makes another very clear point about why leading with the word “trust” to describe “trust frameowrks” when the institutions touting them are the very ones that people have skepticism about (lawyers, accountants, bankers) as a good way to solve all our problems online by having people prove who they are.
People don’t want to accept “trust” blindly form these institutions they want to understand how it works and then decide if they do trust it or not.  Asking questions about accountability seems much easier to be concrete about the actual mechanics that then may are may not be trustworthy.

Accountability Framework – renaming "Trust Frameworks"

Kaliya Young · July 19, 2011 · Leave a Comment

I challenged the choice of the phrase “trust frameworks” to describe policy/technology frameworks that have the goal of creating networks of interoperability in the question and answer part of the NSTIC governance workshop.  Jeremy Grant challenged me to think of a better name for  “trust frameworks” and I think I found it…

Accountability Frameworks

So far everyone I have shared this with likes this new potential name.
* It is 2 words.
* It captures the heart of the intention behind their purpose – Accountability
* Accountability is achieved in these frameworks via both technology standards and policies that are adopted and audible.
* Trust remains an emergent property of these accountability frameworks.
* There can be real conversations by various stakeholders who may have different needs and interests about the nature of the accountability in different frameworks. They can look to see weather particular accountability frameworks are trustworthy from a particular point of view.
* It avoids the problem of talking about the “trustability of trust frameworks”.

Trust Talk

Kaliya Young · August 4, 2006 · Leave a Comment

So I am here at yet another conference – the ever wonderful National Coalition on Dialogue and Deliberation. I just had to post this as soon as I saw it in the swag bag – TrustTalk (tm) – everybody’s talkin’ about it…

  • Trust in the works place
  • But what is it?
  • Which one of the hundreds of models of trust do you want to adopt?
  • How do you help a team talk about trust and collaboration without it turning into therapy? Or so squishy that no one knows what it means?
  • We’ve done the research for you!

So if you want I can bring this nifty little deck to our next Identity Gang meeting and we can see what it might add to our thinking about trust…catch is that the deck of cards cost $75. I am up for it if others thing it might be worth a shot.
I also find that my entire lens – frame of looking at everything is impacted by ‘identity’ and the work of our community in addressing it on the web. I don’t know if I will ever look at the world the same again.
Back to NCDD… I heard rave reviews about there first conference 4 years ago. I went to there second one 2 years ago and now I am here at number three and liking it so far. This year I am presenting on Social Media Tools: How They Fit Together Supporting Community & Conversation. At the very end I might mention why SSO would be cool but this is more about how it can help fit all those tools together.
And for those of you who are tracking these things this will be the fourth one in the last seven days (OSCON, BlogHer, Advocacy Developer 3 and now the National Coalition on Dialogue and Deliberation) [and for those of you concerned about this trend I am not going anywhere beyond they Bay Area until the 16th then I am on vacation for a week at a ‘leadership workshop at a heavenly retreat center’ then it back to FooCamp and off to Burning Man]

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

  • Terms of Use
  • Privacy Policy
  • Sitemap
  • Contact