Subject: [http-auth] Associating URI-based identities with HTTP requests

From: Manu Sporny <[email-masked]>
Date: Fri, 10 May 2013 14:31:38 -0400

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:[email-masked]
Sender: https://dev.payswarm.com/i/manu
Sender: sip:[email-masked]
Sender: ssh://msporny;fingerprint=f3:8f:2f:[email-masked]: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/

---

From: Michael Thomas <[email-masked]>
Date: Fri, 10 May 2013 12:23:11 -0700

> single HTTP request (without introducing state into the HTTP transaction).

here's a question I have: is the identifier used a "handle" or is it
actually an operative identifier for another purpose? That is, does
the identifier just need to be unique, or does it need to also be used
for its "intended" purpose? I'm sorry if this is unclear. Let me give an
example:

[email-masked] is an email address, it has the property that it is globally
unique as well as the property that if you put use it as an email address
for an rfc x82[1|2] message, it will deliver email to me.

102398019380984051850923405120948102801831234092843812304
on the other hand, it a (statistically) unique identity. It doesn't have any
other meaning beyond its (assumedly) uniqueness factor.

If the identifier is more like the latter than the former, there is a handy
way to do that, which is to use raw public keys. They have the property
that they are a) statistically unique and b) provable by the sender that
they possess the private key.

The way I like to think of "accounts" with this is to think not in terms
of a signature asserting ownership of some account identifier (email address,
local handle, etc, etc), but rather that a set of one or more public keys is
bound to a given account regardless of what the human factors name is
(eg, username). That is, the identity that is asserted is the public key, nothing
more, nothing less. It's up to the account server's logic to bind the relationships
together (eg, in its users table), not the client side.

Mike

---

From: James M Snell <[email-masked]>
Date: Fri, 10 May 2013 16:42:50 -0700

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.

---

From: Manu Sporny <[email-masked]>
Date: Sun, 12 May 2013 14:37:25 -0400

On 05/10/2013 03:23 PM, Michael Thomas wrote:
> [email-masked] is an email address, it has the property that it is
> globally unique as well as the property that if you put use it as an
> email address for an rfc x82[1|2] message, it will deliver email to
> me.

This is closer to the purpose than the 'identifier' just being unique.

> 102398019380984051850923405120948102801831234092843812304 on the
> other hand, it a (statistically) unique identity. It doesn't have 
> any other meaning beyond its (assumedly) uniqueness factor.

The types of identifiers that we want to use could be used w/ another
RFC/REC. For example, the Web Payments work at the W3C will use the
identifier:

To assert the ownership of multiple keys. For example, do this:

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

You will see a set of 'publicKey's associated with identity. So, as long
as a message can be verified using any one of those public keys, you can
assert that the owner of the public key is that identity.

> The way I like to think of "accounts" with this is to think not in
> terms of a signature asserting ownership of some account identifier
> (email address, local handle, etc, etc), but rather that a set of one
> or more public keys is bound to a given account regardless of what
> the human factors name is (eg, username). That is, the identity that
> is asserted is the public key, nothing more, nothing less. It's up to
> the account server's logic to bind the relationships together (eg, in
> its users table), not the client side.

You can also go from the key to the owner of the key, for example, do this:

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

You can see that the key has an owner, who is:

However, using purely the key ID assumes that the key ID can always be
discovered in all HTTP Requests. This is not always the case. For
example, if the requestor has already authenticated via a cookie, but
has multiple identities associated w/ the cookie, then it would be
impossible to determine which identity they want to use when requesting
a certain operation on the server.

In short, we don't want to tightly couple the identity scheme with the
authentication or authorization scheme.

-- manu

---

From: Manu Sporny <[email-masked]>
Date: Sun, 12 May 2013 19:07:05 -0400

On 05/10/2013 07:42 PM, James M Snell wrote:
> 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.

The link could be typed, or it could just be a plain 'ol URI. If the
link is typed, it could have multiple different types (since we're
dealing with Linked Data). The purpose of the link is to express an
identity, but the same link can be used for describing ownership, access
control, etc.

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

Yeah, I think we're in this scenario.

> Based on an initial review of your note, a new header is likely 

Thanks - your basic rule was very helpful... would be good if we could
put it in an RFC somewhere. :)

-- manu