Associating URI-based identities with HTTP requests
Manu Sporny <msporny@digitalbazaar.com> Fri, 10 May 2013 18:33 UTC
Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9FB221F8F2C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 10 May 2013 11:33:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.547
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mWiFSszH+qQ for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 10 May 2013 11:33:08 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4AE21F8AA8 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 10 May 2013 11:33:08 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Uas7j-0006mY-0a for ietf-http-wg-dist@listhub.w3.org; Fri, 10 May 2013 18:32:55 +0000
Resent-Date: Fri, 10 May 2013 18:32:55 +0000
Resent-Message-Id: <E1Uas7j-0006mY-0a@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <msporny@digitalbazaar.com>) id 1Uas7X-0006kf-RO; Fri, 10 May 2013 18:32:43 +0000
Received: from [216.252.204.51] (helo=mail.digitalbazaar.com) by lisa.w3.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <msporny@digitalbazaar.com>) id 1Uas7A-0003CC-TH; Fri, 10 May 2013 18:32:43 +0000
Received: from zoe.digitalbazaar.com ([192.168.0.99] ident=msporny) by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from <msporny@digitalbazaar.com>) id 1Uas6U-0002uw-Uj; Fri, 10 May 2013 14:31:39 -0400
Message-ID: <518D3D0A.1010207@digitalbazaar.com>
Date: Fri, 10 May 2013 14:31:38 -0400
From: Manu Sporny <msporny@digitalbazaar.com>
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 <ietf-http-wg@w3.org>
CC: HTTP Auth WG <http-auth@ietf.org>
References: <518C07DD.2090307@digitalbazaar.com> <403D922E-86CF-4355-BBD2-A05F409C25F7@mnot.net>
In-Reply-To: <403D922E-86CF-4355-BBD2-A05F409C25F7@mnot.net>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Received-SPF: none client-ip=216.252.204.51; envelope-from=msporny@digitalbazaar.com; helo=mail.digitalbazaar.com
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: lisa.w3.org 1Uas7A-0003CC-TH 773bed82660da1e21a768b66989d4124
X-Original-To: ietf-http-wg@w3.org
Subject: Associating URI-based identities with HTTP requests
Archived-At: <http://www.w3.org/mid/518D3D0A.1010207@digitalbazaar.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17924
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
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/
- Associating URI-based identities with HTTP reques… Manu Sporny
- Re: Associating URI-based identities with HTTP re… James M Snell
- Re: [http-auth] Associating URI-based identities … Manu Sporny
- Re: Associating URI-based identities with HTTP re… Manu Sporny