As a developer this is what you do - make your usernames be email addresses. Make your login screen have a special button and POST to the special place (View Source on the example page to start). It should only have a username portion, no password portion should be necessary (yet). Specify the page you wish the user to be returned to upon succesful login. Make sure it's a bare page - no URL parameter or anything. If there's any context you want to maintain for the user, you will need to do so in a session of some sort, using cookies, on your server. BTW, you may want to cookie that username field so it's auto-filled on subsequent visits of our user.
On the return page you specified, you will have to handle a big blob of crypto data (Your URL will have a parameter appended to it - "?crypto=abcdef123..."). Decrypt it using the public key (That's a lot harder than it sounds, look at the code on the landing page for a start). In that blob of data, you will find URL paramters specified like "blah=blah&blah=blah..." - of which, you're concerned about 3 - url should be the URL you're now displaying to the user. timestamp should be relatively close to 'now'. And email is the user's email address. They're authenticated now. Take a look.
When he clicks the 'login' button, he gets sent here, and given the chance to log on, sign up, or do a one-shot authentication (the system sends him an email in either of those two cases). Once the user has clicked the email, he gets sent back to your site. If he'd already logged on today, his new logon attempt would just throw up a confirmation screen and he just ahs to hit 'continue'. This is to ensure that any time the user submits his information anywhere, it's always a deliberate choice.
None. This system provides Authentication, not Identity. Identity is your problem. All you get is an email address, and an assurance that that person is who they say they are.