Trustmark: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
 
(4 intermediate revisions by the same user not shown)
Line 12: Line 12:
#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.
#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.
#The user can stipulate their own conditions on which they are willing to interoperate with the site.
#The user can stipulate their own conditions on which they are willing to interoperate with the site.
===The Value Proposition of the [[Trustmark]]===
# Users can understand the meaning of the message about the risk to their privacy.
# Users can understand the commitment that the web site has made to security.
# Enterprise partners can know the depth of the commitment each has made to risk reduction.
# The value of the federation is to provide some metric as to the depth of that commitment.


==Problems==
==Problems==
Line 30: Line 36:


===Possible implementation details===
===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]].
*The [[Trustmark]] will be included in an <img> element with a tag (perhaps a new HTML property or method) 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.
*At competition of page load browsers will have a method 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.
*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 [[Identifier]]s, e.g. tid:// (if it is a URI) or just tid: (if it is a URN) similar to the did: (which is a URN).
*A new schema is developed for trusted web site [[Identifier]]s, e.g. tid:// (if it is a URI) or just tid: (if it is a URN) similar to the did: (which is a URN).
Line 41: Line 47:
==References and Coordination==
==References and Coordination==
*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 The Trust wiki page] is dedicated to collecting information about Trust in a digital environment.
*[[Identifier]]s are considered to be unique within their name domain and only apply to a digital [[Entity]]. Real-world names may be listed as [[Attribute]]s of a digital [[Entity]].
*[[Identifier]]s are considered to be unique within their name domain and only apply to a digital [[Entity]]. Real-world names may be listed as [[Attribute]]s of a digital [[Entity]].
*[https://developers.google.com/web/updates/2018/11/signed-exchanges Google now has a trusted ID for docs.] This depends on the publisher's URL (which I understand the Google Chrome browser is moving away from) and an ID for a [[Web Site]].
*[https://developers.google.com/web/updates/2018/11/signed-exchanges Google now has a trusted ID for docs.] This depends on the publisher's URL (which I understand the Google Chrome browser is moving away from) and an ID for a [[Web Site]].

Latest revision as of 02:40, 12 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 primary goals of this effort are to establish a trusted identity:

  1. The user can unambiguously determine the real-world identity (as a real-world Entity name) responsible for any web site that has any pretense to be trustworthy.
  2. The user knows the context that the site operates by the rules of the federation(s) to which the site has subscribed (many need to follow link for details.
  3. The user knows that if the Trustmark is present that it is tested to be valid by the browser (UX will clearly show if not valid)

The secondary goals of this effort are to establish the rules by which the interaction proceeds.:

  1. 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.
  2. The user can stipulate their own conditions on which they are willing to interoperate with the site.

The Value Proposition of the Trustmark

  1. Users can understand the meaning of the message about the risk to their privacy.
  2. Users can understand the commitment that the web site has made to security.
  3. Enterprise partners can know the depth of the commitment each has made to risk reduction.
  4. The value of the federation is to provide some metric as to the depth of that commitment.

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) based as much as possible on the OpenID 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 (perhaps a new HTML property or method) that can be recognized by the browser as indicative of a Trustmark.
  • At competition of page load browsers will have a method 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:// (if it is a URI) or just tid: (if it is a URN) similar to the did: (which is a URN).

Connecting to the IDEF Registry

The wiki page Trust Framework Membership Validation#Federation_Operator contains information on how the Federation Operator would respond to queries from a Web Site or User Agent. One possible outcome of this effort is the formation of a single Trust Registry that would serve as the root of trust for all Web Site addresses.

References and Coordination