Authenticate Person, With Token and LOA Process Flow Use Case

From IDESG Wiki
Jump to navigation Jump to search

Title

Authenticate Person, With Token and LOA Process Flow Use Case
Reference: https://www.idecosystem.org/wiki/Authenticate_Person_Use_Case Authenticate Person Use Case

Use Case Category

Authentication Related

Contributor

Scott Stephenson, info@trustedinternetidprovider

Use Case Content

Use Case Description

This Use Case only addresses how the Internet User’s Token and LOA are verified to be trusted. Private information exchange would only occur after the Token Process Flow has been completed.  

When a Internet User is initially requesting an RP’s resource, the only information that the RP will have is that the Internet User has a Un-Trusted Token. The RP will not have access to any of the Internet User’s private information.

Summary Process Flow: IDP issues a Trusted Token to the Internet User >>> Internet User sends their Un-Trusted Token to RP. >>> RP sends the Internet User’s Un-Trusted Token to the RP’s IDP for verification of Token. >>> RP’s IDP replies to the RP.

Scenario: A Internet User, who has been issued a Trusted Token, is seeking to gain access to an online Relying Party (RP) resource. The RP sends the Internet User’s Un-Trusted Token to the Relying Party’s Internet ID Provider (IDP) for verification. The Relying Party’s IDP will verify the Token and then send a Token Verification Message back to the RP indicating whether or not the Internet User’s Token is valid and indicating the Internet User’s Level of Assurance Answer (LOAA). The RP, if they chose, can then allow the Internet User access to browse the RP’s resources.

 

