doc/todo/creditentials_page.mdwn



pushing [[this|todo/httpauth feature parity with passwordauth]] and [[this|todo/htpasswd mirror of the userdb]] further (although rather in the [[wishlist]] priority): would it make sense for users to have a $USER/creditentials page that is by default locked to the user and admins, where the user can state one or more of the below?

OpenID
ssh public key (would require an additional mechanism for writing this to a authorized_keys file with appropriate environment variables or prefix that makes sure the commit is checked against the right user and that the user names agree)
gpg public key (once there is a mechanism that relies on gpg for authentication))
https certificate hash (don't know details; afair the creation of such certificates is typically initiated server-side)
password hash (this is generally considered a valuable secret; is this still true with good hashes and proper salting?)

such a page could have a form as described in [[todo/structured page data]] and could even serve as a way of managing users. --[[chrysn]]

I was just thinking about something along these lines myself. The
idea, if I understand correctly, is to allow users to have multiple
login options all leading to the same identity. This would allow a
user to login for example via either their Google account or their
WordPress account, while still being identified as the same user.


However, I'm not sure this should be a static page (I guess you
mean $USER/credentials, I don't think ‘creditentials’ actually
exists). Something entirely managed at the CGI level is probably
better, as it also helps keeping the data in its place (such as ssh
public keys in authorized_keys etc).


-- GB