Draft OpenID v.Next Discovery working group charter

Phillip Hallam-Baker hallam at gmail.com
Fri Apr 16 04:18:05 UTC 2010


On Thu, Apr 15, 2010 at 9:50 PM, Paul E. Jones <paulej at packetizer.com> wrote:
> Phillip,

>> Whatever switching layer we need has to be able to support that use
>> case. It may be that even if we can in fact meet all the use case
>> requirements with SRV alone it is tactically advantageous to use
>> webfinger at least in the transitional phase.
>
> I really liked the idea of SRV records, having a "corporate" kind of view to
> the problem.  But, using SRV making it rather challenging.  Every user in a
> given domain might have a different IDP.  Webfinger makes that very clean

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.

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.

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.

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.


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.


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.

If you want to allow for multi-protocol switching at the domain level
then you could have a record in the DNS that says something like
'openid identifiers may be resolved through SAML, webfinger, kerberos,
yaddayadda'. The one thing to watch here is that the choice of
protocol cannot change the high level protocol semantics. If the
relying party is taking an arbitrary choice amongst the protocols then
alice at example.com can't map to different semantics in unpredictable
ways.


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.

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.

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.


> Indeed.  That's why I think it's important to retain the separate OpenID ID
> that is used today.  Allow the email ID to be a means of deriving the
> latter.

Yep,


>> The solution to the comcast.com issue in my view has to be a solution
>> for all of Alice's internet activities. It has to work for email and
>> her blog and her jabber chat. Since they use DNS as the name scheme,
>> her only real solution to the comcast issue in that case is to buy her
>> own DNS name. That solution must be a sufficient solution for OpenID
>> as well - if it is going to deserve the term 'open'.
>
> Yeah, this is a challenge.  A DNS solution will not help, though.  Once one
> has a Jabber ID, that can't be so easily changed.  Once one has an email ID,
> that can be so easily changed, either.  This is one reason why I own my own
> domain -- so I can run all of these services myself.  That's just
> unreasonable for most.

If i invest in any name, that is going to create a lock in.

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.

> If you're suggesting that Go Daddy ought to push OpenID and other value-add
> services and sell users domain names that are equipped with those services,
> yeah... fully agree.  It's not too much to ask to pay $10/yr to get those
> kinds of services.  For whatever reason, domain sellers have only focused on
> email, web hosting, SSL, and a few more geeky things.
>
> 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.


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

-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/


More information about the specs mailing list