Page Comparison

...

1. A "server policy" is defined that maps names and numbers to combinations of authentication handlers
2. Each "authentication handler" has an "interaction" registered which determines how credentials are gathered.  It could be user-interactive (show a screen) or automatic (fetch a cookie).
3. There should be some kind of precedence to determine which interactions are default.
4. When a request for authentication, the following happens:
   1. The server determines the LOA policy for this service
      1. Look in the service registry to see if the service is registered and has an LOA policy defined.
      2. Look for an LOA parameter.  The LOA parameter is a comma separated list of all LOA values that are acceptable.  A numeric value means: "every LOA with this value or higher".  A named value means: "also this individual level even if it is numerically lower".  Only one number should be included in the list, but the list can have multiple named levels.
      3. If both a pre-registered LOA requirement and a parameter exist, combine them in a way that makes sense and is secure.  (that "way" is to be determined)
      4. This combination could be labeled the "client LOA policy"... it defines what levels of assurance are deemed acceptable to the client
   2. Check the user's current status (list of all handlers that have already successfully authenticated) and determine if the user already satisfies the "client policy".  If so, generate the service ticket and redirect the user back to the service immediately.
   3. Otherwise...  The server determines which interaction(s)it needs to show to the user
      1. Find all rows in the "server policy" table that will satisfy the service's LOA requirements.  Each row contains a list of authentication handlers that must be satisfied, possibly each with some attributes.
      2. For each row, determine if the user has already authenticated using any of the authentication handlers required for that row.  If the user already authenticated with this method, but the attributes aren't satisfied, remove this row from the list of possibilities and also make a note about the unsatisfied attribute(s).
      3. If no rows are found, show the user an error message.  The error message may include information regarding the unsatisfied attributes (such as "your password strength is too weak")
      4. Make a list of possible authentication handler chains based on the lists of authentication handlers for each row.  Remove all already-authenticated handlers from the chains.  Remove any empty chains.
      5. Look at the first authentication handler that remains in each chain. Look up the interaction that is registered for that action.
      6. Perform all automatic interactions (like fetching a cookie).
      7. If multiple user-interactions exist, choose the "default"
      8. Make a list of all alternate interactions, and put that list into the HttpServletResponse.  Every interaction's JSP should include a standard snippet of code that displays these options, allowing the user can pick one of these alternatives if desired.
      9. Probably:  Make a list of the first authentication handler in each chain and put that list into the HttpServletResponse.  This is important if you have a single interaction that is designed to be used with multiple authentication handlers, such as a login screen that includes an optional "connect with Facebook" button.  The interaction's JSP will probably want to take this list into account when showing or hiding various options.
      10. Display the interaction's JSP page
          1. Note that some interactions, even user-interactive ones, might not need to show a JSP page by default.  For example, an OAuth interaction could immediately redirect the user to the OAuth server's login page.  However, this would present a problem if there are any alternate interactions, because the user would not have been given the chance to choose one of the alternates.  In this case, a JSP probably should to be displayed to give the user the choice.
   4. Follow the interaction's code.
   5. Once the interaction has been completed, go back to step "a" until either 1) LOA is fulfilled (see step "b"); or 2) no rows can be found that will satisfy the policy (see step c. iii.)
   6. The server adds all relevant LOA data to the user's session authentication object's, generates the service ticket, and later includes those LOA details in the ticket validation response.

...