Framework Profiles: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
 
(15 intermediate revisions by the same user not shown)
Line 6: Line 6:
*As a part of the creation of a set of [[Identity Ecosystem]]s this plan lays out how to address specific community needs for security, privacy, interoperability and user experience. It is expected that all communities will start from the Baseline Functional Requirements (as amended from time to time) and add additional requirements in those four areas plus the potential for a trusted laboratory validation of compliance with the profiles.
*As a part of the creation of a set of [[Identity Ecosystem]]s this plan lays out how to address specific community needs for security, privacy, interoperability and user experience. It is expected that all communities will start from the Baseline Functional Requirements (as amended from time to time) and add additional requirements in those four areas plus the potential for a trusted laboratory validation of compliance with the profiles.
*Compliance results are freely available for query by any potential participant prior to any engagement using a standard web [[API]]. Potential users need to understand the results before they commit to joining in any framework.
*Compliance results are freely available for query by any potential participant prior to any engagement using a standard web [[API]]. Potential users need to understand the results before they commit to joining in any framework.
*[[Attestation]] of profiles compliant to the IDEF registry will be freely available to anyone with access to a web browser.
*[https://tcwiki.azurewebsites.net/index.php?title=Attested Attestation] of profiles compliant to the IDEF registry will be freely available to anyone with access to a web browser.
*[[Attestation]] from profiles need not be free. Joining any framework will likely be costly in terms of money and effort. Getting an attestation or certificate of membership is a value that must be paid for. The source of funding is not specified but could include charging for access to attested results, for example the acquisition of a signed or encrypted certificate of membership need not be freely available.
*[https://tcwiki.azurewebsites.net/index.php?title=Attested Attestation] from profiles need not be free. Joining any framework will likely be costly in terms of money and effort. Getting an attestation or certificate of membership is a value that must be paid for. The source of funding is not specified but could include charging for access to attested results, for example the acquisition of a signed or encrypted certificate of membership need not be freely available.
*[[Attestation]] of the [[Entity Statement]] is required as it must be signed, typically as as signed JWT or as signed and encrypted JOSE if [[User Private Information]] is present. This is not to be treated as a contradiction of the previous statement about framework membership for [[Entity]] information, which is '''never Private'''. There is no requirement that the [[Entity Statement]] be available at no cost.
*[https://tcwiki.azurewebsites.net/index.php?title=Attested Attestation] of the [[Entity Statement]] is required as it must be signed, typically as as signed JWT or as signed and encrypted JOSE if [[User Private Information]] is present. This is not to be treated as a contradiction of the previous statement about framework membership for [[Entity]] information, which is '''never Private'''. There is no requirement that the [[Entity Statement]] be available at no cost.
*The first goal is a working example of a framework using the OpenID federation in JSON with follow-up work in SAML and XML.


===Existing Compliance Frameworks===
===Existing Compliance Frameworks===
Line 19: Line 20:


==Problems==
==Problems==
*User need to real-time query access to the list of compliant participant.
*User need to real-time query access to the list of compliant participants.
*Each jurisdiction creates their own [[Identifier]] domain(s) for users and for providers that can be used to identify participants with some central rooted registry for the participants that have met the framework profile requirements.
*Each jurisdiction creates their own [[Identifier]] domain(s) for users and for providers that can be used to identify participants with some central rooted registry for the participants that have met the framework profile requirements.


Line 28: Line 29:
*OpenID has a draft federation document that could server as a template for an API.  
*OpenID has a draft federation document that could server as a template for an API.  
*The working document for the [[Trust Framework Membership Validation]] APIs has been under development since August 2017.
*The working document for the [[Trust Framework Membership Validation]] APIs has been under development since August 2017.
*A [http://trustregistry.us-east-2.elasticbeanstalk.com/Registry working sandbox is now available]. The query string has not be enabled as there are only 11 entries. It will be enabled when the list is longer. At that time it is expected that the columns will enable sort, so that the most favorable entry is at the top.
*A [https://tcwiki.azurewebsites.net/index.php?title=Federation_Trust_Registry Federation Trust Registry] is proposed to strongly identify framework participants.
*A [https://tcwiki.azurewebsites.net/index.php?title=Federation_Trust_Registry Federation Trust Registry] is proposed to strongly identify framework participants.
*A [http://identitymeme.org/doc/draft-hodges-saml-openid-compare-05.html draft Technical Comparison of OpenID and SAML] is available to help create coverage of both specs.
*A [http://identitymeme.org/doc/draft-hodges-saml-openid-compare-05.html draft Technical Comparison of OpenID and SAML] is available to help create coverage of both specs.
*The [https://www.incommon.org/federation/ InCommon Federation] is the U.S. education and research identity federation, providing a common [[SAML 2.0]] framework for trusted shared management of access to online resources.
*OpenID has a [https://openid.net/specs/openid-connect-federation-1_0.html draft federation document] that could server as a template for an API based on [[OpenID Connect 1.0]] and extending the InCommon effort. It is designed specifically to work for enterprise cases where the user has signed away their privacy rights.
===Profiles===
===Profiles===
As each community begins the process of creating profile the committee will coordinate and record their efforts here:
As each community begins the process of creating profile the committee will coordinate and record their efforts here:
Line 35: Line 39:
# [[Financial Profile]] now considering the creation of a specific implementation of a [[Financial Profile Sandbox]] for compliance testing.
# [[Financial Profile]] now considering the creation of a specific implementation of a [[Financial Profile Sandbox]] for compliance testing.
# [[Vulnerable Populations]], such as [https://www.oixnet.org/registry/minors-trust-framework/ Minor's Trust Framework], is one example of a horizontal profile that could be developed.
# [[Vulnerable Populations]], such as [https://www.oixnet.org/registry/minors-trust-framework/ Minor's Trust Framework], is one example of a horizontal profile that could be developed.
# [[Privacy Profile]] to track the progress of the NIST


==References==
==References==
 
*[https://www.openidentityexchange.org/wp-content/uploads/2018/11/OIX-White-Paper_Self-Certification-Mandatory-Assessment-Regimes_2018-11-07-.pdf A paper from the OIX comparing self-certification to mandatory assessment schemes.] (2018-11)
*[http://openid.net/specs/openid-connect-federation-1_0.html OpenID Connect Federation 1.0] and the references in that document define most of the terms used in the Federation API. It assumes an enterprise solution where users are not free to chose the federation that they will trust.
*[https://openid.net/specs/openid-connect-federation-1_0-04.html Draft 4 is the working OID federation document for this work]. The above link points to a more current draft that has some defects.


[[Category:Glossary]]
[[Category:Glossary]]
[[Category:Profile]]
[[Category:Profile]]

Latest revision as of 21:22, 15 December 2018

Full Title or Meme

The Identity Ecosystem Framework (IDEF) will need fine-grained specifications for applying its principles to specific vertical industry and horizontal community requirements.

Context

Goals

  • As a part of the creation of a set of Identity Ecosystems this plan lays out how to address specific community needs for security, privacy, interoperability and user experience. It is expected that all communities will start from the Baseline Functional Requirements (as amended from time to time) and add additional requirements in those four areas plus the potential for a trusted laboratory validation of compliance with the profiles.
  • Compliance results are freely available for query by any potential participant prior to any engagement using a standard web API. Potential users need to understand the results before they commit to joining in any framework.
  • Attestation of profiles compliant to the IDEF registry will be freely available to anyone with access to a web browser.
  • Attestation from profiles need not be free. Joining any framework will likely be costly in terms of money and effort. Getting an attestation or certificate of membership is a value that must be paid for. The source of funding is not specified but could include charging for access to attested results, for example the acquisition of a signed or encrypted certificate of membership need not be freely available.
  • Attestation of the Entity Statement is required as it must be signed, typically as as signed JWT or as signed and encrypted JOSE if User Private Information is present. This is not to be treated as a contradiction of the previous statement about framework membership for Entity information, which is never Private. There is no requirement that the Entity Statement be available at no cost.
  • The first goal is a working example of a framework using the OpenID federation in JSON with follow-up work in SAML and XML.

Existing Compliance Frameworks

A partial list of the existing compliance effort that are used as models includes:

  1. The IDEF registry is operation and will serve as the base framework for the sandbox efforts.
  2. The Kantara Initiative has aTrust Registry based on SAML 2 metadata.
  3. The OpenID foundation has a certification program for several of their identity profiles that has won wards for 2018 European Identity and Cloud Award and the 2018 Identity Innovation Award.
  4. The NIST has a Cybersecurity Framework consisting of standards, guidelines, and best practices to manage cybersecurity-related risk. One example of the use of vertical industry profiles of this framework may be found by following the link to the financial profile page below.
  5. The NIST has an SP 800-63-3 compliance program which now has assessors like Kantara to certify compliance.

Problems

  • User need to real-time query access to the list of compliant participants.
  • Each jurisdiction creates their own Identifier domain(s) for users and for providers that can be used to identify participants with some central rooted registry for the participants that have met the framework profile requirements.

Solutions

A user-friendly online query service that will give users actionable information about compliant participants.

  • The establishment of individual profiles that can be verified online and inline by calling APIs is the core of all of these profiles.
  • Unstructured queries will return a list of all the members that meet query.
  • OpenID has a draft federation document that could server as a template for an API.
  • The working document for the Trust Framework Membership Validation APIs has been under development since August 2017.
  • A working sandbox is now available. The query string has not be enabled as there are only 11 entries. It will be enabled when the list is longer. At that time it is expected that the columns will enable sort, so that the most favorable entry is at the top.
  • A Federation Trust Registry is proposed to strongly identify framework participants.
  • A draft Technical Comparison of OpenID and SAML is available to help create coverage of both specs.
  • The InCommon Federation is the U.S. education and research identity federation, providing a common SAML 2.0 framework for trusted shared management of access to online resources.
  • OpenID has a draft federation document that could server as a template for an API based on OpenID Connect 1.0 and extending the InCommon effort. It is designed specifically to work for enterprise cases where the user has signed away their privacy rights.

Profiles

As each community begins the process of creating profile the committee will coordinate and record their efforts here:

  1. Health Care Profile now in planing with various US healthcare committees.
  2. Financial Profile now considering the creation of a specific implementation of a Financial Profile Sandbox for compliance testing.
  3. Vulnerable Populations, such as Minor's Trust Framework, is one example of a horizontal profile that could be developed.
  4. Privacy Profile to track the progress of the NIST

References