Identity Model Overview - Revision history

Tom: /* Solution */

2024-09-04T00:19:24Z

‎Solution

2024-09-04T00:18:44Z

‎Solution

2024-09-04T00:18:22Z

‎Solution

2024-09-04T00:17:19Z

‎Solution

2024-02-26T06:13:08Z

‎References

2019-01-24T22:28:43Z

‎References

2019-01-24T22:21:23Z

‎References

2019-01-24T22:19:33Z

‎Solution

2019-01-24T22:14:27Z

‎Meme - the Basic Idea

2018-08-26T21:31:59Z

‎Problems to be Solved

@@ Line 47: / Line 47: @@
 *A simplified version of the identify model flows is shown below with the three broad categories of entity. The separation of the Authorization from Identity and Attribute Providers ensures that identity tokens are never exposed to the unprotected internet. All three providers could be co-located in some cases. Any digital entity can, and probably will, have some sort of [[User Object]]. The relationships among the user objects on the provider side can get complex as is describe in the full model. For more detail see the [https://wiki.idesg.org/wiki/index.php?title=Identity_Model#New_Identity_Model Identity Model].
-[[File:IdentityModelSimplified.png|777px]]
+[[File:IdentityModelSimplified.png|800px]]
 ==References==

@@ Line 47: / Line 47: @@
 *A simplified version of the identify model flows is shown below with the three broad categories of entity. The separation of the Authorization from Identity and Attribute Providers ensures that identity tokens are never exposed to the unprotected internet. All three providers could be co-located in some cases. Any digital entity can, and probably will, have some sort of [[User Object]]. The relationships among the user objects on the provider side can get complex as is describe in the full model. For more detail see the [https://wiki.idesg.org/wiki/index.php?title=Identity_Model#New_Identity_Model Identity Model].
-[[File:IdentityModelSimplified.png|888px]]
+[[File:IdentityModelSimplified.png|777px]]
 ==References==

@@ Line 47: / Line 47: @@
 *A simplified version of the identify model flows is shown below with the three broad categories of entity. The separation of the Authorization from Identity and Attribute Providers ensures that identity tokens are never exposed to the unprotected internet. All three providers could be co-located in some cases. Any digital entity can, and probably will, have some sort of [[User Object]]. The relationships among the user objects on the provider side can get complex as is describe in the full model. For more detail see the [https://wiki.idesg.org/wiki/index.php?title=Identity_Model#New_Identity_Model Identity Model].
-[[File:IdentityModelSimplified.png|222px]]
+[[File:IdentityModelSimplified.png|888px]]
 ==References==

@@ Line 47: / Line 47: @@
 *A simplified version of the identify model flows is shown below with the three broad categories of entity. The separation of the Authorization from Identity and Attribute Providers ensures that identity tokens are never exposed to the unprotected internet. All three providers could be co-located in some cases. Any digital entity can, and probably will, have some sort of [[User Object]]. The relationships among the user objects on the provider side can get complex as is describe in the full model. For more detail see the [https://wiki.idesg.org/wiki/index.php?title=Identity_Model#New_Identity_Model Identity Model].
-[[File:IdentityModelSimplified.png]]
+[[File:IdentityModelSimplified.png|222px]]
 ==References==

@@ Line 53: / Line 53: @@
 * An alternate mode is the [http://docs.oasis-open.org/coel/COEL/v1.0/cs02/COEL-v1.0-cs02.pdf Classification of Everyday Living] completed 2018-06-26 which defines [[Behavior]]s and [[Identifier]]s in the same way but requires the recording of every event where behaviors are collected. It does not differentiate where data might be stored as in the model, but rather who did the collecting. It also assumes the existence of a "ConsumerID" that can be used by multiple parties, which does not appear to be particularly privacy-preserving. This model allows for diversity of [[Identifier]]s. Still it would be possible for an implementation to use both this model and the COEL model at the same time.
-[[Category:User Experience]]
+[[Category: User Experience]]
-[[Category:Identity]]
+[[Category: Identity]]

← Older revision		Revision as of 22:19, 24 January 2019
Line 49:		Line 49:
	[[File:IdentityModelSimplified.png]]		[[File:IdentityModelSimplified.png]]

		+	==References==
		+	<references />
		+	* An alternate mode is the [http://docs.oasis-open.org/coel/COEL/v1.0/cs02/COEL-v1.0-cs02.pdf Classification of Everyday Living] completed 2018-06-26 which defines [[Behavior]]s and [[Identifier]]s in the same way but requires the recording of every event where behaviors are collected.

	[[Category:User Experience]]		[[Category:User Experience]]
		+	[[Category:Identity]]

@@ Line 7: / Line 7: @@
 *All [[User Private Information]] held by any digital entity on the internet (called a [[User Object]] below) is subject to examination and control by the user.
-*Creating a language for creating a [[Design Pattern]] has been a challenge ever since communities grew beyond the tribe. This paper represents a new way of looking at identity, as a collection of [[Identifier]], [[Attribute]]s, and [[Behaviors]] none of which may be released to any digital entity without the user's explicit consent.
+*Creating a language for creating a [[Design Pattern]] has been a challenge ever since communities grew beyond the tribe. This paper represents a new way of looking at identity, as a collection of [[Identifier]], [[Attribute]]s, and [[Behavior]]s none of which may be released to any digital entity without the user's explicit consent.
 *The intended audience of this page is for decision makers and so has limited technical details. Click on the [[Identity Model]] for a complete technical description with all of the technical details.

@@ Line 28: / Line 28: @@
 #Users are having challenges understanding what attributes are requested and why. The difference between this best practice and the above usability requirement is not clear.([[Usable Best Practice A]])
 #Separating [[User Private Information]] into identity and attribute buckets is not clear. Some sort of data model would help to make this clear. The following are some of the concerns that are not addressed in the BFR. ([[Privacy Req 15]]).
-##Knowledge Based Authentication (KBA) is created on the concept that any attribute can be used in an authentication process.
+##[[Knowledge Based Authentication]] (KBA) is created on the concept that any attribute can be used in an authentication process.
 ##It [https://dataprivacylab.org/projects/identifiability/paper1.pdf has been shown] that just a user's 5 digit zip code, birthdate and gender will result in an 81% chance of uniquely identifying an individual.
 ##Even a user's email address (like tomj@microsoft.com) can provide a significant amount of [[User Private Information]].