Actors

  • Anonymous Interaction – An interaction designed such that the data released and collected is not sufficient to infer the entity involved nor is such data sufficient to permit a relying party to associate multiple interactions with the entity. (Source: http://www.idmanagement.gov/Library)
  • Attribute Providers (AP) Any AP that has been approved by the IDESG or by a approved IDESG IDP.
  • Trusted Framework – Any framework in which an IDESG Community of Interest organization is using to ensure Trusted Identity Management processes are being enforced. The Framework will define the rules on how the various ID Ecosystem providers interoperate in terms of business, legal, technical and privacy guidelines. (Modified definition from source: http://www.iddataweb.com/?page_id=94)
  • Identity Provider (IDP) – Any approved by IDESG IDP. Performs verification of the Internet Users attributes submitted to the IDP by Attribute Providers. If the User is validated, issues the Internet User a Trusted Token and a LOA assurance level.  
    • Accepts Internet User’s Un-Trusted Token from a Relying Party and verifies the Internet User’s Token and LOA assurance level.
  • Internet ID Domain – Approved by IDESG IDPs will create secure encryption tunnels which will create an Internet ID trusted virtual domain using secure industry standard internet connections. The purpose for an Internet ID domain will be to maintain a Token List that will validate and verify the Internet User’s Token with the Token submitted by a RP and a source for the Internet User’s LOA and private information.
  • Internet ID Domain Network Core VPN Router (VPN Router) – This network Core Router will be the initial router that IDESG IDPs will create secure encryption tunnels with.
    • The Core VPN Router will be the source router for all IDP VPN tunnels.
    • The Core VPN Router will be in charge of all routing between IDPs.
    • The Core VPN Router will be included, modified or replaced upon the development of an industry internet standard fault tolerant network configuration which provides extremely high levels of availability and reliability for network connections.
  • Internet Users (IU) – Human Users who want to obtain Anonymous Interaction and private access to an approved IDESG Relying Party resource via the internet.
  • Level of Assurance (LOA) – The Internet User’s measure of trust that the Relying Party requires in order for Users to access the RP’s private or public resources. After the RP has received the Token from the Internet User, the RP will set the Internet User’s LOA to equal zero (LOA = 0), which indicates that the Internet User has a Non-Verified Token. The RP, if they chose, can then allow the Internet User to browse the RP’s public resources anonymously.
    • The RP, if they chose, can contact their IDP to verify the Internet User’s LOA before allowing access to the RP’s public or private resources.
    • The LOA will be modeled similar to LOA RFC 6711. http://tools.ietf.org/html/rfc6711
      • Level of Assurance (LOA) 1: Little or no confidence in the asserted identity’s validity. 
      • Level of Assurance (LOA) 2: Some confidence in the asserted identity’s validity. 
      • Level of Assurance (LOA) 3: High confidence in the asserted identity’s validity. 
      • Level of Assurance (LOA) 4: Very high confidence in the asserted identity’s validity. (Source: http://www.idmanagement.gov/Library)
  • LOA Assurance Level Answer (LOAA) – The LOA assurance level answer is sent from the RP’s IDP back to the RP. The LOAA answer will be to the questions: “This is a Internet User’s Token. Is the Token Valid? The Internet User is requesting LOA = X. Does the User have this LOA?
    • The RP’s IDP will answer: Yes/True, Yes/False or No/False
    • The actual Internet User’s LOA level will not be sent to the RP.
    • It is believed that the number of LOA assurance levels will increase exponentially as more COIs join the ID Ecosystem. (Example: U.S. military will have a minimum of 9 different LOA levels)
  • Relying Party - (RP)   Any approved by IDESG or by IDESG IDP’s Relying Party. Requires a Token and Level of Assurance (LOA) verification from the RP’s Identity Provider (IDP) for the authentication and authorization of the Internet User requesting access to the RP’s resources.
  • Relying Party Public Resources –All information that the Relying Party has chosen to release to the general public without any Authentication, LOA = 0 (Anonymous Interaction browsing is allowed).
  • Relying Party Private Resources All information that the Relying Party has chosen to not release to the general public without authentication and authorization processes being completed, LOA > 0. (Anonymous Interaction browsing is not allowed).
  • Token – An IDESG COI Electronic key issued to an Internet User by an approved IDESG Identity Provider (IDP) to prove the User’s identity electronically.
  • Token List – Will be modeled similar to the Domain Name Service DNS technology (RFC 4033, 4034, 4035, ect. https://www.icann.org/resources/pages/standards-2012-02-25-en). Instead of storing Domain Names to IP addresses, the Token List will store the Internet User’s Token and LOA assurance level in order to verify the Token received from the Relying Party. The Token List is controlled by the IDPs. RPs do not have access to the Token List.
  • Token Verification Message – A message from the IDP to the RP, that indicates whether or not the Internet User’s Token is valid and the Internet User’s LOAA answer. The IDP’s LOA is the resource that the Relying Party will use to complete the authorization process for a User to have access to the RP’s resources. This message will be modeled similar as the existing RFC1122 http://tools.ietf.org/html/rfc1122 (TCP 3-Way Handshake: Synchronize >>> Synchronize >>> Acknowledge)
  • Un-Trusted Token – A token that is received from the Internet User by the RP. The Token remains in the Un-Trusted state until the RP receives a Token Verification Message from the RP’s IDP.

Assumptions:

  1. Internet User has selected an IDP and granted them permission to complete all steps required for the Internet User to be issued a Token and LOA assurance level.  

  2. The Internet User has chosen and granted permission to their APs to release their personal information to the Internet User’s IDP. The Internet User’s LOA assurance level is determined from the information that the APs provide to the IDPs.

  3. The Internet User’s IDP has issued the Internet User a Trusted Token.

  4. The Internet User’s IDP has determined the Internet User’s LOA assurance level.

  5. Relying Party (RP) will pay for a Trustmark, a Token and a subscription/service to an IDESG approved ID Provider (IDP) to provide the RP with a service that will verify the User’s Token and LOA assurance level.

  6. The RP is approved by an IDP and receives a Trustmark & Token.

  7. The Trustmarks & Tokens issued by any IDESG IDP will be trusted by all of the other IDESG COI organizations.

  8. All interactions between Internet Users and RP which includes a Internet User’s Token is completed via a Secure Socket Layer (SSL RFC 6101 http://tools.ietf.org/html/rfc6101) or Transport Layer Security (TLS RFC 5246http://tools.ietf.org/html/rfc5246) connection.  

  9. The IDP and RP networks have created a secure encryption tunnel to form a trusted Internet connection. Internet Users will not have access to this tunnel.

  10. All IDESG IDPs are connected to the Internet ID Domain Network Core VPN Router (VPN Router). RPs will not have access to this tunnel.

  11. Using standard internet network security protocols, the RP will not have access to the Internet ID Domain or the IDP’s Token List. This will be modeled similar to OSPF standards for Area Border Routers (ABR) RFC 1247 and 1583 http://www.rfc-editor.org/search/rfc_search.php . This is to ensure proper Trusted Framework integrity.

  12. The Relying Party, and only the RP, will determine whether the Internet User’s LOA assurance level that is verified by the RP’s IDP is sufficient to allow the Internet User to access the RP’s resources.

  13. The RP’s IDP will be the only IDP that the RP will be able to receive a message from that verifies a User’s Token and LOAA. The RP cannot contact an IDP that the RP did not receive their Trustmark and Token from for the Internet User’s Token and LOA verification. This is to ensure proper Trusted Framework integrity.

 

Process Flow:

  1. When an Internet User with a valid or invalid Token, contacts an RP to request access. The User is prompted to choose the IDP that they were approved by and the LOA assurance level they are requesting. This can be modeled similar to reCaptcha real Internet User verification process. https://www.google.com/recaptcha/intro/index.html"

  2. After the RP has received the Token from the Internet User, the RP will set the Internet User’s LOA to equal zero (LOA = 0), which indicates that the Internet User has a Non-Verified Token.

  3. For Anonymous Interaction browsing with an Un-Trusted Token: The RP, if they chose, can accept the Internet User’s Un-Trusted Token and allow Anonymous Interaction browsing to the RP’s public resources.

  4. For Anonymous Interaction browsing or private browsing with a Trusted Token: The RP sends the Internet User’s Un-Trusted Token and the requested LOA level to the RP’s IDP. If the user was approved by the RP’s IDP, the RP’s IDP queries their User Token List and then sends a Token Verification Message to the RP which verifies the User as a Trusted User and will provide an LOAA answer. The RP can then either modify the LOA access level to the level that the Internet User selected and allow the User access to the RP’s public or private resources or disallow access to the resources.

  5. If the RP’s IDP did not issue the Internet User’s Token, the RP’s IDP forwards the Internet User’s Un-Trusted Token and the requested LOA level to the Internet User’s IDP to verify the User’s Token and LOAA. When the User’s IDP responds with the requested information, the RP’s IDP will forward the Internet User’s IDP Token Verification Message to the RP. The Internet User’s IDP is the only IDP that can send a message verifying the User as a Trusted User and can provide an LOAA answer. The RP can then either modify the LOA access level to the level that the Internet User selected and allow the User access to the RP’s public or private resources or disallow access to the resources.

  6. After the RP’s IDP receives the User’s Token and LOA information from the User’s IDP. The RP’s IDP will only retain the User’s IDP Token Verification Message information until the RP has acknowledged receiving the Token Verification Message. The User’s Token Verification Message will then be deleted. This will prevent multiple User LOAs if the User’s LOA assurance level changes. This is to ensure proper Trusted Framework integrity.

  7. During the RP IDP’s Token verification process, if there is a conflict where the Token information that is received from the RP or another IDP occurs. An alert message is sent out to all Internet ID Domain members, to invalidate the current Internet User’s Token until action is taken to resolve the alert.

  8. When a conflict occurs, the IDP sending the alert message will send the Token and change the LOA to equal -1. (LOA = -1)

  9. Only the Internet User’s IDP can change the LOA back to the correct level after resolving the alert. This is to ensure proper Trusted Framework integrity.

  10. When the Internet User no longer requires access to an RP’s resources and logs out or is timed out by a measure of time chosen by the RP. The Internet User’s LOA that the RP is using to allow access to their resource is reset to zero (LOA = 0). This Flow Process will need to be completed again, when the user wants to reestablish a connection with the same RP.

 

Success Scenario

The Relying Party is able to verify that the Internet User is a trusted user and can determine whether or not the Internet User has the RP’s required LOA assurance level to access the RP’s resources.

Error Conditions

  • Internet ID Provider cannot verify the Internet User’s Token or LOA assurance level.
  • The Relying Party rejects the LOA of the Internet User.
  • The Relying Party is unable to authorize the Internet User, even after verifying the Internet User’s Token and LOA.

Relationships

Extended by:
Authenticate Using Pseudonymous Identity Use Case https://www.idecosystem.org/wiki/Authenticate_Using_Pseudonymous_Identity_Use_Case"
Authenticate Person Use Case https://www.idecosystem.org/wiki/Authenticate_Person_Use_Case

References and Citations

 

Retrieved from "https://wiki.idesg.org/index.php?title=Authenticate_Person,_With_Token_and_LOA_Process_Flow_Use_Case&oldid=373"