(The full story is posted at http://www.hueniverse.com/hueniverse/2008/01/addressing-open.html but this contains the technical parts of the post).
This proposal adds Email Discovery allowing users to use their email address as an OpenID. ... We need to map between the email to the OpenID identifier and this is where DNS comes in. DNS already has a system for resolving email addresses into an actual server - email resolution using an MX record. Why not add a new record type for OpenID. Basically another way to perform OpenID discovery that is all about making it user-friendly. All that is needed is a URL the site performing discovery can append the email to and treat it as an OpenID identifier. This can be done using a OpenID TXT record: 'OpenID [username rule] [priority] [URL]' where [username rule] is a wildcard expression used to match the username part of the email (everything up to the '@'), [priority] is the MX-like priority value, and [URL] is the URL used to generate the OpenID identifier. The URL uses '*' to indicate where the username is inserted, and '**' to indicate where the full, URL-encoded, email address is inserted (both optional). For example: example.com TXT 'OpenID * 10 http://*.example.com/' example.com TXT 'OpenID joe 10 http://example.org/openid?**' Which reads: for any email address '@example.com' other than 'joe' use 'http://username.example.com/' as the OpenID identifier. For email address '[EMAIL PROTECTED]' use 'http://example.org/openid?joe%40example.com' as the OpenID identifier. Rules are processed first based on the username rule match (in order of match closeness) and then on priority which is used in the same manner as MX records priority. ... There are many ways to implement identity delegation, but in the context of email identifiers and simplifying the user experience, the idea is to move the delegation mapping to the OpenID provider. When users sign-up for a new OpenID, they will be given the option, perhaps as a premium paid service, to make the OpenID provider map incoming identity checks for the user email address with their local OpenID identifier. So instead of the users telling the site about their local identity (using delegation), the OpenID provider will perform the mapping. In the above example, '[EMAIL PROTECTED]' has his OpenID managed by 'example.org'. When signing up for an OpenID at 'example.org', Joe asked it to accept identity requests for '[EMAIL PROTECTED]' or at least provide delegation discovery. When Joe tries to log into an OpenID-enabled site using '[EMAIL PROTECTED]', the site convert the email address to the URL 'http://example.org/openid?joe%40example.com' and use it like a regular OpenID identifier. 'example.org' will reply with the needed discovery information to get Joe authenticated using the OpenID protocol. By using the '**' symbol, the full email address is sent over to the OpenID provider which can perform mapping of identities other than its own local ones. This can be viewed as hosted delegated identity where the OpenID provider also provides hosting of the OpenID delegation information for the user. It doesn't require any new standards except for implementation and support by OpenID providers. --- Would love to get some feedback. Thanks, EHL
_______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
