From c62a529a1aed3ceb5995d893f303be1bfef24726 Mon Sep 17 00:00:00 2001 From: "http://jmtd.livejournal.com/" Date: Thu, 27 Jan 2011 22:51:38 +0000 Subject: rename todo/creditentials_page.mdwn to todo/credentials_page.mdwn --- doc/todo/credentials_page.mdwn | 23 +++++++++++++++++++++++ doc/todo/creditentials_page.mdwn | 23 ----------------------- 2 files changed, 23 insertions(+), 23 deletions(-) create mode 100644 doc/todo/credentials_page.mdwn delete mode 100644 doc/todo/creditentials_page.mdwn (limited to 'doc/todo') diff --git a/doc/todo/credentials_page.mdwn b/doc/todo/credentials_page.mdwn new file mode 100644 index 000000000..42a63ad16 --- /dev/null +++ b/doc/todo/credentials_page.mdwn @@ -0,0 +1,23 @@ +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 diff --git a/doc/todo/creditentials_page.mdwn b/doc/todo/creditentials_page.mdwn deleted file mode 100644 index 42a63ad16..000000000 --- a/doc/todo/creditentials_page.mdwn +++ /dev/null @@ -1,23 +0,0 @@ -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 -- cgit v1.2.3