View the Project on GitHub BigBlueHat/userinfo

I've been typing email addresses into browser address bars for over a decade. Now, I want something back.

A User URI Scheme


mailto and (more recently) acct provide methods of identifying an entity (person, bot, etc) by an email address-like identifier.

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 -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:

                                                          +---------------+    +------------------>     |               |
                                                          |               |
                                  GET /                   |               |
                                  Host:    |     Server    |
                                  User-Info: byoung       |               |
         +          +                                     |               |
<html>   |  {       |            <------------------+     |               |
         | "k": "v" |  triples                            +---------------+
</html>  |  }       |              200 OK
         +          +              Content-Type: ...

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 as an HTTP Basic Authorization header. In the example URL above, the outbound request sent by curl (and most other HTTP clients) looks like:

GET / HTTP/1.1
Authorization: Basic YnlvdW5nOg==
User-Agent: curl/7.26.0
Accept: */*

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:


Given this URL,, 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).



Returns HTML + microformat hCard markup (at the moment).

curl -H "Accept: text/turtle"

Returns a WebID document.

curl -H "Accept: image/jpeg" > byoung.jpg

Returns a photo.

Test it!

Yeah, so?

For me, this means a RESTful endpoint for myself. It's trivial to use content negotiation to deliver a profile pic (in various formats) and social or authentication related markup: FoaF, XRD, JRD, OpenID Connect Profiles, HTML + hCard + OpenID discovery meta tags, etc.

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


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.


All code is licensed under the Apache Foundation License 2.0.