Credential Service Provider - Revision history

Tomjones: /* Sources */

2020-05-15T01:56:49Z

Sources

← Older revision		Revision as of 01:56, 15 May 2020
Line 14:		Line 14:
	#An entity that performs identity proofing, registration and issues some form of a subscriber token within some procedural context designed to convey a degree of trust.(Wallace)		#An entity that performs identity proofing, registration and issues some form of a subscriber token within some procedural context designed to convey a degree of trust.(Wallace)
	#A trusted entity that issues credentials to Subscribers.(D'Agostino)		#A trusted entity that issues credentials to Subscribers.(D'Agostino)
			# Credential Service Provider: an organization which provides the functions of an [electronic] Identity Proofing and Credential Management Service, either in full or as a discrete component (i.e., a sub-set of the functions). - Kantara IAWG

	== Status ==		== Status ==
	<span style="background: orange">Proposed Update</span>		<span style="background: orange">Proposed Update</span>

Tomjones: /* Details */

2020-05-15T01:55:53Z

Details

← Older revision		Revision as of 01:55, 15 May 2020
Line 18:		Line 18:

	== Details ==		== Details ==
	* For basic levels of assurance the CSP can provided verified attributes, but these should be treated by any relying party as self-asserted.		* For basic levels of assurance the CSP can provided verified attributes, but these should be treated by any relying party as self-asserted. (IAL1, AAL1 and FAL1)
	* For higher levels of identity assurance the CSP must verify (2) remote or (3) physically present identity proofing, including pseudonymous identity.		* For higher levels of identity assurance the CSP must verify (IAL2) remote or (IAL3) physically present identity proofing, including pseudonymous identity.
	* For higher levels of authentication assurance the CSP must verify proof of possession and control of (2) two factors or (3) a hardware-based authenticator of 2 factors.		* For higher levels of authentication assurance the CSP must verify proof of possession and control of (AAL2) two factors or (AAL3) a hardware-based authenticator of 2 factors.
	* For higher levels of federation assurance the CSP must verify (2) approved encryption or (3) proof of possession and approved encryption.		* For higher levels of federation assurance the CSP must verify (FAL2) approved encryption or (FAL3) proof of possession and approved encryption.

	==References==		==References==

Tomjones: /* Context */

2020-05-15T01:54:53Z

Context

← Older revision		Revision as of 01:54, 15 May 2020
Line 7:		Line 7:
	* In other words, each federation must understand what they mean by [[Trusted Entity]] as the CSP will have the authority to validate credentials under the federations rules.		* In other words, each federation must understand what they mean by [[Trusted Entity]] as the CSP will have the authority to validate credentials under the federations rules.
	* The slight change to the NIST wording was to meant to clarify that subscribers (or subjects) can create their own credentials is protected storage and ask the CSP to verify the security of those credentials.		* The slight change to the NIST wording was to meant to clarify that subscribers (or subjects) can create their own credentials is protected storage and ask the CSP to verify the security of those credentials.
			* Federation Agreement = a document, or group of documents, that contain the agreed upon “rules” by which the federation operates.

	== Sources ==		== Sources ==

Tomjones: /* Context */

2020-05-14T21:59:09Z

Context

← Older revision		Revision as of 21:59, 14 May 2020
Line 5:		Line 5:
	==Context==		==Context==
	* Each federation must establish rules for determining how a [[Trusted Entity]] will be accepted for inclusion in a registry by the federation's [[Accreditation Authority]]. (See details below for federation assurance.)		* Each federation must establish rules for determining how a [[Trusted Entity]] will be accepted for inclusion in a registry by the federation's [[Accreditation Authority]]. (See details below for federation assurance.)
			* In other words, each federation must understand what they mean by [[Trusted Entity]] as the CSP will have the authority to validate credentials under the federations rules.
	* The slight change to the NIST wording was to meant to clarify that subscribers (or subjects) can create their own credentials is protected storage and ask the CSP to verify the security of those credentials.		* The slight change to the NIST wording was to meant to clarify that subscribers (or subjects) can create their own credentials is protected storage and ask the CSP to verify the security of those credentials.

Tomjones: /* Context */

2020-05-14T21:52:43Z

Context

