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

[Simon Spero]

All,

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 .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.edu/user/%u"
         SRV     0 0 443 eritrea.oit.unc.edu.

would map ses at bonjour.unc.edu to provider url
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.


Implementation

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.

Comments?

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