W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2020

Re: Adding user@ to HTTP[S] URIs

From: Rick van Rein <rick@openfortress.nl>
Date: Mon, 27 Jan 2020 13:22:38 +0100
Message-ID: <5E2ED60E.8070304@openfortress.nl>
To: Amos Jeffries <squid3@treenet.co.nz>
CC: ietf-http-wg@w3.org
Hi,

>> Compatibility with other protocols: You cannot copy/paste your gmail
>> address to your browser to access it as webmail.
>
> Counterpoint: I (and many, many others) cannot do that even with your
> spec change because the login to my gmail account is a name and domain
> completely different to the email address URI. A government department
> is the credentials authority - not Google or '@gmail.com'.


You are actually _making_ my point :)

The john.doe@gmail.com represents a resource according to the URI
specs.  Some HTTP implementations have forcefully tied it to
Basic/Digest authentication.  My point is that the authentication
pathway needs a completely different pathway.

In the spec, I used an example with just a username, but this line of
thinking easily extends to allowing forms like amos@jeffri.es as well.

The next step, and now I'm really warming up, is to allow the gmail
server to authenticate amos under the realm of jerffri.es.  That is
possible with these other drafts I've posted last week:

HTTP Authentication with SASL
https://datatracker.ietf.org/doc/draft-vanrein-httpauth-sasl/

Realm Crossover for SASL and GSS-API via Diameter
https://datatracker.ietf.org/doc/draft-vanrein-diameter-sasl/

This architecture allows you to authenticate to gmail.com with your
credential hosted at your example domain jeffr.es.

Point of order: This is a lot extra and we should not discuss it in this
thread; there are other threads and other WGs for the other specs.  I
only mention them here to answer the recurring "why" to the call for
more semantics and better separation of user names in resources and
authentication.  I hope it serves to show that this is not a frivolity.


Cheers,
 -Rick
Received on Monday, 27 January 2020 12:23:10 UTC

This archive was generated by hypermail 2.4.0 : Monday, 27 January 2020 12:23:11 UTC