Associating URI-based identities with HTTP requests

Manu Sporny <> Fri, 10 May 2013 18:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D9FB221F8F2C for <>; Fri, 10 May 2013 11:33:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.547
X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[AWL=5.052, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6mWiFSszH+qQ for <>; Fri, 10 May 2013 11:33:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4E4AE21F8AA8 for <>; Fri, 10 May 2013 11:33:08 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1Uas7j-0006mY-0a for; Fri, 10 May 2013 18:32:55 +0000
Resent-Date: Fri, 10 May 2013 18:32:55 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1Uas7X-0006kf-RO; Fri, 10 May 2013 18:32:43 +0000
Received: from [] ( by with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <>) id 1Uas7A-0003CC-TH; Fri, 10 May 2013 18:32:43 +0000
Received: from ([] ident=msporny) by with esmtp (Exim 4.72) (envelope-from <>) id 1Uas6U-0002uw-Uj; Fri, 10 May 2013 14:31:39 -0400
Message-ID: <>
Date: Fri, 10 May 2013 14:31:38 -0400
From: Manu Sporny <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.5) Gecko/20120624 Icedove/10.0.5
MIME-Version: 1.0
To: HTTP WG <>
CC: HTTP Auth WG <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-2.8
X-W3C-Hub-Spam-Report: AWL=-4.074, RDNS_NONE=1.274
X-W3C-Scan-Sig: 1Uas7A-0003CC-TH 773bed82660da1e21a768b66989d4124
Subject: Associating URI-based identities with HTTP requests
Archived-At: <>
X-Mailing-List: <> archive/latest/17924
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

bcc: Web Payments mailing list

We published the HTTP Signatures spec via the IETF a few days ago:

That spec allows HTTP messages to be digitally signed. We are also
working on another spec called Web Keys, that allows people to create
identities and refer to them using URLs like:

You can also publish RSA keys to locations on the Web and refer to them
like this:

The Web Payments group wanted to pursue updating the HTTP "From:" Header
to allow both e-mail addresses and URLs, so one could do something like

POST /some/url HTTP/1.1
Authorization: Signature keyId="" ...

Effectively, this makes it so that an HTTP request is not only digitally
signed, but also bound to an identity of some sort. This is useful for
the Web Payments work because it allows us to process payments using a
single HTTP request (without introducing state into the HTTP transaction).

After speaking with Mark Nottingham, he made it clear that this approach
may be difficult to pursue in this group because 'From' is in use and
has fairly well-understood semantics at this point in time.

We're looking for feedback on the best approach for adding this sort of
feature to HTTP messages.

So, here are some other options: Using a Link header, or defining a new
HTTP Header.

Is there an RFC that explains when to define a new link relation and
when to define a new header? It seems like doing a link relation would
be better for the Web (by reducing HTTP header proliferation)?

That said, the Web Keys spec would like to introduce some form of
'identity' to be associated with a digital signature for HTTP messages.

We want to send a pretty strong signal that this can be used as a
simpler way to authorize HTTP requests in certain scenarios (instead of
falling back to OAuth, OAuth2, etc.). Placing this in a separate header
might send a better message to developers (this is a primary feature of
HTTP, use it) than doing it as a Link header (which is slightly more
difficult to parse and create for developers).

We could also shove it into an HTTP Signatures parameter, but that would
prevent applications that want to use a different authentication
mechanism from having the ability to refer to an identity using a URL.

So, I think the proposal would be to create a 'Sender' header (ignore
the name for now, it's just a placeholder so we can discuss the
semantics of the header). This header would allow any URI to be placed
into the header (so you could do everything you can today with 'From',
and then in addition, you could also use URLs). For example, these would
all be valid uses of 'Sender':

Sender: ssh://msporny;

Authentication of the sender would be up to the application. In the Web
Keys spec, we'd use the Authorization: Signature field to verify the Sender.

Thoughts? What would be the best way to proceed on this? Link header or
HTTP header? Publish an I-D, or try to tack it on to an existing spec?

-- manu

Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch