There are lots of people adding support for OpenID to their apps (awesome!) but there are some issues that will invariably cause confusion in these implementations if we don't develop some best practices around interaction design.

Basic questions

What username should you give someone signing up with OpenID?

This depends on how the username will be used (if at all). It's not uncommon to use the SREG openid.sreg.nickname attribute to auto-populate this value.

In the case of collision, you could ask if the person has already signed up to your service before using that username, and if so, to have them provide the password for that account to associate the OpenID they've just verified with the existing account; if not, then you simply ask them to provide an alternative username.

Now, since you're using OpenID as the unique identifier, you really don't need the username/nickname, except for, perhaps, their profile URL. Keep that in mind, as you might refer to this as a "vanity URL" instead of "username".

Should signup and login with OpenID be two different processes?

Not exactly.

The first step of any OpenID flow is to ask for the user's OpenID URL (either by directly providing the URL or using a mediated interface, like Blogger's comment form).

Once you've verified their OpenID, then you proceed to the normal account creation process if they've never logged in before. You should try to import and auto-populate any profile forms with data available via SREG, Attribute Exchange, hCard Import. This is especially true for basic data like first and last names, timezone, country and the like. Don't make someone fill out forms that they've already taken the time to fill out elsewhere!

If the person has logged in before, you simply continue on as though it were a normal login flow.

We need the person signing up to check the EULA acceptance box

Nothing about OpenID prevents you from putting up barriers like EULAs in the account creation process. OpenID lets people use existing credentials and optionally import data from their Identity Provider, but doesn't mean that you don't have control over your sign up process.

If someone verifies their OpenID but then aborts the signup process before agreeing to the EULA, their account is simply flagged as needing to agree to the EULA before they can begin using the site, just as you would do for someone who hasn't verified their email address.

In any case, you can still have whatever checks and mandatory data requirements you want in your signup process. OpenID doesn't restrict you in that way at all.

What about confirming email addresses? (the email provided by SREG et al won't necessarily be verified)

Same as before. Since they're using OpenID to sign in, one presumes that they'll be able to use OpenID to login again, obviating some reliance on the email address.

All the same, you simply send out a confirmation email to the email address they've provided and wait for them to confirm it. If provided a false (or accidently incorrect) email, what difference does it make? They can still login with their OpenID and then add other email addresses under their account settings, just as they should be able to do otherwise.

People who use OpenID can't use OpenID inside of our desktop application

Ah ha! Actually then can, thanks to the development of OAuth. OAuth was designed to specifically solve this problem by providing a delegated authorization protocol that is compatible with OpenID (and any other authentication protocol).

There are even libraries to make it easy to implement.

For existing accounts

Associating accounts with OpenIDs

Limited Betas with OpenID

Using invite codes

BricaBox's private beta requires an invite code and the use of the email address that you received the code at when you sign up. They allow you to sign in with OpenID but unfortunately it seems that unless you've previously associated an email-based account with your OpenID, it'll complain that it doesn't recognize your OpenID, even if you have a valid invite code.

The problem with this scenario is that, once I've received my invite email, it should matter how I sign in. Once I've proven that I have a valid invite code (since I received the email), I should be able to sign in with my OpenID.

If they wanted to make sure that I sign up with the same email address that was invited, they should remove the "sign in with OpenID" option until later. Of course this kind of defeats the profile portability benefits of OpenID.

Using Whitelists

--