Phase III IDEF Registry: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
 
(24 intermediate revisions by the same user not shown)
Line 15: Line 15:


*[https://tcwiki.azurewebsites.net/index.php?title=Framework_Profile Framework Profile]
*[https://tcwiki.azurewebsites.net/index.php?title=Framework_Profile Framework Profile]
*
*[[Health Care Profile]]
*[[Financial Profile]]
*[https://docs.google.com/presentation/d/1sYqjqnarKBMGMT-3dJuA6QE4EWYhD3pvtbQZvn9Xz3w  Consumer Ratings System]
 
===Use Cases===
*[[Emergency Contact Information Use Case]]
* [[Patient with Lab and Referral Use Case]]
* [https://docs.google.com/document/d/1taCE6I8tcx5zLQ9PYcDfk6ThB3WlcISIMBfIhKKC_Bg/edit Over 21 claim]
 
===Archive of Files===
* [https://tcwiki.azurewebsites.net/index.php?title=Trusted_Resolver Trusted Resolver]
* Wiki page [[Privacy Profile]] is in development
 
===Minutes of meetings===
* [https://docs.google.com/document/d/1tGTqhOSl4ZGsahfLPnx3D-xBkaok3oNe_0KnRXV1yQQ/edit?ts=5c34e445 Collected mins starting on 2018-01-08]


===Updates completed in Phase II===
===Updates completed in Phase II===
Line 23: Line 37:
* Security [[file:Secure_Requirements_Update.docx]]
* Security [[file:Secure_Requirements_Update.docx]]
* Usable [[file:Usable_Requirments_Update.docx]]
* Usable [[file:Usable_Requirments_Update.docx]]
==Technology Short Comings==
There are at least two identity challenges that need to be resolved before secure communications can be undertaken with web sites that have important personal information like health or financial information:
# The identity of the web site itself is seldom clear. Some sites have urls that are easy to recognize, but many do not and even those that do are subject to spoofing by sites that deliberately try to confuse the user, often with alphabets that are very close to the Latin one we are familiar with. What the user needs is clear indication of who is responsible for the web site in a way that is easy for them to understand.
# Documents that are delivered from health and financial sites very often is delivered by some site other that the one that created the information as is responsible for it. So it is important to package the information and display the owner of the information in a way that is easy for the user to understand. For example; in health care a variety of health care providers (primary care physician, lab) and data controllers (Epic, Cerner, AllScripts, etc.) are involved in provisioning patient information. When data is displayed to the user, it is seldom clear where the data originated and who controls access to the data. These need to be clear if the patient is a exercise their right to ultimate control of the information.
Both of these issues are known and solutions are being explored. These use case are built with the understanding that these problems will be fixed in the near term.


===Archive of Files===
==Work Product==
* [https://tcwiki.azurewebsites.net/index.php?title=Trusted_Resolver Trusted Resolver]
# Build example use case and sandbox for emergency contact information
# Obtain funding to move forward with Web Site ratings
# Obtain funding to build out a sandbox for the Trust Registry
# Continue alignment with NIST specifications on Risk and Privacy.


==Open Issues==
==Open Issues==


Carry over from the Phase II team:
Carry over from the Phase II team:


# There will be multiple identifier frameworks (aka methods) which have their own set of identity requirements.
# There will be multiple identifier frameworks (aka methods or profiles) which have their own set of identity requirements.
# Some of the frameworks will be IDEF compliant.
# Our focus will be on the frameworks will be IDEF compliant.
# All IDESG compliant frameworks will provide a machine-readable method to determine if a web site is a member of the framework
# All IDEF compliant frameworks will provide a machine-readable method to determine if a web site is a member of the framework
# Especially at the start most frameworks will not be IDEF compliant.
# Especially at the start, most frameworks will not be IDEF compliant.
# How should an IDEF compliant entity deal with identifiers that are:
# How should an IDEF compliant entity deal with identifiers that are:
## from within their own framework, ie within Healthcare or within the education internet 2 framework,
## from within their own framework, ie within Healthcare or within the education internet 2 framework,
## from an external framework that is still IDEF compliant, ie a student being transfer from a school client to the healthcare hospital or from a VA hospital with a PIV card to a public hospital that cannot read it
## from an external framework that is still IDEF compliant, ie a student being transfered from a school client to the healthcare hospital or from a VA hospital with a PIV card to a public hospital that cannot read it
## from an external framework is is not IDEF compliant, ie from a social network site like Google, FB, Microsoft, etc.
## from an external framework it is not IDEF compliant, ie from a social network site like Google, FB, Microsoft, etc.
# There is no advice available for entities that do not normally interact with the user on recovery and redress
# There is no advice available for entities that do not normally interact with the user on recovery and redress
# No standard has been found that helps to describe how a site with no user connectivity can meet any privacy or security guideline.
# No standard has been found that helps to describe how a site with no user connectivity can meet any privacy or security guideline.
# While there is a federation metadata draft standard from OpenID, it is oriented to enterprise environments where their is already a relationship with the users, there is no similar metadata standard for open environments.
# While there is a federation metadata draft standard from OpenID, it is oriented to enterprise environments where there is already a relationship with the users, there is no similar metadata standard for open environments.


==References==
==References==


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

Latest revision as of 16:34, 16 April 2019

Project details for Phase III are to be tracked here.

Phase II IDEF Registry is where the prior phase was tracked.

Requirements for Phase III

  1. Trusted Identities in Cyberspace will continue as the primary goal.
  2. Users can know that their personal information is:
    1. Acquired and used only on their consent and for the purposes agreed in advance.
    2. Only going to sites that have proven their identity and intent to the user.
    3. Will be securely protected wherever it is stored.
  3. Users can easily learn about the ratings on registered web sites
  4. Each Web site will present cryptographic proof of their identities, ratings and intentions about user information.

Requirements Documents

Use Cases

Archive of Files

Minutes of meetings

Updates completed in Phase II

Technology Short Comings

There are at least two identity challenges that need to be resolved before secure communications can be undertaken with web sites that have important personal information like health or financial information:

  1. The identity of the web site itself is seldom clear. Some sites have urls that are easy to recognize, but many do not and even those that do are subject to spoofing by sites that deliberately try to confuse the user, often with alphabets that are very close to the Latin one we are familiar with. What the user needs is clear indication of who is responsible for the web site in a way that is easy for them to understand.
  2. Documents that are delivered from health and financial sites very often is delivered by some site other that the one that created the information as is responsible for it. So it is important to package the information and display the owner of the information in a way that is easy for the user to understand. For example; in health care a variety of health care providers (primary care physician, lab) and data controllers (Epic, Cerner, AllScripts, etc.) are involved in provisioning patient information. When data is displayed to the user, it is seldom clear where the data originated and who controls access to the data. These need to be clear if the patient is a exercise their right to ultimate control of the information.

Both of these issues are known and solutions are being explored. These use case are built with the understanding that these problems will be fixed in the near term.

Work Product

  1. Build example use case and sandbox for emergency contact information
  2. Obtain funding to move forward with Web Site ratings
  3. Obtain funding to build out a sandbox for the Trust Registry
  4. Continue alignment with NIST specifications on Risk and Privacy.

Open Issues

Carry over from the Phase II team:

  1. There will be multiple identifier frameworks (aka methods or profiles) which have their own set of identity requirements.
  2. Our focus will be on the frameworks will be IDEF compliant.
  3. All IDEF compliant frameworks will provide a machine-readable method to determine if a web site is a member of the framework
  4. Especially at the start, most frameworks will not be IDEF compliant.
  5. How should an IDEF compliant entity deal with identifiers that are:
    1. from within their own framework, ie within Healthcare or within the education internet 2 framework,
    2. from an external framework that is still IDEF compliant, ie a student being transfered from a school client to the healthcare hospital or from a VA hospital with a PIV card to a public hospital that cannot read it
    3. from an external framework it is not IDEF compliant, ie from a social network site like Google, FB, Microsoft, etc.
  6. There is no advice available for entities that do not normally interact with the user on recovery and redress
  7. No standard has been found that helps to describe how a site with no user connectivity can meet any privacy or security guideline.
  8. While there is a federation metadata draft standard from OpenID, it is oriented to enterprise environments where there is already a relationship with the users, there is no similar metadata standard for open environments.

References