doc/todo/credentials_page.mdwn

   1 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/credentials` page that is by default locked to the user and admins, where the user can state one or more of the below?
   2
   3 * OpenID
   4 * 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)
   5 * gpg public key (once there is a mechanism that relies on gpg for authentication))
   6 * https certificate hash (don't know details; afair the creation of such certificates is typically initiated server-side)
   7 * password hash (this is generally considered a valuable secret; is this still true with good hashes and proper salting?)
   8
   9 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]]
  10
  11 > I was just thinking about something along these lines myself. The
  12 > idea, if I understand correctly, is to allow users to have multiple
  13 > login options all leading to the same identity. This would allow a
  14 > user to login for example via either their Google account or their
  15 > WordPress account, while still being identified as the same user.
  16
  17 > However, I'm not sure this should be a static page (I guess you
  18 > mean `$USER/credentials`, I don't think ‘creditentials’ actually
  19 > exists). Something entirely managed at the CGI level is probably
  20 > better, as it also helps keeping the data in its place (such as ssh
  21 > public keys in `authorized_keys` etc).
  22
  23 > -- GB
  24
  25 >> having multiple login options leading to the same identity, and (more important to me) giving the user an easy way to review and edit them. i'm thinking a bit of foaf+ssl style "i am $USER and you can recognize me by my client certificate $CERTIFICATE" statements.
  26 >>
  27 >> the reason why i want this in a static place instead of cgi level is that it can be used, for example, for automatically creating htpasswd files for read-only (cgi-less) replicas of private wikis. furthermore, it all gets versioned and it can easily be seen where the data really is. the credentials have to be filed appropriately by plugins anyway, but that can happen as a part of the regular rebuild process.
  28 >>
  29 >> and yes, you're right about the word misusage; thanks for pointing it out and fixing it.
  30 >>
  31 >> --[[chrysn]]
  32
  33 an issue to be considered: for ways of authentication that don't explicitly mention the user name (and that would be everything but password; especially OpenID), there has to be a way to prevent users from hijacking an admin's account. the user wouldn't get more privileges, but the admin could find himself logged in as a user instead of an admin when he logs in using his OpenID, for example. he could fix it by removing the openid from the user's ("his") page, but it has to be taken care of nevertheless. --[[chrysn]]