Attestation

Full Title

Attestation is a certified form of access checking or labeling that gives users or services the information needed to ascertain the trustworthiness of an entity.

Context

Goals

• The immediate goal is that the user of the service recognize the value of conformance to the framework profile.
• The end goal is safety and privacy for the end users at an acceptable level of user experience and enterprise cost.

Components

This is a taxonomy of the components, that might be attested, ordered in increasing levels of specificity.

• Framework - in this wiki a trust framework that provides principles.
• Profile - details on the application of the framework to a specific vertical or horizontal group of entities.
• Service - a digital web site or collection of sites or endpoints that offers services to entities, both digital and (through agents) real-world
• Endpoint - a single digital address providing a specified set of services
• Application - a collection of software that provides a service to entities, both digital and (through agents) real-world
• Device - a specific type of computing hardware with specific features specified in a profile.
• Instance - an identified application on an identified device or endpoint

It is recognized that there are hybrids components, like web apps that are an application downloaded into a user agent on a device; but these can be handled by the above taxonomy if some overlap is permitted.

Problems

It is far too easy for a web site to make a set of claims or mimic a well know brand to trick a user into performing actions that are against their intentions or best interests.

Solutions

The best attestations are performed by a Trusted Third Party that is known to a community of users. This will involved at least a framework profile and a service. As the service branches out to increasing levels of security and privacy it is likely that more levels of specificity, as outlined above, will be desirable.

Framework or Profile Attestation

These are both as set of rules that others might follow. They are attested by a couple of methods:

1. The creators of the artifacts themselves evaluate the effectiveness as the are typically subject matter experts (SMEs) in the field.
2. Wide implementation is a prerequisite for any standard artifact to gain credence.
3. Bug reports and updates are needed to be sure that as new attacks succeed against the integrity of conformant sites, these must be addressed in a timely fashion.
4. At then end of the cycle success is measured by the relative safety of the users of sites conformant to the artifacts.

Self Attestation

• All attestation regimes start with a list of "features" that must be supported in order to gain the right to display an attestation mark. It is important that candidate service understand the cost and benefit of the Attestation before they undertake the effort to acquire the mark or badge or API response that shows conformance.
• Self attestation can be recorded and the results can be evaluated and posted. This is the way that the initial IDEF registry is implemented. They do have a concierge service to help with the process, but the results are submitted by the site owner.

Audited Attestation

• Some attestation will required an audit, others will allow the audit to be made at the option of the service. In any case it is critical that the user of the service understand the value of the attestation. This is potentially the hardest problem and the one that the Framework Management Office take the most care to develop.

Availability of Attestation

The means of validating an attestation must be publicly accessible without cost as the trustworthiness of the service provider must be evident to the user before any sort of transaction even gets underway. This is necessitated by the ability of web sites to spoof well-known sites. That type of attack can only be mitigated by giving the user of the service the data they need for ascertaining the quality of the service before engaging in any significant way.

Example of Audit Attestation

The CA/B Forum was created to give users evidence of the safety of browsing on the web. From the beginning of the standardization of attestation rules they have involved audit firms and the results have been fairly good. As always in such confederations, compromises were made and the user's voice was not often heard, but still the long term success of the web is due, in part, to the work of this forum in establishing rules for the identification of web sites.

Example Device-App

Most mobile devices, like smart phones, have a strict policy of attestation before they will allow apps to be offered for down-load on their app stores. It is always possible to find other ways to load apps on smart phone, but it is deliberately difficult so that ordinary users will not bother with loading any app that is not attested by the O/S vendor, Android and Apple for smart phones. The Framework that each uses is unique to the O/S vendor, but the underlying framework for the web is coordinated by a common underlying platform that nearly all now support. One component of that attestation is a "home" endpoint on the web that can intereact with the app.

Example Authentication

The OpenID Foundation has a framework for authentication called OpenID Connect they also work with industry teams to create specific profiles for industries like the Financial Grade API profile. They have also created a certification program that will test an implementation by way of the endpoints on a web site. More than one endpoint is required to create a full implementation. They do list applications that have been used to obtain certification. But they do not attest that applications are conformant because there are so many ways to implement an application on a web site that it would have no meaning.