Federated Strong Employee ID: Difference between revisions
Line 48: | Line 48: | ||
=== References and Citations === | === References and Citations === | ||
* [http://www.tscp.org/privacy-employer-ids/ Privacy using | * [http://www.tscp.org/privacy-employer-ids/ Privacy using Employer issued Identifiers] from http://tscp.org | ||
* | * | ||
Latest revision as of 23:13, 20 May 2020
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:
Relationships
- Extended by:
- Extension of: