Trusted Third Party

Introduction

This use of the concept of Trusted Third Party here is limited to a digital entity on the internet that can provide a link between a trusted and proofed user (at NIST SP 800 63-3 levels 2 or 3) and a pseudonym that is used to hide the user's real-world identity while still providing access to a User Object that is held by another party. It forms the majority of Trusted Entities and is often used interchangeably with it.

Note that the concept of hiding a user's real-world identity from the identifier that is used with a relying party is described in the Identity Model. This paper describes the case where the third party fully accepts the fiduciary responsibility to hide the user's real-world identity from service providers (aka relying parties).

Context

There are many cases were users want to access data or other resources on the Internet while still assuring that the service provider cannot discover their real identity. Some cases include health related lab tests, minors under the age of consent or people who are being stalked. In particular HIPAA and COPPA require protections that need to be addressed by compliance with technology solutions such as the one described here. This document considers the case where:

1. Internet Providers have data or resources that are known to be protected by statute.
2. Trusted Third Parties agree to both proof the identity of users and to authenticate the user to the appropriate level of assurance resulting in an identity token that is not to be tracked by any service provider to that real-world user.
3. All parties that access the data are bound by legal statutes or agreements to protect the user's privacy to a high level of assurance.

This case is focused on digital access, real-world interactions, like providing health care, may require a real-world identity depending on the policy of the service provider.

The case of vulnerable populations that do not have good real-world identities must be addressed elsewhere.

Problem

• It is well known that only a small amount of personal information can be used to identify a real-world person.
• Real-world users wish to maintain their privacy and still have access to protected data on the internet.
• Real-world users have the right to control to whom and for what reason their personal information is disclosed.

Solution

• Frameworks are established for Protected Health Information (PHI under HIPAA rules), other specific personal data and other protected groups like minors. These frameworks establish rules describing the level of assurance needed to protect user identity.
• Identity Providers (IdPs) are formed that create an identifier that is bound to one proofed real-world identity and are certified to meet the criteria of the relevant framework.
• Service Providers all have their own identifier and are suitable vetted by the framework and can be validated by the framework trust anchor. They can then get an authenticated user's identifier from the IdP.
• The frameworks establish a Trust Anchor on the internet where any interested party can learn the status of any digital entity certified by the framework using the digital entity's identifier.
• It is possible that some recognized trust authority can be used in addition to, or in place of, the framework trust anchor. These are certified by the framework to provide access to verification information,including the level of assurance or confidence associated with the supplied identifier.
• It is always the case that one digital entity can validate another identity as to membership status in the trust framework in real-time using the authorization protocol defined by the trust anchor.

References and Coordination

Trust Elevation Use Case describes one case where a trusted third party could be used to bridge between a pseudonym and a proofed and trusted identity.