Re: Associating URI-based identities with HTTP requests

Re: when to use a link header, the rule I follow is fairly basic : if the
value consists of a uri that is optionally typed and potentially requires
additional metadata,  and if you think the link relation will be generally
useful in other scenarios (e.g.  Atom links,  json documents, html tags),
then use a link relation. If,  on the other hand it is something that only
requires a uri with no additional metadata, and you don't care about
non-http use cases, use a new header.

Based on an initial review of your note, a new header is likely
appropriate.
 On May 10, 2013 11:33 AM, "Manu Sporny" <msporny@digitalbazaar.com> wrote:

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