Eric Norman ejnorman at doit.wisc.edu
Mon Feb 12 22:35:51 UTC 2007

This seems to be a good place to reintroduce something that
I discovered last week.  It does seem like a problem that
the OpenID community needs to address, although how it's
addressed remains to be seen.  I did put something in the
user-experience wiki page about it.

On Feb 12, 2007, at 1:50 PM, Martin Atkins wrote:

> A domain name is just a string with some dots in it. It works 
> everywhere
> that domain names are accepted. A HTTP URL is just a string prefixed
> with http:// and a domain name. It works everywhere that HTTP URLs are
> accepted.

But prefixing the string with https:// (whether implicitly by a redirect
or explicitly by user typing) doesn't work!  Here's how to see this.

Get an OpenID identifier from protectnetwork.org.  It will be of the
form http://user.protectnetwork.org

Try logging into the wiki right here for this community.

Type in your OpenID identifier as https://user.protectnetwork.org.

It won't work; you won't be logged in.

I suspect that the reason that it doesn't work is that the SSL 
for the protectnetwork OP says that its name is idp.protectnetwork.org.
That doesn't match user.prot... so that verification fails during the 

Someone did suggest that the consequences should be that OPs should
have wild card certificates if they provide OpenID identifiers of the
above form.  I question this recommendation.

Does the OpenID RP code operate correctly if a wild card certificate
is returned?

Isn't this to much of a burden to ask of OPs?

Wouldn't it be better for security if this connection used SSL/TLS?

Eric Norman

More information about the general mailing list