Commentary by Mark Wahl, CISA
Organizing principles for identity systems:
Don't touch my claims if you please, Mister IdP (20070611)
One aspect of the InfoCard design is the separation between self-issued card interactions, in which the user generates a card and types in their claims values to be sent to the relying party, and managed card interactions, in which an identity provider stores and (indirectly) transfers the values of claims to the relying party. In the self-issued interaction, no identity provider is involved, and the claim values are known only to the user and the relying party. When an identity provider is involved, claims may be made "on behalf" of the user.
Last month Mike Jones of Microsoft wrote in Interoperable Verified Identity Claims that
"Verified claims are made by third party identity provider on your behalf, and have been validated in some fashion by the identity provider."
A variant of this consideration is, how to express the user's validation of a claim value to be sent by an identity provider on the user's behalf. It is desirable for a user to be able to state that they reviewed a particular claim with a particular value, potentially in the context of a particular relying party, and have this statement be provided to a relying party along with the claim. I'd call this variant the "subject-verified identity claim".
For example, a user might have a public/private key pair, and the public part is in a certificate available to relying parties. The user might sign a particular claim value, and wish to provide that signed claim to the identity provider. The identity provider can send that signed claim in subsequent interactions to relying parties. The identity provider cannot modify the value of the claim without invalidating the signature. This can increase the trust that users have in their identity providers.
In an enterprise IdP case, a user may wish to validate certain claims the identity provider makes about them, such as "address" or "telephone number", but not give their validation for others, such as "department code". Also, the user may wish to validate only certain values of a multi-valued claim: the identity provider might be storing multiple addresses for the user, and some may be incorrect. (Merely receiving claims should not lead to the relying party to the the presumption that the user belives the claim values are correct: the user might not be concerned with the accuracy of some of the claims.)
As with the verified identity claim, a relying party might ask for the base claim type (e.g., street address), but would give preference to one which has been verified.
Presumably the more verifications on a particular value, the better. Whether the relying party would prefer a value verified by a third party to a different value (recently) verified by a user would depend on the third party. A credit reporting service, for example, might have a 'verified' address for a user, but that is out of date as the credit issuers haven't yet notified the reporting service.