- Identified (or Recognized)
- Presentation Authorization – A certain set of information (general, specific, or personalized) is displayed on the screen or can be printed. There is no direct method to change this level (such as hidden content with a link).
- Transactional Authorization – A certain set of transactions (general, access-controlling, or liability-inducing)
- Management Authorization – Most users can only manage their profile. Some can manage multiple profiles. Some (e.g. customer care) can perform certain functions over multiple profiles. These are further subdivided into having degrees of Presentation or Transactional Authorization for each of the other profiles they can view and/or manage. Even if not in scope at the moment, you must consider it during the design of the system
Anonymous:A customer visiting your site, who has never visited before or is visiting on a computer without a cookie (such as a friend's or at the library) will not be identified, and receives only general content. There are other schemes aside from cookies, but they are most common, so assume that for planning purposes. Links to various types of personal information or authenticated-customer services are displayed, and if selected will either:
- Allow use, but will not save information. The kitchen planner today works like this, and intercepts for authentication on save or exit.
- Inform the user they are only for customers, providing significant amounts of introductory content and a link to authenticate or register.
- Intercept with an authentication dialogue, demanding credentials (or enticing to register) or allowing the request to be abandoned.
Identified:The customer has visited the site before while authenticated, and the client computer can accept cookies. On this visit, Lowe's.com recognizes the cookie, matches it to a user profile, and presents complete customer information (minus the usual masking of values that should not be sent over the internet, such as passwords and credit card numbers). The customer can perform simple transactions that do not induce access control changes or liability, and are not too destructive (without recovery). They may not change access-controlling or liability-inducing information. They may have limits on changes to personal information. For example, items will be able to be added to or removed from the Home Profile, but deleting the whole Home may not be allowed. The following is a sample set of transactional features that are not available to the Identified session:
- Change password, or recovery information
- Change or add mailing address
- Change or add contact information
- Change or add payment methods
Authenticated:The customer has provided a username and password combination which is successfully recognized by the system. There are two methods to provide this:
- The customer entered the site as an anonymous user, and either deliberately signs on, or attempts to access an unavailable transaction (such as checking out with purchases). They enter both a username and passcode.
- The customer has entered the site and been automatically identified. When attempting to access an unavailable transaction (such as checking out) they are intercepted, and provide their passcode only. The username is pre-populated (or not displayed, but a proxy such as the customer nickname and avatar are displayed) during the request for additional credentials.
Access-controlling:Any feature that, if maliciously modified within one session, could prevent access by the owner, and/or redirect information about access away from the owner. Changing of credentials or contact information, basically.
Liability-inducing:Any feature that, if maliciously modified, could result in unauthorized financial transactions, or one that includes information that could lead to valid transactions being intercepted or otherwise repurposed.
Cross-Channel:The same identifiers should be used in all channels. All websites, all applications, in store, at home. Rules may vary between the access points. For example, the mobile application (and website) should (probably) sign on with the same credentials, then retain the customer entirely authenticated, relying on the device's security.
Identification Management:A cookie or similar key is placed on the customer's client machine. This is checked at each authenticated visit, and if no cookie is found a new one is created. No special first-use case must be developed. Since this key is on the client, and sent in plaintext, it must be secure. Do not place any intelligence in the key. It should not be the customer's name, location, customer ID, Keyfob ID, MEID, time created, store, card number, SSN or any other characteristic. It should not even be a random or encoded value using any customer-identifying information as the seed. All too often, these are cracked, with bad PR if you are lucky. It should be an entirely arbitrary key value, and nothing else. Make this key value as short as possible, to reduce bandwidth. Remember to not pad values for expected total sizes of the data store. The first users to register can have a key with the minimum secure/intepretable length, and then additional characters are added as the service grows. The key is sent to an authentication management service when the customer enters the site, and is looked up in a table to associate the key to a customer. That customer then has that authorization level.
User Management of Identification:It is usually best to simply set the cookie for all users. Those who do not like them will disable cookies across the board, or for our domain. If there are concerns, then a method can be provided for the user to manage this:
- A checkbox on the authentication dialogue (set to saving the cookie by default).
- A setting in the user's profile.
- Help documentation should be provided with as much information as possible, and links to privacy and security policies