OpenID Email Discovery

Hallam-Baker, Phillip pbaker at verisign.com
Thu Jan 3 23:03:04 UTC 2008


NAPTR is an ietf proposed standard but there is no deployed base. SRV has been supported in windows since 2000 and bind since before then.

XRI is a specification, not an OASIS recommendation. Until the IPR commitments necessary to allow that change are made there is no standard.


Sent from my GoodLink Wireless Handheld (www.good.com)

 -----Original Message-----
From: 	Peter Davis [mailto:peter.davis at neustar.biz]
Sent:	Thursday, January 03, 2008 02:07 PM Pacific Standard Time
To:	Hallam-Baker, Phillip
Cc:	Eran Hammer-Lahav; OpenID specs list
Subject:	Re: OpenID Email Discovery

actually, NAPTR RR's would be a better fit, as the unique-part of an  
openID may be in the local-path part of a URI, not the hostname... of  
course, if a users openID changes, so too might their underlying DNS  
name, and then DNS won't help you at all there.  XRI is better  
situated to solve that use case.

=peterd

On Jan 3, 2008, at 4:48 PM, Hallam-Baker, Phillip wrote:

> This is the function of the existing DNS SRV record.
>
> _openid.example.com  SRV 1 1 1 1 openid1.example.com
>
> The Internet has an architecture already. Use it, don't try to  
> reinvent it.
>
> From: specs-bounces at openid.net on behalf of Eran Hammer-Lahav
> Sent: Thu 03/01/2008 4:01 PM
> To: 'OpenID specs list'
> Subject: OpenID Email Discovery
>
> (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 'joe at example.com' 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, 'joe at example.com' has his OpenID managed by  
> 'example.org'. When signing up for an OpenID at 'example.org', Joe  
> asked it to accept identity requests for 'joe at example.com' or at  
> least provide delegation discovery. When Joe tries to log into an  
> OpenID-enabled site using 'joe at example.com', 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 at openid.net
> http://openid.net/mailman/listinfo/specs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20080103/f81c7fbd/attachment-0002.htm>


More information about the specs mailing list