<span class="gmail_quote"></span>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><span style="font-weight: bold;">
Fixed Mapping</span><br>The simplest approach is to used a fixed mapping from realm form to the necessary URLs. For example, <br><span style="font-style: italic;">user</span>@<span style="font-style: italic;">realm</span>
could map to identity "<a href="https://openid" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://openid</a>.<span style="font-style: italic;">realm</span>/~<span style="font-style: italic;">
user</span>/" and provider "<a href="https://openid" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://openid
</a>.<span style="font-style: italic;">realm</span>/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><span style="font-weight: bold;">Fixed Mapping + HTTP Discovery<br><br></span>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><span style="font-weight: bold;">DNS-SD Discovery
</span>
<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><font size="1"><span style="font-family: courier new,monospace;">$ORIGIN _tcp.bonjour.unc.edu.</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">_openid PTR eritrea._openid
</span><br style="font-family: courier new,monospace;"></font><br><font size="1"><span style="font-family: courier new,monospace;">$ORIGIN _openid._tcp.bonjour.unc.edu.<br><br style="font-family: courier new,monospace;">
</span>
<span style="font-family: courier new,monospace;">eritrea TXT "provider=<a href="https://eritrea.oit.unc.edu/openid1/%25u" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://eritrea.oit.unc.edu/openid1/%u
</a>" \<br> "identity=<a href="https://eritrea.oit.unc.ed" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
https://eritrea.oit.unc.ed</a></span><span style="font-family: courier new,monospace;">u/user/%u"</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> SRV 0 0 443
<a href="http://eritrea.oit.unc.edu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">eritrea.oit.unc.edu</a>.</span></font><br><br>would map <a href="mailto:ses@bonjour.unc.edu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
ses@bonjour.unc.edu</a> to provider url <a href="https://eritrea.oit.unc.edu/openid1/ses" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://eritrea.oit.unc.edu/openid1/ses
</a> , and identity url <a href="https://eritrea.oit.unc.edu/user/ses" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">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><span style="font-weight: bold;">DNS Mapping + HTTP Discovery</span><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><span style="font-weight: bold;">
Implementation<br><br></span>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><span class="sg"><br>Simon<br>
</span>