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

[Manu Sporny <[e-mail]>]

On 05/10/2013 03:23 PM, Michael Thomas wrote:
> [e-mail] 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:

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

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:

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

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

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