Attestation: Difference between revisions
| (18 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Full Title== | ==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. | [[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 or software implementation. | ||
==Context== | ==Context== | ||
===Goals=== | ===Goals=== | ||
* The immediate goal is that the user of the service recognize the value of conformance to the framework profile. | * The immediate goal is that the user of the web platform 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. | * The end goal is safety and privacy for the end users at an acceptable level of user experience and enterprise cost. | ||
| Line 11: | Line 11: | ||
*Framework - in this wiki a trust framework that provides principles. | *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. | *Profile - details on the application of the framework to a specific vertical or horizontal group of entities. | ||
* | *Web Platform - a digital web site or collection of web 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 | *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 | *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. | *Device - a specific type of computing hardware with specific features specified in a profile. | ||
*Instance - an identified application on an identified device or endpoint | *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. | 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. | ||
| Line 25: | Line 25: | ||
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. | 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=== | ===Framework or Profile Attestation=== | ||
These are both as set of rules that others might follow. They are attested by a couple of methods: | These are both as set of rules that others might follow. They are attested (trusted) by a couple of methods: | ||
# The creators of the artifacts themselves evaluate the effectiveness as the are typically subject matter experts (SMEs) in the field. | # The creators of the artifacts themselves evaluate the effectiveness as the are typically subject matter experts (SMEs) in the field. | ||
# Wide implementation is a prerequisite for any standard artifact to gain credence. | # Wide implementation is a prerequisite for any standard artifact to gain credence. | ||
| Line 32: | Line 32: | ||
===Self Attestation=== | ===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. | * All attestation regimes start with a list of required "features" that must be supported in order to gain the right to display an attestation mark. It is important that the candidate service provider 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 [https://idefregistry.edufoundation.kantarainitiative.org/ IDEF registry] is implemented. That registry does have a concierge service to help with the process, but the results are submitted by the web platform owner. | |||
===Audited Attestation=== | ===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 | * 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 any [[Framework Management Office]] take the most care to develop. | ||
===Availability of Attestation=== | ===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 | 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 web sites. That type of attack can only be mitigated by giving the user of the web platform the data they need for ascertaining the quality of the web platform before engaging in any significant way. | ||
====API==== | |||
There will be many applications for both users and services to acquire information about the state of a Web Platform's attestation. It is important that a common means of acquiring that information is published. There exists several federation APIs in both SAML and OpenID that can serve as a template for the API, but there is still a need for a general comprehensive specification. | |||
===Example of Audit Attestation=== | ===Example of Audit Attestation=== | ||
| Line 44: | Line 48: | ||
===Example Device-App=== | ===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. | 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. | ||
Note that this example, like all in this wiki, is oriented around [https://wiki.idesg.org/wiki/index.php/NSTIC_Strategy Trusted Identities in Cyberspace]. Currently available technology requires the connection of the app with authentication to a trusted source on the web. There is no known technology that can provide testable authentication today without a web connection, although it is possible to use a secure portable device for [https://tcwiki.azurewebsites.net/index.php?title=Bootstrapping_Identity_and_Consent Bootstrapping Identity and Consent]. | |||
===Example Authentication=== | ===Example Authentication=== | ||
| Line 51: | Line 57: | ||
==References== | ==References== | ||
[[Category: Trust Framework]] | [[Category: Trust Framework]] | ||
[[Category: Glossary]] | |||
[[Category: Profile]] | [[Category: Profile]] | ||
Latest revision as of 04:47, 23 August 2020
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 or software implementation.
Context
Goals
- The immediate goal is that the user of the web platform 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.
- Web Platform - a digital web site or collection of web 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 (trusted) by a couple of methods:
- The creators of the artifacts themselves evaluate the effectiveness as the are typically subject matter experts (SMEs) in the field.
- Wide implementation is a prerequisite for any standard artifact to gain credence.
- 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.
- 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 required "features" that must be supported in order to gain the right to display an attestation mark. It is important that the candidate service provider 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. That registry does have a concierge service to help with the process, but the results are submitted by the web platform 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 any 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 web sites. That type of attack can only be mitigated by giving the user of the web platform the data they need for ascertaining the quality of the web platform before engaging in any significant way.
API
There will be many applications for both users and services to acquire information about the state of a Web Platform's attestation. It is important that a common means of acquiring that information is published. There exists several federation APIs in both SAML and OpenID that can serve as a template for the API, but there is still a need for a general comprehensive specification.
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.
Note that this example, like all in this wiki, is oriented around Trusted Identities in Cyberspace. Currently available technology requires the connection of the app with authentication to a trusted source on the web. There is no known technology that can provide testable authentication today without a web connection, although it is possible to use a secure portable device for Bootstrapping Identity and Consent.
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.