Difference between revisions of "Federated Ecosystem"

From MgmtWiki
Jump to: navigation, search
(Trust Principles)
(Solutions)
Line 29: Line 29:
  
 
===Trust Principles===
 
===Trust Principles===
*The [[User]] must be able to set a level of [[Assurance]] that any site proffered, either on search, or on some other [[Web Site]] will meet that [[Assurance]] level. (eg. COPPA sites only)
+
*The [[User]] must be able to set a level of [[Assurance]] that any site proffered, either on search, or on some other [[Web Site]] will meet that [[Assurance]] level. (eg. [[COPPA]] sites only)
 
*The user must be able to search for a named [[Entity]]'s [[Web Site]] in a manner that will provide only relevant [[Assurance|assured]] links and not links to competitors or malicious sites.
 
*The user must be able to search for a named [[Entity]]'s [[Web Site]] in a manner that will provide only relevant [[Assurance|assured]] links and not links to competitors or malicious sites.
  

Revision as of 16:54, 6 September 2018

Full Title or Meme

A sub-set of sentient and non-sentient components what work together trough some interaction to increase the information content of the local environment.

Context

  • The most current paradigm for digital Ecosystems is the internet taken together with the definitions and components maintained by ICANN, for example the Domain Name System which servers as the root for all URLs used on the internet.
    • As originally envisioned the URL obtained with a name lookup that started with the ICAN root server would result in an Identifier in ASCII that was human-readable.
    • As the internet expanded beyond its original basis in ARPANET, the new languages and cultures turned to the Identifiers returned by the name lookup into something that was easy to spoof.[1]
  • The domain name was defined to be extensible, for example endpoint.company.com can be converted to an IP address by the following steps:
  1. ICANN root server will provided a link to the .com domain, which can be considered as a federation of business sites.
  2. .com name server will provide a link to the company.com domain which gets an Enterprise server which hosts a collection of servers controlled by the Enterprise.
  3. company.com server will provide a link to one particular server (perhaps one of many) that can services a request.
  4. endpoint.company.com can initiate further navigation based on the contents of the URL as needed.
  • There are (at least) two ways to look at a Federated Ecosystem:
  1. This page is primarily about open Web Sites including: Relying Party, Identifier or Attribute Provider and Trusted Third Party.
  2. The NIST Public Working Group on Federated Cloud (PWGFC) includes the User which is appropriate for closed systems, like citizens of a country, or employees of a company

Problems

  • So how can a User know enough about a Web Site to make a trust decision about it.
  • As noted above[1] the URL has failed in its goal to be human-readable as it was pulled in other directions.
  • EV Certs were established with a view to solve this problem, but have failed for reason noted on that page.

Solutions

  • A Federated Ecosystem considers how to partition the solution into federations using the existing paradigm of the DNS, but starting from a source of Trust and maintaining that Trust as the federation Evolves.
  • Unlike the priorities for the original ARPANET, we consider the primary purpose to be a Trusted Identity in Cyberspace.
  • As a working hypothesis we will consider the use case where the federation creates Identifiers based on a new secure schema, it is to be expected that other use cases will be considered before a final paradigm shift is established to a fully Federated Ecosystem.
  1. The root of trust is a singleton, all federations must accept the baseline functional requirements.
  2. A variety of trust frameworks, or trust profiles, can be established, the base one is the self-assessment criteria.
  3. It is possible that further branching can occur after the first.

Trust Principles

  • The User must be able to set a level of Assurance that any site proffered, either on search, or on some other Web Site will meet that Assurance level. (eg. COPPA sites only)
  • The user must be able to search for a named Entity's Web Site in a manner that will provide only relevant assured links and not links to competitors or malicious sites.

Trust Hierarchy

The following is a hypothetical trust hierarchy for the health care framework (profile). Each descendant branch is limited by all of the frameworks above it. In other words, the limitations on the Entity only get more stringent.

  1. baseline functional requirements
    1. United States Health care framework.
      1. Hospitals
        1. ER
        2. Psyciatric
      2. Individuals
        1. First Responders on active duty
        2. Physicians
          1. Cardiaologist(perhaps this is an attribute and not a part of the taxonomy)
        3. Nurses
        4. Practitioners
        5. DEA licensed prescription writers (perhaps this is an attribute and not a part of the taxonomy)
      3. Pharmacies
      4. Labs

It should be clear that individual entities have more than one role and so be at more than one node on the tree. The Pharmacy may also be an authorized seller of alcohol registered under some state authority. For any interaction with a user it will be important that the role is clear. What is not clear is how the user should know about the difference between Bartell's the prescription filler and Bartell's the liquor merchant. And it must be clear that the User Experience is the primary metric.

References

  1. 1.0 1.1 Lily Hay Newman, SNEAKY EXPLOIT ALLOWS PHISHING ATTACKS FROM SITES THAT LOOK SECURE. (2017-04-18) https://www.wired.com/2017/04/sneaky-exploit-allows-phishing-attacks-sites-look-secure/