A User URI Scheme

The userinfo portion of a URI
per RFC 3986
provides for such a format in URI design (emphasis added):

The userinfo subcomponent may consist of a user name and, optionally,
scheme-specific information about how to gain authorization to access
the resource.

Additionally, the userinfo portion of
the URL is mentioned in the WHATWG URL spec as follows (emphasis added):

Userinfo must be a username, optionally followed by a ":" and a password.

In HTTP the userinfo portion of the URL has been used exclusively for authorization. However, other protocols (SSH, XMPP, SMTP) have used the userinfo portion for identification. HTTP should have the same facility and now it can.

The Plan

Introduce a User-Info header to request user / agent
information from a domain.

Doing this now with curl (or any other HTTP client) looks like
adding the proposed User-Info header to the request. For instance:

curl http://bigbluehat.com/ -H 'User-Info: byoung'

Which is obviously not as pretty…yet.

If implemented natively in an HTTP client, the flow would look something
like this:

The userinfo portion of the URI now becomes the User-Info
header in the HTTP sent to the server. Or that's The Plan.

Doing it Now

HTTP clients will currently send URLs in the format of
http://user@example.com/
as an HTTP Basic Authorization header. In the example
URL above, the outbound request sent by curl (and most other HTTP
clients) looks like:

The Authorization header contains the authorization schema (Basic)
and a Base64 encoded
string containing username
byoung and typically
a :.

The User-Info header is the preferred method, but if that's not
sent, we have the information we need in this style of Authorization
header. As such, it's recommended that implementations
handle these fallback HTTP Basic requests, including any of the following, each
of which have been spotted in the wild:

base64($username)

base64($username + ':')

base64($username + ': ')

Clients

Given this URL, http://user@example.com/, client implementations
SHOULD send the User-Info header (as seen above).
Only Server implementations should care about the Authorization-based fallback
(essentially because your HTTP client already sends them now without
modification).

At the very least, implementations can benefit from URLs in this style,
and could send 302 response codes redirecting
to a current social network profile document or social stream, such as
http://twitter.com/bigbluehat

Contribute

The biggest need right now is client testing,
reporting, and patching / implementation of the User-Info header
and URL parsing. Please use
the issues on the `userinfo` repo
to send in your thoughts, stories, and implementation details.