[OpenID] Graphical UIs

[Nate Klingenstein]

Andrew,

> Thanks for trying to explain it Nate.  Actually what I was wondering  
> is why OAuth must be part of the request at all.

I was interested in leveraging existing whitelists, because it seems  
like maintaining multiple sets of bilateral agreements is redundant  
and cumbersome*2.

> There's been talk on this thread of bringing OAuth into it so that a  
> signed message from the RP can be sent to the OP.  First of all,  
> using OAuth just for its signing seems like a misuse.  The OpenID 
> +OAuth extension that you described doesn't sign the request at  
> all.  And finally, it escapes me why the request needs to be signed  
> at all.  If an attacker were to form a request to look like it came  
> from a legitimate company, then the assertion would go to that  
> legitimate company (assuming RP discovery and return_to matching was  
> successful) and the attacker would have gained nothing.

I agree with all this.  Signing authentication requests is (mostly,  
with the exception of a few very fringe use cases) worthless in  
general, and a potential DoS risk to boot.

Humanized pre-registration would prevent an attacker from receiving  
any authentication information at all, even if it successfully created  
a request pointing at itself with an arbitrary logo displayed to the  
user.  If it's able to register itself with no interaction, or the OP  
is in promiscuous mode, then even that benefit is gone.

> So why must OAuth be part of login just so that logos from the RP  
> can show up at the OP?


There really is no way to get out of this without some form of trust  
fabric.  Since apparently the hybrid doesn't offer one either in spec  
nor in practice, I see no protection as currently formulated.

Take care,
Nate.