Associating URI-based identities with HTTP requests

bcc: Web Payments mailing list

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

http://lists.w3.org/Archives/Public/public-webpayments/2013May/0008.html

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:

https://dev.payswarm.com/i/manu

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

https://dev.payswarm.com/i/manu/keys/4

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

POST /some/url HTTP/1.1
Host: example.com
From: https://dev.payswarm.com/i/manu
Authorization: Signature keyId="https://dev.payswarm.com/i/manu/keys/4" ...

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: mailto:msporny@digitalbazaar.com
Sender: https://dev.payswarm.com/i/manu
Sender: sip:msporny@digitalbazaar.com
Sender: ssh://msporny;fingerprint=f3:8f:2f:..@example.com:1234

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
http://blog.meritora.com/launch/

Received on Friday, 10 May 2013 18:32:45 UTC