Difference between revisions of "Federation Trust Registry"

From MgmtWiki
Jump to: navigation, search
(→‎Fraunhofer)
(→‎Fraunhofer)
Line 49: Line 49:
 
* [https://essif-lab.eu/essif-train-by-fraunhofer-gesellschaft EESIF Fraunhofer TRAIN project]<blockquote>Our component aims to extend the ESSIF-Framework through a global trust infrastructure that can be used to verify the trustworthiness of involved parties in an electronic transaction. The trust layer enables actors using the ESSIF-Framework to verify the root of trust of certificates used to sign credentials. In addition, the component allows for the definition, consideration, and verification of Trust Schemes compliance (e.g. eIDAS including LoAs or other Trust Schemes that can also be application/industry-specific) of involved parties. It is not dependent on a hierarchical CA infrastructure.</blockquote>
 
* [https://essif-lab.eu/essif-train-by-fraunhofer-gesellschaft EESIF Fraunhofer TRAIN project]<blockquote>Our component aims to extend the ESSIF-Framework through a global trust infrastructure that can be used to verify the trustworthiness of involved parties in an electronic transaction. The trust layer enables actors using the ESSIF-Framework to verify the root of trust of certificates used to sign credentials. In addition, the component allows for the definition, consideration, and verification of Trust Schemes compliance (e.g. eIDAS including LoAs or other Trust Schemes that can also be application/industry-specific) of involved parties. It is not dependent on a hierarchical CA infrastructure.</blockquote>
 
* [https://essif-lab.pages.grnet.gr/essif-lab/docs/open_calls/ EESIF open call]
 
* [https://essif-lab.pages.grnet.gr/essif-lab/docs/open_calls/ EESIF open call]
 +
* [https://essif-lab.github.io/framework eSSIF-Lab Framework]
  
 
===Example Data Elements===
 
===Example Data Elements===

Revision as of 15:33, 15 October 2021

Full Title or Meme

Wherever a Web Sites wishes to take advantage of the benefits of belonging to a Federation it needs to be exposed in a Data Service that allows any user to ensure that the Web Site has been Validated by the Federation, or, at the very least, subscribed to the federation's principles.

Context

Several variations on the theme of a Federation Trust Registry exist already.

  • Trust Services of TSCP the Transglobal Secure Collaboration Program (mostly focused on NATO A&D industry).
  • UK Open Banking (focused on UK banks and payment processors) Trust Registry is run by the FCA.
  • Recognized Coordinating Entity (RCE) (focused on the US Health Care community.)[1] See the page on TEFCA.

When a US federal federal agency's mission requires that it disseminate controlled unclassified information (CUI) to non-executive branch entities, but prohibits it from entering into a contractual arrangement, the agency is nevertheless directed to seek the entity's protection of CUI in accordance with Executive Order 13556, Controlled Unclassified Information, or any successor order, and the CUI Program regulations, which include requirements to comply with NIST SP 800-171.

Standards must be implemented, potentially with a profile, to ensure that the result is "as consistently as possible, follows implementation guides and authoritative best practices published by the applicable standards development organization (SDO). Minimizing variation in how standards are implemented will make it easier for others to connect to Electronic Health Information. Further, to the extent possible, Electronic Health Information stored in health IT products should be structured and coded using standardized vocabularies."[1]

Problem

  • Users and participants in an Identity Federation need to understand in real-time whether any particular web site is conformant with federation rules. Or, in other words, the user must be aware of the rules that apply to their current activity.
  • So far every solution has been one-off and not applicable to the next federation with the same general problem.
  • Most user's experience with Internet Security is sub-optimal or worse. Trust Registries might be able to address at least some of the security challenges.

Solution

There will be a Nationwide, or Global, registry of all compliant federations. That is able to answer queries about whether any Web Site is currently compliant. Queries can have specific site Identifiers or any character sting that will return a list of participants that meet the query. This services is specifically designed to be user friendly.

In order that a Federation can be expose both is principles and its membership to the public some data server needs to provide information about the existing membership and their status. There are two ways to do this:

  1. A list of the members and their status that can be viewed in a browser.
  2. A data service that exposes the contents of the site in machine readable format.

This page is about the later case.

Of primary importance for a Federation that wants to allow user's to trust the members, is some easily accessible data service on a site that meets the following criteria[2]

  1. Reliable, always-on accessibility.
  2. Meta-data descriptions of the contents of any federated Web Site.
  3. Machine readable data as well as meta-data (called Service-Enabled Data Store).
  4. Data Security
  5. Contains no User Information and does not track the user, but is expected to respond Anonymously to User queries.

Federation Profile

Each federation will need to create their own set of specifications for determining those Web Sites and Subjects that may be registered. While that could be an independent effort, this page address those federations that define a Framework Profile of the IDEF registry. Only with a single rooted tree of registries can the user be sure of the source of trust. It is possible for the federation to break the Framework Profile into separate documents for security, privacy and interoperability as UK Open Banking did.[3]

Each federation will support one or more Federation APIs that will enable any communicating Entities on the web to query the current status of each member. The Federation API page describes different sets of goals that depend on the purposes of the api, either technical or experiential.

Use Cases

Working Sample Site

The work product can be viewed at this site. The Kantara demo registry can be viewed at this site. It is currently focused on Healthcare apps.

Accreditation Services

For high assurance Trust Registries, some sort of Accreditation Service is required to evaluate the members to assurance compliance.

Fraunhofer

  • EESIF Fraunhofer TRAIN project
    Our component aims to extend the ESSIF-Framework through a global trust infrastructure that can be used to verify the trustworthiness of involved parties in an electronic transaction. The trust layer enables actors using the ESSIF-Framework to verify the root of trust of certificates used to sign credentials. In addition, the component allows for the definition, consideration, and verification of Trust Schemes compliance (e.g. eIDAS including LoAs or other Trust Schemes that can also be application/industry-specific) of involved parties. It is not dependent on a hierarchical CA infrastructure.
  • EESIF open call
  • eSSIF-Lab Framework

Example Data Elements

The following is extracted from a representative collection of existing Trust Registries. Including those at the GCCN registry page.

Element Name OIDC mdl description
issuer iss VI entity identifier of the issuer of the statement. If the iss and the sub are identical, the issuer is making a statement about itself.
Roles Need a formal taxonomy, e,g, Federation Trust Authority
jurisdiction Laws that apply, e.g. us-WA
Basis of trust Laws or other governance
subject sub DN The entity identifier of the subject
subjurl sub DN The URL of the subject, could be.a did or the common name from a cert
start date iat nbf The time the statement was issued
end date exp naf The date/time the statement expires.
public key jwks cert the public part of the subject entity's signing keys.
recipient aud  ?? audience
metadata metadata ?? metadata
policy metadata_policy ?? policy
trust anchor trust_anchor_id ?? entity id
logos trust_mark ?? These logos can be displayed on the providers web sites to allow informed user choice

Submittter Data Elements

The following is extracted from a representative collection of existing Trust Registries.

nam|| iss||VI|| || e.g. submitter.corp.com address|| |||| in the standard format name, strte, city, provide, country, potal code
Element Name OIDC mdl description
mail Need a formal taxonomy, e,g, user@example.com
jurisdiction Laws that apply, e.g. us-WA
subjurl sub DN The URL of the submitter, could be.a did or the common name from a cert (optional)
public key jwks cert the public part of the subject entity's signing keys. (Optional)
metadata metadata ?? for example, president of company, etc.
trust anchor trust_anchor_id ?? entity id

References

  1. ↑ 1.0 1.1 The Office of the National Coordinator (ONC) for Health Information Technology, DRAFT TRUSTED EXCHANGE FRAMEWORK. (2018) Section 2 - How Will it Work p. 9ff https://www.healthit.gov/sites/default/files/draft-trusted-exchange-framework.pdf
  2. ↑ Michael J. Carey +2, Data Services (2012-06) CACM 55 No 6 Pp. 86-97
  3. ↑ UK Open Banking OIDC Security Profile. https://bitbucket.org/openid/obuk/src/4630771db004da59992fb201641f5c4ff2c881f1/uk-openbanking-security-profile.md?at=master&fileviewer=file-view-default

External Sources

Retrieved from "http://tcwiki.azurewebsites.net/index.php?title=Federation_Trust_Registry&oldid=12588"