openid.consumer tag

Daniel E. Renfer Duck at
Wed Sep 14 17:14:00 PDT 2005

I really wasn't thinking about the fact that every OpenId isn't/won't be 
standardized as to how they accept the form input from the login box. 
Obviously, in order for something like this to work, you would have to be 
assured that you could always initiate a login by sending the same commands 
via GET to any OpenId consumer. This should only be for those consumers that 
can respond to a GET request containing "openid_url" and do whatever it 
needs to do to authenticate you.

The browser understands it perfectly. It's a link tag. It's a link to a 
related resource located somewhere else. It points to the url responsible 
for handleing authentication request for this page. Your browser might not 
know what to do with it, but my OpenId Extension for Firefox that I 
downloaded from MozillaUpdate (not yet written) knows that when it sees that 
tag in the head of a page, it should prompt me to send my stored identity to 
that url.

A supporting agent SHOULD preserve any arguments on the original 
openid.consumer url.

----- Original Message ----- 
From: "Lukas Leander Rosenstock" <webmaster at>
To: <yadis at>
Sent: Wednesday, September 14, 2005 4:07 PM
Subject: Re: openid.consumer tag

> At first glance a great idea. However, why should someone download a 
> plugin just to enter his/her identity URL? The login process itself, as it 
> is done on a website from the server (and can be anything from silent, a 
> <form> to HTTP auth.) so as long as this is not standardized it won't save 
> to much time. Browser integration, hmm, if browsers don't even understand 
> all these nice links like "glossary", "help", "next" etc. from HTML 2.0 
> why should they do it with openid.consumer? Okay, Firefox displays an RSS 
> icon, so when OpenID has become as popular as RSS it might happen, yes. 
> Proposing such a tag as you've given here is okay, but it is not all for 
> it, one point I'm thinking about is what the user agent should send as 
> return_url, the current webpage or something else (e.g. the webpage with 
> parameters)? Just think about it again.
> Anas M. Nebuchadnezzar XXXVII wrote:
>> I've been doing some thinging, and I cam up with an idea that I wanted to 
>> share with you to see what you all think. My idea is, every site that 
>> supports openid authentication should add an extra link tag in the header 
>> pointing to it's openid consumer url. This would have the benefit of 
>> assisting in the autodiscovery of openid-enabled sites as well as makeing 
>> possible to write browser plugins/extensions that work with that 
>> information.
>> Imagine going to and seeing a little openid icon show 
>> up on the bottom of the window. If you click on the icon, you get the 
>> options: "log in with {stored identity}" or "log in with other". Choosing 
>> either option would automatically send a login request to that sites 
>> consumer url.
>> This will make things a lot easier when we start to see more sites that 
>> accept openid logins. If the user doesn't have any such plugin, then 
>> nothing happens. There's just another link tag in the header, but if they 
>> _do_ have a plugin installed then it will save them time in logging in to 
>> the site. (Livejournal doesn't have an openid login box on every page)
>> So, if you have a site that consumes openid's, then go ahead and put this 
>> tag on your site now, and if we get enough people to do it, then we may 
>> be able to start doing something with it.
>> This wouldn't really needed to be added to the spec. It doesn't really 
>> change the way anything works already, it's just an optional tag that 
>> sites can add.
>> Let me know what you think. Any ideas, or reasons why this wouldn't work?
>> Example:
>> <link rel="openid.consumer" 
>> href="" />
>> Daniel E. Renfer
>> openid:

More information about the yadis mailing list