Johannes Ernst at
Wed Aug 30 22:01:55 UTC 2006

Josh Hoyt and I had a conversation on this accidentally off-list.  
Here is the gist of it. I also blogged it at 

> Josh: Having a trust root does not prevent an attack. It just  
> provides an indication to the user of what the Relying Party  
> intends to do with the decision. Its primary purpose is to make the  
> user experience nicer, by being easier to understand than a full  
> return_to URL. It also allows the IdP to help the user with  
> authentication decisions for a site, even if the return_to changes  
> (e.g. by adding query parameters)
> Johannes: So if it is only about the user interface, then why are  
> we checking it on the IdP side?
> Josh: It's being checked to make sure (as much as we can) that the  
> RP is not misrepresenting itself to the user. The checks are to  
> make sure that the return_to actually *is* in the range that the RP  
> is claiming and that the range is something sane.

This is a good explanation. Thanks, Josh. As a friend of minimalistic  
protocols, I'm still not sure it's really needed (e.g. do we really  
need to have return_to URLs that have incomprehensible parameters?)  
but the use that Josh suggests is a good one. I hope somebody will  
put a sentence into the upcoming OpenID 2.0 spec that explains this  
in a similar manner.

On Aug 30, 2006, at 12:58, Johannes Ernst wrote:

> Which reminds me that I've never quite understood what the attack  
> is that the OpenID trust_root protects against. There seems to be  
> no mechanism by which the user (or the IdP) could force the RP to  
> only apply authentication to places covered by trust_root. And  
> return_to already to where the authentication assertion goes.
> Anybody enlightened on this list who'd like to enlighten me?  
> Thanks ...
> Johannes Ernst
> NetMesh Inc.
> <lid.gif>

Johannes Ernst
NetMesh Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
Url :
-------------- next part --------------

More information about the yadis mailing list