Seamless site-to-site account creation and login via OpenID

Drummond Reed drummond.reed at
Mon Aug 28 17:55:21 UTC 2006

+1 to Mike's flow here. I believe this eliminates the security issues that
I'm worried would surface with proxied IdPs. 

The remaining issue is privacy. Site A reveals the identifier the user used
with Site A to Site B. With OpenID 2.0, the user can have site-specific
identifiers ("directed identity"). The whole idea of directed identity is
that you don't have to reveal the same identifier to different sites, and
yet you still get single sign-on and profile exchange.

The only solution I can see that would retain that benefit is for Site A to
redirect not to Site B, but to a redirect service at the user's IdP, who
then redirects to SiteB AFTER determining if the user wants a site-specific
identifier for Site B.

This way Site A and Site B never have to share identifiers for the user; all
they know is that the user uses a particular IdP.


-----Original Message-----
From: yadis-bounces at [mailto:yadis-bounces at]
On Behalf Of Michael Mell
Sent: Sunday, August 27, 2006 7:52 AM
To: Tony
Cc: Yadis list
Subject: Re: Seamless site-to-site account creation and login via OpenID

Hi Tony,
The scenario you describe does make a lot of sense. It's occurred to me 
too. But I worry that creating Proxy IdP's will degrade the security 
and reliability of the authentication. The IdP is a complex application 
with strict compliance requirements. Adding a new process in the IdP or 
rolling your own ancillary process could introduce new security holes 
(and require a lot of work!).

Here's an example of a much easier flow that achieves your goal today: 
User logs in to Site A. Site A presents a link to Site B with User's 
identifier in the url arguments. The Site B Landing page recognizes 
that an identifier has been passed which indicates the user should be 
logged in as that identifier. Site B redirects User to Site B login 
which redirects to User's IdP. User has a session at the IdP so no 
password is requied. User is routed back to Site B with authentication 
tokens. Site B confirms authentication and routes User to Site B 
Landing page.

I don't see much to gain from Proxy IdP'ing. If you really want Site A 
to be the authentication authority then Site A *is* the IdP and should 
run the strongest IdP processes available.

hope that helps,

On Aug 24, 2006, at 12:36 PM, Tony wrote:

> Yes, that's correct.  The idea is to have a partner network of a 
> number of sites that all trust each other, and allow any user of any 
> site in the partner network to move around the network utilizing 
> various services which are tied to an account on that site.
> - Tony
> On 8/24/06, Drummond Reed < drummond.reed at> wrote:Tony,
>> So if I understand this (fascinating) scenario, what you're really 
>> talking about is the capability for any site A to dynamically begin 
>> serving as a "proxy" IdP for a user to another trusted site B, simply 
>> by issuing a URL for accessing site B that points back to site A as 
>> the OpenID IdP.
>> Do I have that right?
>> If so, that's both really cool, and – possibly – a little scary, 
>> because the user may not expect/want site A to act in that proxy IdP 
>> capacity.
>> What do folks think?
>> =Drummond (i-name: =drummond.reed,
>> From: yadis-bounces at [mailto: 
>> yadis-bounces at] On Behalf Of Tony
>> Sent: Thursday, August 24, 2006 1:21 AM
>> To: yadis at
>> Subject: Seamless site-to-site account creation and login via OpenID
>> Thus far I've only read about OpenID and tried it out with some scant 
>> services.  However as far as I can tell, the process of creating an 
>> account and logging in to a trusted "partner" site could be made 
>> completely automated, correct?
>>  Example:
>>  User has an account on Web Site A.  User logs into Site A and a 
>> session cookie is set.
>>  User wants to access a service on Site B which is part of Site A's 
>> trusted network of partner sites.
>>  User requests Site B's feature on Site A.  Site A directs the user 
>> to Site B, passing their OpenID XRI for Site A to Site B.
>>  Site B would then contact Site A based on the OpenID to verify 
>> User's identity.  Site B would then issue an HTTP redirect for the 
>> user to a specially designed landing URL.
>>  When User's browser hits the landing URL, Site A checks the session 
>> cookie and sets up the trust relationship with Site B.
>>  As far as I can tell, this can be 100% seamless and behind the 
>> scenes, provided the user has 1) already logged into Site A and 2) 
>> Site A and B trust each other enough to use OpenID in this manner.
>>  Correct, or am I missing something?
>>  Tony Arcieri

More information about the yadis mailing list