OpenID Email Discovery

Fri Jan 4 18:34:07 UTC 2008

I'm sorry, Phillip, we're not going to let you get away with that one. 

Drummond already asked you about what you are talking about w/r/t IPR
commitments, and I haven't seen a reply. All IPR commitments for XRI are in
place and have been for quite a while. I encourage you to review the "RF on
Limited Terms" option (under which the TC operates) of
http://www.oasis-open.org/who/intellectualproperty.php 

I appreciate your technical discussion, but please don't drop the IPR FUD
bomb without substantiation or explanation. Thanks.

    -Gabe

  _____  

From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On Behalf
Of Hallam-Baker, Phillip
Sent: Thursday, January 03, 2008 3:03 PM
To: Peter Davis
Cc: OpenID specs list
Subject: Re: OpenID Email Discovery

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%
<http://example.org/openid?joe%25> 
> 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%
<http://example.org/openid?joe%25> 
> 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/20080104/0da0c620/attachment-0002.htm>