openid.trust_root wildcards

Brad Fitzpatrick brad at
Wed May 18 10:53:06 PDT 2005

It's up to the identity server to do the right thing here.  It doesn't
affect the protocol.

I'm sure we'll build a recommended list of domain suffixes which SHOULDN'T
be wildcarded.

- Brad

On Wed, 18 May 2005, Martin Atkins wrote:

> The OpenID site says (on the spec page):
>      openid.trust_root (Optional, but recommended) -- The URL which the
>      user will actually see to approve. The return_to URL must descend
>      from the trust_root, or the identity server will return an error,
>      not a redirect. Namely, the URL scheme and port must match. The
>      path, if present, but be equal or below the trust_root, and the
>      domains on both must match, or, the trust_root contain a wildcard
>      like "*" (but the wildcard may only be at the
>      beginning) You can try to pass things like http://*.com/ or
>      http://*, but any respectable identity server will protect
>      their users from that. Defaults to return_to URL if absent.
> It's the clause at the end about *.com that concerns me. While I guess
> that this field is purely for display -- the user will see that it's a
> stupid wildcard -- without some concrete restrictions on what should be
> allowed and what should not it's inevitable that some ID servers will
> screw up and allow (or prevent) odd cases.
> For example, * is mentioned. As a (rather geeky) human in the UK,
> I know that this is the country-wide domain for companies. However,
> other countries do not have fixed second-level domains and will instead
> let anyone register domains inside their country domain directly. There
> is the possibility that someone could register (for the sake of example)
>, and that would be a legitimate domain. Even if we exclude
> two-letter domains, there is and the similar
> How is this dealt with for HTTP cookies? Can I set a cookie for
> If not, what rule says that I can't?
> Regardless of what the rules are, the spec should mention (or at least
> refer to) some more specific rules and require them for compliance.
> _______________________________________________
> yadis mailing list
> yadis at

More information about the yadis mailing list