Draft OpenID v.Next Discovery working group charter
Paul E. Jones
paulej at packetizer.com
Fri Apr 16 01:50:37 UTC 2010
> I have no intention of setting up my own IdP for that purpose either.
> If the scheme is going to work acceptably then it has to be possible
> for people like me who have a domain but don't want to run an IDP of
> their own can make use of other IDPs easily.
You would not have to. You could have lines like this returned when the RP
queries one of your email (er, acct:) URIs:
The RP would find that OpenID URI and use it. And the RP would display it
to you and you'd be directed to the login page of said domain. Your browser
might even already be logged in (using cookies) and not required to re-enter
> 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.
> The problem I see with any scheme that does not involve DNS switching
> is that we then lack an ongoing proof of ownership of the name.
Which name? The email address or the OpenID ID? Artifact binding might
help with the email address, but the RP will get proof of the OpenID ID
ownership when the user authenticates. DNS is not required to make that
happen. (I'll ignore the case where DNS might be compromised. That can
happen and user identities can be hijacked regardless of what scheme is
> So for example, if alice is silly enough to use alice at comcast.com and
> then Comcast tells her that they are selling her local cable co to
> someone else and changing all the account names, alice has just lost
> all the equity she has built up in that name. This is a problem in
> this instance, as I found out myself as my cable co has changed its
> name three times in the seven years I have used them.
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
> But when I left VeriSign the company expressly wants all the rights I
> may have acquired for pbaker at verisign.com out there in the net to
> expire when they decide.
> 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.
> That is why one of the routes I see for evangelizing OpenID is to go
> to the big DNS registrars with a value proposition: If they support
> OpenID it will increase the value of the names they sell. I can go to
> Bob Parsons with a really good argument that he can see a fast return
> on investing in OpenID.
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?
> 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?
More information about the specs