Trust over the Internet is vital but current solutions are imperfect. This scenario creates an environment for innovative approaches deserving of patent protection. This article explores trust over the Internet and how patents can protect innovative solutions.
Generally, trust means having certainty in the character, ability, strength, or truth of someone or something. That is a adequate definition for communications over the Internet, as well. However, the amount of trust needed may depend on the service provided. As a service provider, you may not need to trust a service requester if, for example, your service is simply providing a weather forecast. But you do need to trust the service requester if, for example, you are performing an action that has immediate financial consequences.
Trust can be based in part in the manner of authentication, which is the concept of identifying an entity. Authentication can involve, for example, entering a user identifier and password. However, you might not want to keep track of passwords for every site you visit, so you could simply authenticate to a trusted authentication service. When you visit a site that requires authentication, the authentication service can vouch for you. The site accepts your identity because it trusts the service.
The preceding scenario can be implemented, for example, using the Security Assertion Markup Language (SAML), a standard ratified by the Organization for the Advancement of Structured Information Standards (OASIS). In the SAML model, the trusted service is called the identity provider (IdP) and the site is a relying party (RP). The concept of avoiding multiple passwords is called web browser single sign-on (SSO).
Returning to the consequences of performing an action on behalf of a requester, how much do can you trust an entity?
One aspect is the way the entity authenticated to the IdP. Authentication might require a simple password or multiple forms of identification (multifactor authentication). For example, you use two factor authentication at any ATM; something you have (the ATM card) and something you know (your password). So how much you trust the IdP might correspond to the type of authentication it used.
A second aspect is how much effort did the IdP take to identify the true identity of the entity it is vouching for? This process, called person proofing, can range from a personal appearance with a drivers license at a registrar (high) to simply believing the name entered when creating an account at the IdP (low). This range is described as the level of assurance and is discussed in National Institute of Standards and Technology (NIST) "Electronic Authentication Guideline" Special Publication 800-63-2. So how much you trust the IdP might correspond to the level of assurance the IdP used to originally investigate the identity of the user it is vouching for.
A third aspect is the how confident you are communicating with the true IdP. You may trust an IdP but you have to be confident the IdP is not being impersonated. This confidence can depend on the technology being used to identify the IdP, which could be a shared secret, an asymmetric key pair, or some other mechanism where key management, computational trust, and cipher selection can limit the chances of impersonation. So how much you trust the IdP might correspond to the underlying technology.
So how much should you trust the entity before performing an action on behalf of a requester?
The Department of Defense released an instruction (DoDI 8520.03) that gives some perspective. Trust necessarily depends on the sensitivity of the information, the cryptographic credentials proffered, and the environment the entity is communicating from. As the Figure shows, if you are in an untrusted environment (Internet cafe) you can't be trusted beyond acts that have minimal consequences. If confidence in the communication channel increases, you can be trusted at a higher level, depending on how strong your credentials are (signified by the letters A-H).
Instead of rejecting requests from entities, you may trust a party only to a certain point then require more evidence of trustworthiness if the consequences of the request are too great. This technique is called trust elevation and can require, for example, a stronger credential, different IdP, or more confidence in the network the IdP is communicating over.
An example is patent 8,893,293, Elevating Trust in User Identity During RESTful Authentication. The inventors allow authentication using credentials passed in a Representational State Transfer (REST) front channel then augment that information with additional (cryptographically signed) information over a secured network. Although the need for trust mechanisms has been researched for years, inventors can still apply for a patent that describes a novel improvement in trust-related technologies.