OpenID Email Discovery

Fri Jan 4 00:25:32 UTC 2008

Phillip, what do you mean by "Until the IPR commitments necessary to allow
that change are made there is no standard". The OASIS XRI TC has operated
under a royalty-free IPR policy since the day it was formed (see the
language in the charter,
http://www.oasis-open.org/committees/xri/charter.php), and subsequently
adopted to the RF Limited IPR Policy when OASIS update its IPR rules
(document at http://www.oasis-open.org/committees/xri/ipr.php). 

So even though the final spec in the XRI 2.0 suite - XRI Resolution 2.0
Committee Draft 02 - is now in public review
(http://lists.oasis-open.org/archives/xri/200712/msg00001.html), so we
should be proceeding to an OASIS Standard vote on XRI 2.0 this spring, there
shouldn't be anything standing in the way of immediate adoption, as has been
happening in a number of open source efforts.

Or is there something about the OASIS standardization process that I'm
missing?

=Drummond 

  _____  

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/20080103/307fff5c/attachment-0002.htm>