User Private Information - Revision history

Tom: /* Open Issues */

2024-07-25T04:27:35Z

‎Open Issues

Tom: /* Solution */

2024-07-25T04:24:31Z

‎Solution

Tom: /* 3=Strongly Authenticated */

2024-07-25T01:42:18Z

‎3=Strongly Authenticated

Tom: /* 3=Strongly Authenticated */

2024-07-25T01:37:57Z

‎3=Strongly Authenticated

Tom: /* Context */

2024-02-29T00:25:19Z

‎Context

Tom: /* Context */

2024-02-29T00:23:12Z

‎Context

Tom: /* Full Title or Meme */

2024-02-29T00:15:30Z

‎Full Title or Meme

Tom: /* Engineering Risk for Private Information */

2022-04-29T00:41:06Z

‎Engineering Risk for Private Information

Tom: /* External Definitions */

2022-02-01T22:43:53Z

‎External Definitions

Tom at 16:50, 15 October 2018

2018-10-15T16:50:17Z

@@ Line 62: / Line 62: @@
 ===Open Issues===
-'''Data exposed by a Federated IdP may be in excess of what a user intends.''' Describing the problem in terms of [[OpenId Connect]] which is a federated authentication built on oauth 2, which is an authorization protocol. The process is this: a user navigates to an RP, the RP bounces a request off the user to the IdP which verifies the user intent, the IdP replies through the user to to RP with an authorization token that allows the RP to request the authorized attributes from the IdP. Now the question is whether the RP really needed all of the attributes requested and whether the user actually understood what attributes she agreed to release.
+'''Data exposed by a Federated IdP may be in excess of what a user intends.''' Describing the problem in terms of [[OpenID Connect]] which is a federated authentication built on oauth 2, which is an authorization protocol. The process is this: a user navigates to an RP, the RP bounces a request off the user to the IdP which verifies the user intent, the IdP replies through the user to to RP with an authorization token that allows the RP to request the authorized attributes from the IdP. Now the question is whether the RP really needed all of the attributes requested and whether the user actually understood what attributes she agreed to release.
 '''Do Not Track (DNT)''' has not been approved for [http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html release] by the World Wide Web consortia even though it is widely implemented in common browsers. This HTTP header field has the capability to include multiple values and could handle an indication that the user was restricted in some way.