← Older revision		Revision as of 21:52, 14 May 2020
Line 4:		Line 4:

	==Context==		==Context==
	* Each federation must establish rules for determining how a [[Trusted Entity]] will be accepted for inclusion in a registry by the federation's [[Accreditation Authority]].		* Each federation must establish rules for determining how a [[Trusted Entity]] will be accepted for inclusion in a registry by the federation's [[Accreditation Authority]]. (See details below for federation assurance.)
	* The slight change to the NIST wording was to meant to clarify that subscribers (or subjects) can create their own credentials is protected storage and ask the CSP to verify the security of those credentials.		* The slight change to the NIST wording was to meant to clarify that subscribers (or subjects) can create their own credentials is protected storage and ask the CSP to verify the security of those credentials.

Tomjones: /* Context */

2020-05-14T21:50:59Z

Context

← Older revision		Revision as of 21:50, 14 May 2020
Line 4:		Line 4:

	==Context==		==Context==
	* Each federation must establish rules for determining how a [[Trusted Entity]] will be accepted for inclusion in a registry by the [[Accreditation Authority]].		* Each federation must establish rules for determining how a [[Trusted Entity]] will be accepted for inclusion in a registry by the federation's [[Accreditation Authority]].
	* The slight change to the NIST wording was to meant to clarify that subscribers (or subjects) can create their own credentials is protected storage and ask the CSP to verify the security of those credentials.		* The slight change to the NIST wording was to meant to clarify that subscribers (or subjects) can create their own credentials is protected storage and ask the CSP to verify the security of those credentials.

Tomjones: /* Context */

2020-05-14T21:49:32Z

Context

← Older revision		Revision as of 21:49, 14 May 2020
Line 4:		Line 4:

	==Context==		==Context==
	* Each federation must establish rules for ~~determine to determine~~ how a [[Trusted Entity]] ~~it to~~ be ~~registered~~ in a registry by the [[Accreditation Authority]].		* Each federation must establish rules for determining how a [[Trusted Entity]] will be accepted for inclusion in a registry by the [[Accreditation Authority]].
	* The slight change to the NIST wording was to meant to clarify that subscribers (or subjects) can create their own credentials is protected storage and ask the CSP to verify the security of those credentials.		* The slight change to the NIST wording was to meant to clarify that subscribers (or subjects) can create their own credentials is protected storage and ask the CSP to verify the security of those credentials.

Tomjones: /* Context */

2020-05-14T21:48:24Z

Context

← Older revision		Revision as of 21:48, 14 May 2020
Line 4:		Line 4:

	==Context==		==Context==
	* Each federation must establish rules for determine to determine how a [[Trusted Entity]] it to be registered in the [[Accreditation]].		* Each federation must establish rules for determine to determine how a [[Trusted Entity]] it to be registered in a registry by the [[Accreditation Authority]].
	* The slight change to the NIST wording was to meant to clarify that subscribers (or subjects) can create their own credentials is protected storage and ask the CSP to verify the security of those credentials.		* The slight change to the NIST wording was to meant to clarify that subscribers (or subjects) can create their own credentials is protected storage and ask the CSP to verify the security of those credentials.

Tomjones: /* Context */

2020-05-14T21:47:24Z

Context

← Older revision		Revision as of 21:47, 14 May 2020
Line 4:		Line 4:

	==Context==		==Context==
	The slight change to the NIST wording was to meant to clarify that subscribers (or subjects) can create their own credentials is protected storage and ask the CSP to verify the security of those credentials.		* Each federation must establish rules for determine to determine how a [[Trusted Entity]] it to be registered in the [[Accreditation]].
			* The slight change to the NIST wording was to meant to clarify that subscribers (or subjects) can create their own credentials is protected storage and ask the CSP to verify the security of those credentials.

	== Sources ==		== Sources ==

Tomjones: /* Definition */

2020-05-14T21:15:34Z

Definition

← Older revision		Revision as of 21:15, 14 May 2020
Line 1:		Line 1:
	Taxonomy Template:		Taxonomy Template:
	==Definition==		==Definition==
	A ~~trusted entity~~ that issues or registers subscriber authenticators and issues [verifications of] electronic credentials to subscribers. A CSP may be an independent third party or [it may] issue credentials for its own use.		A ''[[Trusted Entity]]'' that issues or registers subscriber authenticators and issues [verifications of] electronic credentials to subscribers. A CSP may be an independent third party or [it may] issue credentials for its own use.

	==Context==		==Context==