[OpenID] Fwd: Proposal: DNS based mapping/discovery for user at REALMidentifiers

Chasen, Les les.chasen at neustar.biz
Sat Mar 31 01:08:59 UTC 2007

Or you could just use XRI where everyone is just an individual with defining metadata.

----- Original Message -----
From: general-bounces at openid.net <general-bounces at openid.net>
To: general at openid.net <general at openid.net>
Sent: Fri Mar 30 20:06:15 2007
Subject: [OpenID] Fwd: Proposal: DNS based mapping/discovery for user at REALMidentifiers


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"... 

In an attempt to moot this problem, I've been playing around with some simple approaches to allow identifiers of the form "user at realm" to be resolved to openid urls using the DNS.  

Fixed Mapping
The simplest approach is to used a fixed mapping from realm form to the necessary URLs. For example, 
user at realm could map to identity "https://openid.realm/~ user/" and provider "https://openid <https://openid> .realm/openid1/".

This approach appears to rigid to fit the openid model well;  identity  providers must be changed to follow URL conventions, and delegation becomes problematic. 

Fixed Mapping + HTTP Discovery

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. 

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.

DNS-SD Discovery 

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.  

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. 

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.  

$ORIGIN _tcp.bonjour.unc.edu.
_openid                 PTR     eritrea._openid 

$ORIGIN _openid._tcp.bonjour.unc.edu.

eritrea  TXT     "provider=https://eritrea.oit.unc.edu/openid1/%u <https://eritrea.oit.unc.edu/openid1/%25u> " \
 "identity= https://eritrea.oit.unc.ed <https://eritrea.oit.unc.ed> u/user/%u"
         SRV     0 0 443 eritrea.oit.unc.edu.

would map ses at bonjour.unc.edu <mailto:ses at bonjour.unc.edu>  to provider url https://eritrea.oit.unc.edu/openid1/ses <https://eritrea.oit.unc.edu/openid1/ses> , and identity url https://eritrea.oit.unc.edu/user/ses . 

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. 

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". 

DNS Mapping + HTTP Discovery

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.  

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. 


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. 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20070330/9544ce86/attachment-0002.htm>

More information about the general mailing list