Identity Model - Revision history

Tomjones: /* General References */

2020-10-30T00:16:17Z

General References

← Older revision		Revision as of 00:16, 30 October 2020
Line 261:		Line 261:
	[[Category:Identity]]		[[Category:Identity]]
	[[Category:Consent]]		[[Category:Consent]]
			[[Category:Profile]]
	[[Category:Compliant Implementations]]		[[Category:Compliant Implementations]]

Tomjones: /* Identity Taxonomy */

2020-10-07T04:45:43Z

Identity Taxonomy

← Older revision		Revision as of 04:45, 7 October 2020
Line 93:		Line 93:
	##Subject is an OpenID name for the identifier used between the IdP (which they call an OP) and the RP (which they call a client).		##Subject is an OpenID name for the identifier used between the IdP (which they call an OP) and the RP (which they call a client).
	##For the purposes of [[User Experience]] documents the user is always a natural person.		##For the purposes of [[User Experience]] documents the user is always a natural person.
	#Linkages bind one digital identifier to another, to a real-world name or to an assertion.		#Linkages bind one digital identifier to another, to a real-world name or to an assertion. aka tracking.
	#[[Authentication]] provides a real-time, short-term linkage between a user and a [[User Object]].		#[[Authentication]] provides a real-time, short-term linkage between a user and a [[User Object]].
	##No [[User Private Information]] is provided to the RP until after a successful authentication and user consent process has completed.		##No [[User Private Information]] is provided to the RP until after a successful authentication and user consent process has completed.

Tomjones: /* Identity Laws */

2020-10-07T04:44:09Z

Identity Laws

