Password authentication over Gemini

[Sean Conner]

It was thus said that the Great solderpunk once stated:
> >   There's no reason for the user to generate a certificate and then provide
> > a username/password when the certificate already has the username:
> 
> This is kind of neat, but would require the interface interaction that
> happens in response to a 61 to give the user the opportunity to specify
> these details.  At best, this is an unnecessary bit of UI friction in
> cases where it won't be used.  At worst, for very privacy-conscious
> users, being asked to specify any kind of personal information at all to
> include in something which is supposed to be an entirely ephemeral /
> disposable / transient will feel like a red flag, I suspect.

  You're already asking for clients to generate a temporary certificate. 
Before going too down far this rabbit hole, why not make a few temporary
certificates and hitting:

	gemini://gemini.conman.org/private/

  There's nothing there that generates a status of 10, but it is asking for
temporary certificates.  It's not even expecting any set information.  It
might be instructive to know what what is and isn't required for a
certificate.

> >   Not much there, other than to ask about having second thoughs about
> > certificate only authentication?
> 
> Sorry, can you clarify?  Do you mean second thoughts about only having
> certificates as a way to authenticate (i.e. are we sure we don't want
> passwords as first-class citizens?).  Or do you mean second thoughts
> about allowing authentication with only a certificate?  Why wouldn't we
> want to allow that?

  I meant I had no thoughts about your question re: status code of 11.  My
question to you was, why have a usernames/password scheme when you have
certificates, which are a combination of username/password?

  -spc