Trustmark: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
Line 35: Line 35:
*Much more detail is on the page [[Trustmark Evolving Design Pattern]], which may not be fully up-to-date.
*Much more detail is on the page [[Trustmark Evolving Design Pattern]], which may not be fully up-to-date.
*[https://tcwiki.azurewebsites.net/index.php?title=Trust This wiki page] is dedicated to collecting information about Trust in a digital environment.
*[https://tcwiki.azurewebsites.net/index.php?title=Trust This wiki page] is dedicated to collecting information about Trust in a digital environment.
*Georgia Tech published a [https://trustmarkinitiative.org/specifications/trustmark-framework/1.2/tfts-1.2.pdf Trustmark Framework Technical Specification] (2017-11-06)
*Georgia Tech published a [https://trustmarkinitiative.org/specifications/trustmark-framework/1.2/tfts-1.2.pdf Trustmark Framework Technical Specification] (2017-11-06) that is focused on XML, but the fields are still helpful.
[[Category:Glossary]]
[[Category:Glossary]]
[[Category:Profile]]
[[Category:Profile]]

Revision as of 23:05, 5 November 2018

Full Title

The purpose of a Trustmark is to give the users of a web site sufficient information to make an informed decision about whether the site is trustworthy.

Context

Users of the internet today face a daunting array of risks each time they land on a website, including the possibility of the misuse of personal information, outright fraud or theft of credentials, to infection of their computers with malware or viruses.

The goals of this effort are to enable:

  1. The user can unambiguously determine the real-world identity of any web site that has any pretense to be trustworthy.
  2. The user knows the context that the site operates by the federation(s) to which the site has subscribed.
  3. The user can clearly determine the purpose of the web site, especially in regard to the intent of the site to use their personal information.
  4. The user can stipulate their own conditions on which they are willing to interoperate with the site.

Problems

  • Users do not pay attention to existing Trustmarks.
  • Users not understanding the purposes or meaning of Trustmarks.
  • Existing Trustmarks are trivial to copy on sites that are not trusted.
  • Web site URLs can be spoofed as a result of the many alphabets that are now supported on the web.

Solution

The following are the current characteristics of the new Trustmark:

  1. The mark is cryptographically bound to an Identifier of the current web site which is linked to, but not the same as, its URL.
  2. The Identifier of the site has a signed certificate of membership in the framework that issued the Trustmark.
  3. The companies that report on web site safety (Microsoft, Google, Apple, etc.) are informed of the conditions under which the Trustmark is issued.
  4. The W3C is encouraged to standardize on the method to validate Trustmarks and encourages members to mark any website misuse of the Trustmark as unsafe.
  5. The OpenID Json Web Token (JWT) for federation specification.
  6. Kantara proselytizes not only the adoption of the W3C rules, but actively recruits sites to prominently feature the Trustmark and to assist in educating the meaning and benefits to users.

Possible implementation details

  • The Trustmark will be included in an <img> element with a tag that can be recognized by the browser as indicative of a Trustmark.
  • At competition of page load browsers will check for the tag so that they can run a check on the cryptographic binding of the mark.
  • If the check fails two events will occur, the header of the browser will flag the site as unsafe, a message will be sent by the browser to any user authorized malware checker.
  • A new schema is developed for trusted web site Identifiers, e.g. tid:// or just tid: similar to the did:.

References and Coordination