<!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 &lt;general-bounces@openid.net&gt;<BR>
To: general@openid.net &lt;general@openid.net&gt;<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&nbsp; about openid, I always seem to hear objections, mostly on aesthetic grounds, to the use of URLs as end-user visible identifiers.&nbsp; As Patrick McGoohan said, &quot;I am not a web page, I am a free man&quot;...<BR>
<BR>
In an attempt to moot this problem, I've been playing around with some simple approaches to allow identifiers of the form &quot;user@realm&quot; to be resolved to openid urls using the DNS.&nbsp;<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 &quot;<A HREF="https://openid.realm/">https://openid.realm/</A>~ user/&quot; and provider &quot;<A HREF="https://openid">https://openid</A> &lt;<A HREF="https://openid">https://openid</A>&gt; .realm/openid1/&quot;.<BR>
<BR>
This approach appears to rigid to fit the openid model well;&nbsp; identity&nbsp; 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&nbsp; discovery rites to determine the right endpoint.<BR>
<BR>
This approach makes it easier to change identity providers, but&nbsp; 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.&nbsp; These mechanisms are the underpinnings of Apple's Bonjour.&nbsp;<BR>
<BR>
Services are&nbsp; represented in DNS-SD as&nbsp; pairs of SRV and TXT records.&nbsp; The SRV&nbsp; record&nbsp; providers hostname and port information.&nbsp; 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.&nbsp;<BR>
<BR>
$ORIGIN _tcp.bonjour.unc.edu.<BR>
_openid&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PTR&nbsp;&nbsp;&nbsp;&nbsp; eritrea._openid<BR>
<BR>
$ORIGIN _openid._tcp.bonjour.unc.edu.<BR>
<BR>
eritrea&nbsp; TXT&nbsp;&nbsp;&nbsp;&nbsp; &quot;provider=<A HREF="https://eritrea.oit.unc.edu/openid1/%u">https://eritrea.oit.unc.edu/openid1/%u</A> &lt;<A HREF="https://eritrea.oit.unc.edu/openid1/%25u">https://eritrea.oit.unc.edu/openid1/%25u</A>&gt; &quot; \<BR>
&nbsp;&quot;identity= <A HREF="https://eritrea.oit.unc.ed">https://eritrea.oit.unc.ed</A> &lt;<A HREF="https://eritrea.oit.unc.ed">https://eritrea.oit.unc.ed</A>&gt; u/user/%u&quot;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SRV&nbsp;&nbsp;&nbsp;&nbsp; 0 0 443 eritrea.oit.unc.edu.<BR>
<BR>
would map ses@bonjour.unc.edu &lt;<A HREF="mailto:ses@bonjour.unc.edu">mailto:ses@bonjour.unc.edu</A>&gt;&nbsp; to provider url <A HREF="https://eritrea.oit.unc.edu/openid1/ses">https://eritrea.oit.unc.edu/openid1/ses</A> &lt;<A HREF="https://eritrea.oit.unc.edu/openid1/ses">https://eritrea.oit.unc.edu/openid1/ses</A>&gt; , 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.&nbsp; This may be appropriate, but is more restrictive than&nbsp; behavior.<BR>
<BR>
The discovered information should really be authenticated using DNSSEC; until then&nbsp; 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=&quot;_openid._tcp.bonjour.unc.edu&quot;.<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.&nbsp;<BR>
<BR>
The two approaches can be combined by making the provider url optional, and only performing http discovery when it is not present.&nbsp; 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;&nbsp; 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>