Federated Strong Employee ID - Revision history

Tom at 15:22, 2 May 2025

2025-05-02T15:22:41Z

Tom: /* References and Citations */

2025-05-02T15:19:37Z

‎References and Citations

Tom: /* References and Citations */

2025-05-02T15:19:19Z

‎References and Citations

Tom: /* Assumptions: */

2025-05-02T15:17:18Z

‎Assumptions:

Tom: /* Actors: */

2025-05-02T15:16:28Z

‎Actors:

Tom: /* Use Case Details */

2025-05-02T15:15:28Z

‎Use Case Details

Tom: Created page with "'''Title:''' Federated Strong Employee ID authenticated to external sites sanctioned by the Employer Use Case Description: Use existing strongly authenticated employee identi..."

2025-05-02T15:14:28Z

Created page with "'''Title:''' Federated Strong Employee ID authenticated to external sites sanctioned by the Employer Use Case Description: Use existing strongly authenticated employee identi..."

New page

'''Title:''' Federated Strong Employee ID authenticated to external sites sanctioned by the Employer

Use Case Description: Use existing strongly authenticated employee identity certificate to create claims that are accepted by employer approved web sites, either internal or external to the employer's enterprise. While this use case focuses on the employee-employer relationship, it would work equally well for any case where their is a contractual relationship between the user and the identity provider (IdP).

Use Case Category: Authentication, Federated Identity
Contributor: Tom Jones

==Use Case Details==
Actors:

User (aka employee) in this case is an entity authenticated by an enterprise employer that is willing to create a claim to a specific site. Note that not only employees but other entities, like groups of individuals or contractors can have enterprise credentials.
User agent in this case is an entity that controls inclusion of the user's private attributes in the bucket of claims provided to the RP.
Identity Provider in this case is an enterprise that can strongly identify entities and that has some contractual authority to control the user's behavior when authenticated using the employer provided credentials.
Relying party (RP) in this case is a specific internet connection web site, not always part of the enterprise.

Goals: The goal is to provide an identity from an enterprise to a federated site (the RP) with all information needed by the RP to make the authorization decision.

Assumptions:

The enterprise will have some contractual or ownership role with the user. These contractual obligations made by the user are often important to the relying party.
Typically the claim created by the enterprise will contain the enterprise internal identifier for the user. Note that some enterprises create alias that are not specific to any individual or that obfuscate that individual's real world identity for reasons that it need not disclose to the relying party.
The user agent will be assumed under the control of the enterprise employer for this use case. Typically the claim provided to the relying party will contain attributes that are unique to the user and the enterprise will be operating under some regulatory compliance constraints that control the release of user private data to the RP.
Proof of strong authentication of the user will be an attribute provided by the employer's IdP.

Requirements:

Process Flow:

Success Scenario:

Error Conditions:

==References and Citations==
Privacy using Employer issued Identifiers from http://tscp.org
[[Categories: Use Cases]]
[[Categories: Identifier]]
[[Categories: Authentication]]

@@ Line 37: / Line 37: @@
 ==References and Citations==
 * [https://web.archive.org/web/20201028202038/http://www.tscp.org/privacy-employer-ids/ Privacy using Employer issued Identifiers] from http://tscp.org
-[[Category: Use Cases]]
+[[Category: Use Case]]
 [[Category: Identifier]]
 [[Category: Authentication]]

@@ Line 19: / Line 19: @@
 ===Assumptions:===
-The enterprise will have some contractual or ownership role with the user. These contractual obligations made by the user are often important to the relying party.
+*The enterprise will have some contractual or ownership role with the user. These contractual obligations made by the user are often important to the relying party.
-Typically the claim created by the enterprise will contain the enterprise internal identifier for the user. Note that some enterprises create alias that are not specific to any individual or that obfuscate that individual's real world identity for reasons that it need not disclose to the relying party.
+*Typically the claim created by the enterprise will contain the enterprise internal identifier for the user. Note that some enterprises create alias that are not specific to any individual or that obfuscate that individual's real world identity for reasons that it need not disclose to the relying party.
-The user agent will be assumed under the control of the enterprise employer for this use case. Typically the claim provided to the relying party will contain attributes that are unique to the user and the enterprise will be operating under some regulatory compliance constraints that control the release of user private data to the RP.
+*The user agent will be assumed under the control of the enterprise employer for this use case. Typically the claim provided to the relying party will contain attributes that are unique to the user and the enterprise will be operating under some regulatory compliance constraints that control the release of user private data to the RP.
-Proof of strong authentication of the user will be an attribute provided by the employer's IdP.
+*Proof of strong authentication of the user will be an attribute provided by the employer's IdP.
 Requirements:

@@ Line 10: / Line 10: @@
 ===Actors:===
-User (aka employee) in this case is an entity authenticated by an enterprise employer that is willing to create a claim to a specific site. Note that not only employees but other entities, like groups of individuals or contractors can have enterprise credentials.
+*User (aka employee) in this case is an entity authenticated by an enterprise employer that is willing to create a claim to a specific site. Note that not only employees but other entities, like groups of individuals or contractors can have enterprise credentials.
-User agent in this case is an entity that controls inclusion of the user's private attributes in the bucket of claims provided to the RP.
+*User agent in this case is an entity that controls inclusion of the user's private attributes in the bucket of claims provided to the RP.
-Identity Provider in this case is an enterprise that can strongly identify entities and that has some contractual authority to control the user's behavior when authenticated using the employer provided credentials.
+*Identity Provider in this case is an enterprise that can strongly identify entities and that has some contractual authority to control the user's behavior when authenticated using the employer provided credentials.
-Relying party (RP) in this case is a specific internet connection web site, not always part of the enterprise.
+*Relying party (RP) in this case is a specific internet connection web site, not always part of the enterprise.
 Goals: The goal is to provide an identity from an enterprise to a federated site (the RP) with all information needed by the RP to make the authorization decision.

@@ Line 1: / Line 1: @@
-'''Title:''' Federated Strong Employee ID authenticated to external sites sanctioned by the Employer
+==Full Title:==
-Use Case Description: Use existing strongly authenticated employee identity certificate to create claims that are accepted by employer approved web sites, either internal or external to the employer's enterprise. While this use case focuses on the employee-employer relationship, it would work equally well for any case where their is a contractual relationship between the user and the identity provider (IdP).
+'''Use Case Description:''' Use existing strongly authenticated employee identity certificate to create claims that are accepted by employer approved web sites, either internal or external to the employer's enterprise. While this use case focuses on the employee-employer relationship, it would work equally well for any case where their is a contractual relationship between the user and the identity provider (IdP).
 Contributor: Tom Jones