[OpenID] Wildcard realms and return URL verification discovery conflict

Deron Meranda deron.meranda at gmail.com
Tue Apr 7 07:55:58 UTC 2009

While trying to create an RP that works with both Google and Yahoo! OPs, I
have found a particular troublesome case where I can't easily please both
at the same time.

My situation is that I want to be able to run several RPs across different
subdomain websites yet still be able to correlate users among them.  Say
I run at least two sites:


Now, since Google's openid identities are hashed from the realm, I
have to use a wildcard realm, e.g., https://*.example.org/ if I want to
get the same user identity regardless of which of the two sites the
user logs into.  There is no other option with Google.

But now consider Yahoo!, which performs the optional Return URL
Verification step.  Per section 9.2.1 of the OpenID 2.0 spec, it will then
attempt to perform discovery (for my RP's XRDS document) starting at

Now my problem is that I don't have control over the "www" server.  Or
more specifically, the "marketing" department runs that server (as I
suspect is the case in most large companies), so there is no chance of
getting anything technical implemented on it; such as an XRDS
document or links (http or meta) to one.  In fact the www server is
the only one in the domain that doesn't even run https.  So the choice of
"www" to replace the "*" wildcard during discovery is, for me, just about
the worst possible default.

So one OP is forcing me to use wildcard realms, and another OP is
pushing me in the other direction.  Am I now going to have to set my
realm conditionally based on the OP endpoint?   And what if eventually
there was a new OP which behaved like both Google and Yahoo!?  Could
you not have a multiple-site OpenID RP set, without having to control the
one magically-designated "www" subdomain?

I was thinking that perhaps OpenID could have specified that the root
URL of the return_to URL would be used for discovery, if it *matches*
the realm.  For example if an authentication request was sent to an
OP which contained:
   openid.realm = https://*.example.org/
   openid.return_to = https://site1.example.org/openid/return/
then the OP would attempt discovery of the XRDS document at
rather than

Of course this would only be valid if the return_to *matches* the wildcard

Deron Meranda

More information about the general mailing list