Merge lp://staging/~joe-topjian-v/django-openid-auth/jtopjian-dev into lp://staging/~django-openid-auth/django-openid-auth/trunk

Sorry for not reviewing this patch earlier. Note that email addresses are only self asserted, so unless you have some other reason to trust the provider you shouldn't treat them as validated.

I wonder if a better approach would be to ask the user for the required information if it is not provided?

My opinion is that if the application I am creating is unable to trust various OpenID providers, I should not be allowing them to be used for authentication at all. If I choose to trust an OpenID provider for authentication, I should also be able to trust them as a central repository for any other information as well.

However, I understand that checking for various user attributes should not be the responsibility for django-openid-auth -- the "auth" in the name can be seen as it is for authentication only.

There are certainly use cases for accepting user details from an OpenID provider you don't fully trust.

The only thing the OpenID protocol tells you for a given OpenID authentication handshake is that the user controls the given identity URL (this is roughly equivalent to proving that the user knows the password associated with a particular user name).

When I say that all other details are self asserted, I'm not saying that they are useless. There is a lot of self asserted information many applications would be happy to accept without verification (e.g. the user's full name). My point was that if you need verified information, then self asserted details from the OpenID handshake are as good as details entered into a form by the user. It doesn't mean the authentication is compromised.