- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sun, 12 May 2013 14:37:25 -0400
- To: Michael Thomas <mike@mtcc.com>
- CC: HTTP WG <ietf-http-wg@w3.org>, HTTP Auth WG <http-auth@ietf.org>
On 05/10/2013 03:23 PM, Michael Thomas wrote: > mike@mtcc.com 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/
Received on Sunday, 12 May 2013 18:37:55 UTC