Commentary by Mark Wahl, CISA
Organizing principles for identity systems:
Embedded and pure play identity providers and attribute validity (20070612)
Dave Kearns replies to my suggestion from yesterday (that users sign values stored by their identity provider) in "IdP marketing 101" that
"... any one [IdP] which provides no mechanism for correcting erroneous information won't stay in business very long. The user has the choice of which IdPs to use, the market competition will be the same as in any service industry - IdPs will compete for your business (as do banks, insurance companies, etc.) based on the perceived value of the service."
I agree that if the metasystem is made up of "pure-play" IdPs, identity providers who merely provide an identity data storing and claim generation service to anyone, then IdPs which provide consistently incorrect information should disappear.
However, the original message from Mike Jones noted the desire for a third party to be able to validate claim values as accurate. For example, for an IdP not run by Yahoo, a "Yahoo IM screen name" attribute is a self-asserted attribute. Some relying parties might not care for the accuracy of this claim, but other relying parties might wish to know that Yahoo believes that the asserted IM screen name for the associated individual is correct. If this is important, then it should be made explicit, just as the ability for a user to assert the validity of their information. How recent that validity assertion was made may be particularly important.
I find my credit report often has invalid data (misspelled/truncated company names), various government agency databases can't seem to handle building addresses with no house number or street name, and I am sure that some of my past employers, banks, insurance companies, internet service providers, have at one time or another had addresses or phone numbers that were no longer valid due to a move. It might take a few days or weeks to figure out that an organization has the wrong address, and even longer to have it corrected. Some of these organizations might choose to operate identity provider services.
- Even if the user detects the information held by the IdP is invalid, and the IdP allows it to be correct, the process for correcting invalid data may not be instantaneous.
For example, the US Federal Trade Commission Credit Reports: What Information Providers Need to Know summary of the FCRA notes that information providing organizations must not supply to credit reporting agencies information that the organization knows to be incorrect. However, if the organization is notified by the credit reporting agency that the consumer is disputing the accuracy of information, the organization must investigate, and if it finds the information to be inaccurate, correct it "within 30 days".
For another example, Dun and Bradstreet allows currently active commercial businesses to update some of their information online, but government entities must use an offline process.
- The identity provider may be supplying information to a relying party which the user does not immediately determine is invalid.
For example, a user who has moved might remember to update their mailing address but forget to update their telephone number (the user might not discover their new mailing address and new telephone number simultaneously). Packages from relying parties continue to be delivered, now to the revised address, but if months later a relying party needs to call the user about an order, they'd find the phone number was no longer valid.
- The identity provider may be supplying information to relying parties in transactions that do not involve the subject.
It is desirable for users to be able to attach statements to their information to be provided for the benefit of relying parties, if they are not an intermediary in the transaction. Analogously, the FCRA 611(b) requires a credit reporting agency to accept a short statement made by the user and attach it the user's credit report.
- The identity provider may not allow updates by the user.
One or more identity providers may be incorporating public record database information into the user's profile. The user might not be able to update that information at any identity provider. The originators of the data may not wish to operate as an identity provider.
- The identity provider may have other lock-in for which the user is willing to accept some degree of invalid data.
For example, if Sun Microsystems operates an identity provider for its employees, then the employee might not be able to switch to another identity provider when a relying party offers a service that is tied to the Sun IdP.
In general it is useful for a subject-verified identity claim to ensure the relying party is not working based on stale information. For example, a relying party might request an attribute that the user has reviewed "in the last 3 months". In some scenarios, the user may be able to provide more information. Particularly, university identity providers may have a user assertion of notValidAfter for their user's on-campus address.