[OpenID] Fwd: Proposal: DNS based mapping/discovery for user at REALMidentifiers
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.
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 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.
_openid PTR eritrea._openid
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...
More information about the general