<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7651.59">
<TITLE>Re: [OpenID] Fwd: Proposal: DNS based mapping/discovery for user@REALMidentifiers</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Or you could just use XRI where everyone is just an individual with defining metadata.<BR>
--------------------------<BR>
<A HREF="http://xri.net/=les.chasen">http://xri.net/=les.chasen</A><BR>
<BR>
<BR>
----- Original Message -----<BR>
From: general-bounces@openid.net <general-bounces@openid.net><BR>
To: general@openid.net <general@openid.net><BR>
Sent: Fri Mar 30 20:06:15 2007<BR>
Subject: [OpenID] Fwd: Proposal: DNS based mapping/discovery for user@REALMidentifiers<BR>
<BR>
All,<BR>
<BR>
Whenever I talk to people on campus about openid, I always seem to hear objections, mostly on aesthetic grounds, to the use of URLs as end-user visible identifiers. As Patrick McGoohan said, "I am not a web page, I am a free man"...<BR>
<BR>
In an attempt to moot this problem, I've been playing around with some simple approaches to allow identifiers of the form "user@realm" to be resolved to openid urls using the DNS. <BR>
<BR>
Fixed Mapping<BR>
The simplest approach is to used a fixed mapping from realm form to the necessary URLs. For example,<BR>
user@realm could map to identity "<A HREF="https://openid.realm/">https://openid.realm/</A>~ user/" and provider "<A HREF="https://openid">https://openid</A> <<A HREF="https://openid">https://openid</A>> .realm/openid1/".<BR>
<BR>
This approach appears to rigid to fit the openid model well; identity providers must be changed to follow URL conventions, and delegation becomes problematic.<BR>
<BR>
Fixed Mapping + HTTP Discovery<BR>
<BR>
A variant on the previous approach is to use a fixed mapping to generate the identity URL, then perform the existing discovery rites to determine the right endpoint.<BR>
<BR>
This approach makes it easier to change identity providers, but still requires identity URLs to be in a fixed form, and requires a second discovery step.<BR>
<BR>
DNS-SD Discovery<BR>
<BR>
DNS Service Discovery (DNS-SD) defines a set of mechanisms for locating services using the DNS. These mechanisms are the underpinnings of Apple's Bonjour. <BR>
<BR>
Services are represented in DNS-SD as pairs of SRV and TXT records. The SRV record providers hostname and port information. The TXT record carries any other service parameters in a key=value format.<BR>
<BR>
One approach to using DNS-SD for OpenID discovery is to define service parameters to carry identifier and provider format strings - for example, %u might stand for the user name, and %r might stand for the realm. <BR>
<BR>
$ORIGIN _tcp.bonjour.unc.edu.<BR>
_openid PTR eritrea._openid<BR>
<BR>
$ORIGIN _openid._tcp.bonjour.unc.edu.<BR>
<BR>
eritrea TXT "provider=<A HREF="https://eritrea.oit.unc.edu/openid1/%u">https://eritrea.oit.unc.edu/openid1/%u</A> <<A HREF="https://eritrea.oit.unc.edu/openid1/%25u">https://eritrea.oit.unc.edu/openid1/%25u</A>> " \<BR>
"identity= <A HREF="https://eritrea.oit.unc.ed">https://eritrea.oit.unc.ed</A> <<A HREF="https://eritrea.oit.unc.ed">https://eritrea.oit.unc.ed</A>> u/user/%u"<BR>
SRV 0 0 443 eritrea.oit.unc.edu.<BR>
<BR>
would map ses@bonjour.unc.edu <<A HREF="mailto:ses@bonjour.unc.edu">mailto:ses@bonjour.unc.edu</A>> to provider url <A HREF="https://eritrea.oit.unc.edu/openid1/ses">https://eritrea.oit.unc.edu/openid1/ses</A> <<A HREF="https://eritrea.oit.unc.edu/openid1/ses">https://eritrea.oit.unc.edu/openid1/ses</A>> , and identity url <A HREF="https://eritrea.oit.unc.edu/user/ses">https://eritrea.oit.unc.edu/user/ses</A> .<BR>
<BR>
This approach allows much more flexibility in urls, but is best suited to cases where every user in a realm is authenticated by the same provider. This may be appropriate, but is more restrictive than behavior.<BR>
<BR>
The discovered information should really be authenticated using DNSSEC; until then it can also be authenticated through SSL by requiring that the full service name be present as a CN in the certificate used for http communication; for example, CN="_openid._tcp.bonjour.unc.edu".<BR>
<BR>
DNS Mapping + HTTP Discovery<BR>
<BR>
The previous approach can also be modified to only use DNS-SD to map to the identity URL, with the remaining information being discovered through the existing mechanisms. <BR>
<BR>
The two approaches can be combined by making the provider url optional, and only performing http discovery when it is not present. This approach may be the best option.<BR>
<BR>
<BR>
Implementation<BR>
<BR>
Adding support for DNS discovery to existing consumers is pretty simple; the consumer can either use an existing DNS-SD library, or just make a couple of DNS requests; one to discover the service instances, and a second to fetch the SRV and TXT records.<BR>
<BR>
Comments?<BR>
<BR>
Simon<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>