authority's userinfo?

[Petite Abeille]

> On Jun 10, 2020, at 13:15, Felix Queißner <felix at masterq32.de> wrote:
> 
> I don't think that user/password is the right way to handle
> authentication in Gemini.

Why not? Gemini mandates a secure communication channel (TLS) already. The userinfo is identical to the Basic Authentication scheme, but encoded the URL directly. Rather convenient altogether.

> The URL RFC also specifies:
> 
>> Use of the format "user:password" in the userinfo field is
>> deprecated.

This is more related to authentication over an open channel.

> So only user@… is still a valid URL.
> 
> If your server handles user@ in a different way than without authority,
> i think that's totally in-spec, but authentication is probably not.

I guess user@ could be any magic token/ticket, for the client to maintain a state on the server.

Perhaps a subset of 40 TEMPORARY FAILURE, e.g. 49 Unauthorized, would be an appropriate response if Authenticate: Basic is required by a resource. 

> One possible usage for authority could be home-dirs instead of an
> official site:

I was more looking into a way for the client to maintain some states (e.g. preferences) on the server:

C: gemini://token@mozz.us/?ua=lightweight -- user-agent store its preferences on the server
S: 30 gemini://token@mozz.us/index.gmi-- redirect to an appropriate resource
C: gemini://token@mozz.us/index.gmi -- lightweight version of the resource
S: 20 text/gemini -- customized as per the user-agent stated preferences

A bit of content negotiation in other words.

For all practical purpose, it serves the same purpose as the various 6x (CLIENT CERTIFICATE REQUIRED) statuses. Minus the burden of the actual TLS gymnastic.