update

[ikiwiki] / doc / todo / Separate_OpenIDs_and_usernames.mdwn

I see OpenID more as an authentication technology than as a human-friendly identifier. It would be cool if, in addition to my identity URL, I could also associate a username with my account. I'd then use the URL to log in, but all changes would be associated with the username I provide. Additionally, I could sign changes with my username, possibly change my identity URL and set a password. It would be nice if I could use my identity URL for authentication convenience and actually be known as nolan or thewordnerd on my wikis, rather than the somewhat less human http://thewordnerd.info. :)

Separating username from identity URL would also let me change the URL later. It would be nice, for instance, if I could assign a username to my account and change the identity to my preferred thewordnerd.info once delegation is supported, without the potential of losing access to my account and contributions. :)

I see this being implemented in one of two possible ways. The easiest seems like it'd involve splitting the fields, doing a simple OpenID verification as is done today, then allow setting of username on the preferences page. When crediting a user for a change, call a function that returns either the username or, if it is null, the identity URL. Then, allow logging into the same account with the username, but only if the password is non-blank. That seems like the most minimal and least invasive way of making the change.

A slightly more complex next step would be to request sreg from the provider and, if provided, automatically set the identity's username and email address from the provided persona. If username login to accounts with blank passwords is disabled, then you have the best of both worlds. Passwordless signin, human-friendly attribution, automatic setting of preferences.

> Given that openids are a global user identifier, that can look as pretty
> as the user cares to make it look via delegation, I am not a fan of 
> having a site-local identifier that layered on top of that. Perhaps
> partly because every site that I have seen that does that has openid
> implemented as a badly-done wart on the side of their regular login
> system.
> 
> The openid plugin now attempts to get an email and a username, and stores
> them in the session database for later use (ie, when the user edits a
> page).
> 
> I am considering displaying the userid or fullname, if available,
> instead of the munged openid url in recentchanges and comments.
> It would be nice for those nasty [[google_openids|forum/google_openid_broken?]].
> But, I first have to find a way to encode the name in the VCS commit log,
> while still keeping the openid of the committer in there too.
> Perhaps something like this (for git): --[[Joey]] 
> 
>       Author: Joey Hess <http://joey.kitenet.net/@web>
> 
> Only problem with the above is that the openid will still be displayed
> by CIA. Other option is this, which solves that, but at the expense of
> having to munge the username to fit inside the email address,
> and generally seems backwards: --[[Joey]] 
> 
>       Author: http://joey.kitenet.net/ <Joey_Hess@web>
> 
> So, what needs to be done:
> 
> * Change `rcs_commit` and `rcs_commit_staged` to take a session object,
>   instead of just a userid. (For back-compat, if the parameter is 
>   not an object, it's a userid.) Bump ikiwiki plugin interface version.
> * Modify all RCS plugins to include the session username somewhere
>   in the commit, and parse it back out in `rcs_recentchanges`.
> * Modify recentchanges plugin to display the username instead of the
>   `openiduser`.
> * Modify comment plugin to put the session username in the comment
>   template instead of the `openiduser`.

Unfortunately I don't speak Perl, so hopefully someone thinks these suggestions are good enough to code up. I've hacked on openid code in Ruby before, so hopefully these changes aren't all that difficult to implement. Even if you don't get any data via sreg, you're no worse off than where you are now, so I don't think there'd need to be much in the way of error/sanity-checking of returned data. If it's null or not available then no big deal, typing in a username is no sweat.

[[!tag wishlist]]