@@ Line 42: / Line 42: @@
 The user provides or permits some identifier that can be reused over time to link a continued presence. The RP does not try to link the user to a human. The user implicitly intends to assert [http://donottrack.us/ DO NOT TRACK].
-IAL 1 = LOA 1 or 2 if provided by the user. Note that the identifier may be supplied by the RP.
+IAL 1 &#8771; LOA 1 or 2 if provided by the user. Note that the identifier may be supplied by the RP.
 ===<span style="color:#ee8010">2=Weakly Authenticated<span>===
@@ Line 48: / Line 48: @@
 The user provides or permits an identifier that may be linked from one site to another under limited conditions permitted by the user expressed intent.
-IAL 1 = LOA 1 or 2 if provided by the user. Note that the identifier may be supplied by the RP.
+IAL 1 &#8771; LOA 1 or 2 if provided by the user. Note that the identifier may be supplied by the RP.
 ===<span style="color:#ff0000">3=Strongly Authenticated<span>===
@@ Line 59: / Line 59: @@
 The user has some legal obligation to be well-known to the system in order to be authorized to perform their duties. The user will have some physical authentication factor like a CAC or PIV card and some binding between the current interchange and the physical factor (see [[Channel Binding]]).
-IAL 3 = LOA 4
+IAL 3 &#8771; LOA 4
 ===Open Issues===
-'''Data exposed by a Federated IdP may be in excess of what a user intends.''' Describing the problem in terms of OpenIdConnect which is a federated authentication built on oauth 2, which is an authorization protocol. The process is this: a user navigates to an RP, the RP bounces a request off the user to the IdP which verifies the user intent, the IdP replies through the user to to RP with an authorization token that allows the RP to request the authorized attributes from the IdP. Now the question is whether the RP really needed all of the attributes requested and whether the user actually understood what attributes she agreed to release.
+'''Data exposed by a Federated IdP may be in excess of what a user intends.''' Describing the problem in terms of [[OpenId Connect]] which is a federated authentication built on oauth 2, which is an authorization protocol. The process is this: a user navigates to an RP, the RP bounces a request off the user to the IdP which verifies the user intent, the IdP replies through the user to to RP with an authorization token that allows the RP to request the authorized attributes from the IdP. Now the question is whether the RP really needed all of the attributes requested and whether the user actually understood what attributes she agreed to release.
 '''Do Not Track (DNT)''' has not been approved for [http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html release] by the World Wide Web consortia even though it is widely implemented in common browsers. This HTTP header field has the capability to include multiple values and could handle an indication that the user was restricted in some way.

@@ Line 54: / Line 54: @@
 The RP has some specific requirement to know the identity of the user, such as [[Know Your Customer]], or [[KYC]] regulations for a bank.
-IAL 2 &sime; LOA 3
+IAL &#8771; LOA 3
 ===<span style="color:#990099">4=User Identity Proofed in Person<span>===

@@ Line 52: / Line 52: @@
 ===<span style="color:#ff0000">3=Strongly Authenticated<span>===
-The RP has some specific requirement to know the identity of the user, such a KYC regulations for a bank.
+The RP has some specific requirement to know the identity of the user, such as [[Know Your Customer]], or [[KYC]] regulations for a bank.
-IAL 2 = LOA 3
+IAL 2 &sime; LOA 3
 ===<span style="color:#990099">4=User Identity Proofed in Person<span>===

@@ Line 3: / Line 3: @@
 ==Context==
-There is an interesting story about Samuel D. Warren II, one of the authors of "The Right to Privacy"<ref>Warren and Brandies, ''The Right to Privacy'' Harvard Law Review IV (5) 192-200</ref>. He was a very private person who had a very public scandal that resulted in lewd newspaper articles about the reason for his wife's death.<ref></ref> Shortly after that he wrote the law review article which was first to sharply define the right.
+There is an interesting story about Samuel D. Warren II, one of the authors of "The Right to Privacy"<ref>Warren and Brandies, ''The Right to Privacy'' Harvard Law Review IV (5) 192-200</ref>. He was a very private person who had a very public scandal that resulted in lewd newspaper articles about the reason for his wife's death.<ref>Amy Gajda, Seek and Hide'' ISBN 978-1984880741</ref> Shortly after that he wrote the law review article which was first to sharply define the right.
 Most of the discussion of user authentication is based on NIST Special Publication [[NIST SP 800-63-2]] and the Levels of Authentication (LOA). (A [https://pages.nist.gov/800-63-3/sp800-63-3.html new draft SP 800-63-3] has just been approved which proposes Identity Assurance Level (IAL) 1, 2 and 3. Both the LOA and IAL are listed below.) This page looks at user authentication from the point of view of the user and what they understand about their own exposure of personal information in a system. This could be shown through the exhibiting of a user's status through authentication from the user's need to provide the session with authorization to achieve the user's intentions.

← Older revision		Revision as of 00:23, 29 February 2024
Line 3:		Line 3:

	==Context==		==Context==
		+	There is an interesting story about Samuel D. Warren II, one of the authors of "The Right to Privacy"<ref>Warren and Brandies, ''The Right to Privacy'' Harvard Law Review IV (5) 192-200</ref>. He was a very private person who had a very public scandal that resulted in lewd newspaper articles about the reason for his wife's death.<ref></ref> Shortly after that he wrote the law review article which was first to sharply define the right.
		+
	Most of the discussion of user authentication is based on NIST Special Publication [[NIST SP 800-63-2]] and the Levels of Authentication (LOA). (A [https://pages.nist.gov/800-63-3/sp800-63-3.html new draft SP 800-63-3] has just been approved which proposes Identity Assurance Level (IAL) 1, 2 and 3. Both the LOA and IAL are listed below.) This page looks at user authentication from the point of view of the user and what they understand about their own exposure of personal information in a system. This could be shown through the exhibiting of a user's status through authentication from the user's need to provide the session with authorization to achieve the user's intentions.		Most of the discussion of user authentication is based on NIST Special Publication [[NIST SP 800-63-2]] and the Levels of Authentication (LOA). (A [https://pages.nist.gov/800-63-3/sp800-63-3.html new draft SP 800-63-3] has just been approved which proposes Identity Assurance Level (IAL) 1, 2 and 3. Both the LOA and IAL are listed below.) This page looks at user authentication from the point of view of the user and what they understand about their own exposure of personal information in a system. This could be shown through the exhibiting of a user's status through authentication from the user's need to provide the session with authorization to achieve the user's intentions.

@@ Line 1: / Line 1: @@
 ==Full Title or Meme==
-User Information consists of two parts, the Private and the Public.
+[[User Information]] consists of two parts, the Private and the Public. Click on the link to see more about [[User Information]] in general.
 ==Context==

@@ Line 77: / Line 77: @@
 **Requires that agencies apply the NIST Risk Management Framework (RMF) in their privacy programs.
 **Specifically calls out that strict [[Compliance]] with privacy laws is insufficient to provide privacy protection.
+* NIST Internal Report 8062 [http://nvlpubs.nist.gov/nistpubs/ir/2017/NIST.IR.8062.pdf An Introduction to Privacy Engineering and Risk Management in Federal Systems] issued in January 2017 describes how federal agencies could host [[Compliance|compliant]] relying party web sites.
-* NIST Internal Report 8062 [http://nvlpubs.nist.gov/nistpubs/ir/2017/NIST.IR.8062.pdf An Introduction to Privacy Engineering and Risk Management in Federal Systems] issued in January 2017 describes how federal agencies could host [[Compliance|compliant]] relying part web sites.
+* [https://www.cdse.edu/Portals/124/Documents/student-guides/CS124-guide.pdf Introduction to the DoD Risk Management Framework]
 There is also an evolving effort to measure [https://www.ashurst.com/en/news-and-insights/legal-updates/conduct-risk-framework-a-guide-for-firms/ "Conduct Risk Assessment" in the UK FCA] ([https://www.fca.org.uk/ Financial Conduct Authority]) that has been getting positive reception in the US and other countries. The following quote expresses this quite well.

@@ Line 89: / Line 89: @@
 #[[FHIR]] defines protection given to "Protected Health Information" ([[PHI]]) or electronic PHI (ePHI or [[EHI]]).
-[[Category:User Experience]]
+[[Category: User Experience]]
-[[Category:Security]]
+[[Category: Consent]]
 [[Category:Privacy]]
 [[Category:Identity]]

@@ Line 7: / Line 7: @@
 The only function of the internet is to move information from one point to another point. The internet protocols structure data and provide context that allows the systems communicating on the internet to infer meaning. It is the action that information has when it moves from one site to another that unlocks the full potential of the internet. This page address the visibility to the user as to the amount of information that a user needs to provide to a relying party (RP) web site to achieve their goals.
-Note that risk status directly addresses the issues of the December 2016 Plenary on the acceptance by the IDESG of NIST SP 800-63-2 assurance levels 4 and 5. Specifically these levels of assurance are claimed to not meet the pseudonymity requirements of the IDEF, but are required for some secure web sites. The appearance of high levels of risk on the web page should help to address these concerns and still allow sites to be IDEF compliant.
+Note that risk status directly addresses the issues of the December 2016 Plenary on the acceptance by the IDESG of NIST SP 800-63-2 assurance levels 4 and 5. Specifically these levels of assurance are claimed to not meet the pseudonymity requirements of the IDEF, but are required for some secure web sites. The appearance of high levels of risk on the web page should help to address these concerns and still allow sites to be IDEF [[Compliance|compliant]].
 ===Goal===
@@ Line 24: / Line 24: @@
 ==Solution==
 ===When to use this Solution===
-The user is on an internet connected display device using a browser or other HTML display screen. This solution is based on a display to the user by a Relying Party (RP). It is expected that the same values could be used by other entities, like an IdP. It is expected that a PIER logo would be in the header of every page on an compliant site in addition to the IDEF logo at the bottom of the page.
+The user is on an internet connected display device using a browser or other HTML display screen. This solution is based on a display to the user by a Relying Party (RP). It is expected that the same values could be used by other entities, like an IdP. It is expected that a PIER logo would be in the header of every page on a [[Compliance|compliant]] site in addition to the IDEF logo at the bottom of the page.
 ===User Private Information Exposure Risk (PIER) Levels===
@@ Line 68: / Line 68: @@
 ==References and Coordination==
 ===User Identity Management===
-*The [[Best Practice and Example Relying Party]] document describes how a relying party can construct an IDEF compliant site.
+*The [[Best Practice and Example Relying Party]] document describes how a relying party can construct an IDEF [[Compliance|compliant]] site.
 *The [[Identity Model]] page describes a new model which integrates the customer relationship management (CRM) and vendor relationship management (VRM) into a model that can be used by any system.