← Older revision		Revision as of 04:44, 7 October 2020
Line 67:		Line 67:
	Here the model considers the laws as they apply to the users in an IDESG compliant ecosystem. That means that all parties to the interchange are attempting to follow the [https://wiki.idesg.org/wiki/index.php?title=Baseline_Functional_Requirements_v1.0 Baseline Functional Requirements v1.0 (BFR)].		Here the model considers the laws as they apply to the users in an IDESG compliant ecosystem. That means that all parties to the interchange are attempting to follow the [https://wiki.idesg.org/wiki/index.php?title=Baseline_Functional_Requirements_v1.0 Baseline Functional Requirements v1.0 (BFR)].

	# User Control and Consent - for this model no data is released to the RP by the IdP without explicit consent of the user. That said there are still many cases where the relying party will ask for attributes that are not necessary to their purpose in communicating with the user. It is easy to understand why an RP would ask for the email address of the user both for verification and for communications if something later requires that, including notification of some attack against the user's identity.		# User Control and [[Consent]] - for this model no data is released to the RP by the IdP without explicit consent of the user. That said there are still many cases where the relying party will ask for attributes that are not necessary to their purpose in communicating with the user. It is easy to understand why an RP would ask for the email address of the user both for verification and for communications if something later requires that, including notification of some attack against the user's identity.
	# Minimal Disclosure for a Constrained Use - ask for the least amount of identifying information for a stable solution. Compliant web sites must follow this requirement, but other web sites will ask for whatever they can get away with.		# Minimal Disclosure for a Constrained Use - ask for the least amount of identifying information for a stable solution. Compliant web sites must follow this requirement, but other web sites will ask for whatever they can get away with.
	# Justifiable Parties - The identity system must make its user aware of the party or parties with whom she is interacting while [[Information Sharing Agreement\|sharing information]]. The justification requirements apply both to the user who is disclosing information and the relying party who depends on it.		# Justifiable Parties - The identity system must make its user aware of the party or parties with whom she is interacting while [[Information Sharing Agreement\|sharing information]]. The justification requirements apply both to the user who is disclosing information and the relying party who depends on it.

Tomjones: /* General References */

2020-03-27T21:36:24Z

General References

← Older revision		Revision as of 21:36, 27 March 2020
Line 260:		Line 260:
	[[Category:User Experience]]		[[Category:User Experience]]
	[[Category:Identity]]		[[Category:Identity]]
			[[Category:Consent]]
	[[Category:Compliant Implementations]]		[[Category:Compliant Implementations]]

Tomjones: /* Identity Laws */

2020-01-09T16:36:22Z

Identity Laws

← Older revision		Revision as of 16:36, 9 January 2020
Line 69:		Line 69:
	# User Control and Consent - for this model no data is released to the RP by the IdP without explicit consent of the user. That said there are still many cases where the relying party will ask for attributes that are not necessary to their purpose in communicating with the user. It is easy to understand why an RP would ask for the email address of the user both for verification and for communications if something later requires that, including notification of some attack against the user's identity.		# User Control and Consent - for this model no data is released to the RP by the IdP without explicit consent of the user. That said there are still many cases where the relying party will ask for attributes that are not necessary to their purpose in communicating with the user. It is easy to understand why an RP would ask for the email address of the user both for verification and for communications if something later requires that, including notification of some attack against the user's identity.
	# Minimal Disclosure for a Constrained Use - ask for the least amount of identifying information for a stable solution. Compliant web sites must follow this requirement, but other web sites will ask for whatever they can get away with.		# Minimal Disclosure for a Constrained Use - ask for the least amount of identifying information for a stable solution. Compliant web sites must follow this requirement, but other web sites will ask for whatever they can get away with.
	# Justifiable Parties - The identity system must make its user aware of the party or parties with whom she is interacting while sharing information. The justification requirements apply both to the user who is disclosing information and the relying party who depends on it.		# Justifiable Parties - The identity system must make its user aware of the party or parties with whom she is interacting while [[Information Sharing Agreement\|sharing information]]. The justification requirements apply both to the user who is disclosing information and the relying party who depends on it.
	# Directed Identity - For the IDESG this means that a relying party should use as many sources of identifiers as is consistent with their objectives. The goal must be user convenience.		# Directed Identity - For the IDESG this means that a relying party should use as many sources of identifiers as is consistent with their objectives. The goal must be user convenience.
	# Pluralism of Operators and Technologies - Much of the focus of the work of this committee is the OpenID Connect standards bodies because they can be made fully compliant with IDESG principles. It is hoped that other technologies will enable the IDESG principles as well.		# Pluralism of Operators and Technologies - Much of the focus of the work of this committee is the OpenID Connect standards bodies because they can be made fully compliant with IDESG principles. It is hoped that other technologies will enable the IDESG principles as well.

Tomjones: /* Certificate Service Provider (CSP) View */

2019-11-18T17:09:52Z

Certificate Service Provider (CSP) View

← Older revision		Revision as of 17:09, 18 November 2019
Line 114:		Line 114:
	There is an internet standard that requires the user select, or be assigned, an unique identifier called a Uniform Resource Identifier or URI. The email address is now the most common URI for individuals. It is already true that most people that can operate computers have already acquired several of these identifiers which are used in specific contexts, including internet purchases and work-related web accesses.		There is an internet standard that requires the user select, or be assigned, an unique identifier called a Uniform Resource Identifier or URI. The email address is now the most common URI for individuals. It is already true that most people that can operate computers have already acquired several of these identifiers which are used in specific contexts, including internet purchases and work-related web accesses.

	===[[Certificate Service Provider]] (CSP) View===		===Certificate Service Provider (CSP) View===

	There are two types of CSP with differing views of the role of the user in determining their own list of attributes (aka identity claim) to be contained within the certificate:		There are two types of CSP with differing views of the role of the user in determining their own list of attributes (aka identity claim) to be contained within the certificate:

Tomjones: /* Certificate Service Provider (CSP) View */

2019-11-18T17:08:53Z

Certificate Service Provider (CSP) View

← Older revision		Revision as of 17:08, 18 November 2019
Line 114:		Line 114:
	There is an internet standard that requires the user select, or be assigned, an unique identifier called a Uniform Resource Identifier or URI. The email address is now the most common URI for individuals. It is already true that most people that can operate computers have already acquired several of these identifiers which are used in specific contexts, including internet purchases and work-related web accesses.		There is an internet standard that requires the user select, or be assigned, an unique identifier called a Uniform Resource Identifier or URI. The email address is now the most common URI for individuals. It is already true that most people that can operate computers have already acquired several of these identifiers which are used in specific contexts, including internet purchases and work-related web accesses.

	===Certificate Service Provider (CSP) View===		===[[Certificate Service Provider]] (CSP) View===

	There are two types of CSP with differing views of the role of the user in determining their own list of attributes (aka identity claim) to be contained within the certificate:		There are two types of CSP with differing views of the role of the user in determining their own list of attributes (aka identity claim) to be contained within the certificate:
Line 120:		Line 120:
	# The user can, in theory, generate their own private keys to serve as a source of credentials and create their own certificate profile with the use of virtual smart cards where the user generates the private key themselves and requests a credential from a Certificate Service Provider like Verisign or Global Trust. Attempts to deploy individual user certificates outside of an enterprise environment have not been successful.		# The user can, in theory, generate their own private keys to serve as a source of credentials and create their own certificate profile with the use of virtual smart cards where the user generates the private key themselves and requests a credential from a Certificate Service Provider like Verisign or Global Trust. Attempts to deploy individual user certificates outside of an enterprise environment have not been successful.

	Originally conceived by the monopoly telephone companies as a ~~extention~~ of the monetization their telephone directories, [https://en.wikipedia.org/wiki/X.509 X.509 certificates] were defined to bind [[User Private Information]] to a authenticator, like a private key on a smart card. The view of the CSP in this case depends on the type of use to which the certificate is applied.		Originally conceived by the monopoly telephone companies as a extension of the monetization their telephone directories, [https://en.wikipedia.org/wiki/X.509 X.509 certificates] were defined to bind [[User Private Information]] to a authenticator, like a private key on a smart card. The view of the CSP in this case depends on the type of use to which the certificate is applied.

	* In the case of users that need to prove their authority to act, a formal certificate of the X.509 type can be critical. The most critical functions of society: first responders, physicians, professional engineers, child care providers and others given authority, the certificate can be the critical document that provides the proof needed for that critical individual to act on behalf of the individual, or on behalf of legally constituted organizations in society. Typically the registration authority associated with the use of the credential will determine the certificate profile.		* In the case of users that need to prove their authority to act, a formal certificate of the X.509 type can be critical. The most critical functions of society: first responders, physicians, professional engineers, child care providers and others given authority, the certificate can be the critical document that provides the proof needed for that critical individual to act on behalf of the individual, or on behalf of legally constituted organizations in society. Typically the registration authority associated with the use of the credential will determine the certificate profile.

Omaerz: 609 revisions imported: Initial Upload of old pages from IDESG Wiki

2018-06-28T04:01:34Z

609 revisions imported: Initial Upload of old pages from IDESG Wiki

Show changes