Draft OpenID v.Next Discovery working group charter

[Paul E. Jones]

Phillip,

I feel like we're trying to solve the problem before the group is chartered,
but I'm nonetheless interested to have this dialog.  If others' prefer not
to see it, perhaps we should take it offline.

> That would not be the right way to use DNS. There is actually a DNS
> record that is meant to be used for that called NAPTR. I do not
> recommend it be used.

Curious: any reason why?  NAPTR records could be used to transform an email
identifier into an OpenID URI quite easily.
 
> DNS is a service for locating services by domain name. It should not
> be conflated with user account data. That crosses the organizational
> boundaries in a bad way. I can see now why folk would see SRV as a bad
> idea. We had an extended debate on this point in the DKIM working
> group.

I guess the above is your reason "why not".  You don't want to use DNS to
get a regular expression that can convert the given ID into another URL?
DNS is not holding the account names: it just holds strings to enable
mapping.
 
> If you have a name alice at example.com and bob at example.com, both need to
> be resolved through the same OpenID service but not necessarily the
> same server.

I don't understand your statement above.  Can you clarify?

> So in my view, if we are only dealing with discovery for one
> resolution protocol the sequence would be as follows
> 
> 1a) attempt to resolve an SRV record for _openid.example.com
> 
> This step gives us the solid robustness and reliability that you can
> achieve through multiple servers for the same service. It also means
> that the maintainer of example.com DNS records can direct all OpenID
> traffic to an offsite IdP service without any impact on the Web server
> for example.com.
> 
> It bypasses the problem of 'well known' URI space entirely because we
> are connecting to a HTTP service that is specific to our protocol.

Let's look at the complete SRV record:

_openid._tcp            IN      SRV     0 0 8080 openid.example.com.

We have a machine name, but what is the URL to the endpoint for logging in?
What is the user's OpenID URI?

> 1b) If no host is resolved, attempt to find an A record or AAAA record
> for example.com
> 
> If all else fails fall back to standard IP address translation. Just
> like most mail servers do.
> 
> This is going to give the administrators a headache if they try to do
> this at scale, but it is possible to make it serviceable.

This leaves me with the same questions.
 
> 2) Present 'alice at example.com' (or bob at example.com) to the indicated
> service for resolution
> 
> This could be the webfinger protocol, could be another protocol. It is
> almost certain to be layered on HTTP, either in a REST-y or SOAP-y
> sort of way. And could well be a referral to another resolution
> service and/or protocol.

I understand how to do this with Webfinger, but I'm missing how you're
proposing this to work using SRV records.  I am still missing the OP
endpoint and the user's identitifer.

> Without the use of SRV your IdP infrastructure is going to be joined
> at the hip to your Web server infrastructure. And that is bad for all
> concerned. Most enterprises would consider IdP to be a critical
> resource. If it is down the user is not going to be able to access any
> facility. If the access to the IdP depends on the Web site being up
> then there are going to be big issues when the Web server is taken
> offline for maintenance. Many large companies take their entire Web
> presence offline from time to time for maintenance. It was bad enough
> when twitter did that, loosing my enterprise identity could be mission
> critical.

You have a point here, but the enterprise could also have a web server
running that older provides the webfinger service to ensure that the
identification service keeps running.  One would not take down all DNS
services when doing maintenance, either.  While your point is entirely valid
based on practice today, I think it's a matter of practice, not something an
organization could not address.  I could easily see, for example, this
perhaps leading to yet another reason for running the web services on
www.example.com and not on example.com, leaving example.com there only to
provide such services as allowed by host-meta.
 
> If SRV had existed in 1993 we would have used it as the basis of HTTP.
> At some point we will almost certainly move to using it for HTTP.
> Using it to discover Web services is definitely a good idea. It
> simplifies maintenance and allows for fault tolerant services.

But how is that better than an A record and having multiple A records?
(Perhaps because there is a priority value associated with records, but I'm
skeptical that they would make a lot of difference here.)
 
> It gets a little more complex if there were going to be multiple
> resolution protocols at the IdP level. Here the question is whether
> you want to do the demultiplexing at the domain level or the account
> level or both.

Yeah, it does.  And, as others pointed out, use of DNS makes it a bit more
challenging for some scripting languages.  What concerns me more than which
option we select, though, is introducing multiple options and/or more steps
to the process.  Each step introduces just a little more complexity and I
fear that might lead to a lower adoption rate by RPs. OpenID is fairly
simple today, but still requires a fair bit of logic.

> The DNS has survived for a complex set of reasons. One of the main
> ones is that ICANN is not actually in charge. If you have a name in
> .uk it is not under ICANN control in any shape or form. Same for many
> of the other CC TLDS. ICANN likes to pretend it can boss the others
> around, but this is an illusion.

DNS survived because it's a critical piece required to map names to numbers.
I do not see how ICANN had anything to do with it.  Nor do I understand what
this has to do with the rest of the discussion.  Nonetheless, I fully agree
with you: ICANN's authority is actually quite weak.  But, they have the
power to tax!  They've proven that, as I pay annual ICANN taxes on every
domain! :-)
 
> > If users really do care about preserving their identity on the
> Internet, I
> > can definitely see a user-friendly service being quite popular.  But,
> do
> > people really care about preserving their identities?
> 
> They can be made to care. There are important strategic reasons why it
> is in Microsoft's and GoDaddy's and quite probably even Google's
> interest to make it so.

I can definitely see the driver for the registrars.  Not so sure about MS or
Google, as both would like to lock users into their domains, no?
 
> >> Where the value add may come in for OpenID over what an IETF group
> >> would have delivered is precisely considering this type of issue and
> >> offering the type of useful but unenforceable guidance to deployers
> >> that help them build a system that works well together rather than
> one
> >> that works badly.
> >
> > I'm not quite sure I follow you on this. Perhaps there is some
> history I
> > don't know here, but what does the IETF offer in terms of identity?
>  OAuth
> > is in progress, but otherwise... there are a few different protocols,
> none
> > of which share a common identity value.  Is that your point?
> 
> IETF does not do the user interface or the user experience. Since the
> Web developers exited in the '96 schism that turned W3C into the
> standards org it was promised not to be, IETF has been very low in the
> stack. Most people there are hardcore line mode types who avoid GUIs
> and don't see the point.

Well, I'll not start a war here, but I suspect some in the IETF would
disagree.  I assure you that there are many in the IETF who would say that
the IETF has experience in application development, whereas other SDOs do
not.  They have security expertise whereas others do not.  I've heard that a
lot.  It's humorous to hear, because the IETF is comprised of "whoever shows
up at the door or mailing list."  And, often many of those same folks show
up elsewhere, too. :-)  So, the superiority of one SDO over another is
usually highly exaggerated.

I just like to get stuff done.

Paul