Why would OAuth be necessary? If an RP registered with an OP and submitted their logos/text/etc, then any auth request coming in with the registered realm could display those pictures. There is a danger that <a href="http://hacker.com">hacker.com</a> might register and upload the Wells Fargo logo, but OAuth won't prevent that. <br>
<br>To avoid registration at all, an OP could perform discovery on the RP realm and find an XRDS with pointers to the resources that the RP wants to display. Again, you have the phishing logo problem here, but as far as I can tell there's no good way to fix that without a trust infrastructure. Perhaps one of those extra-strong SSL certs at the RP during discovery would provide the needed assurance of a legitimate company?<br>
<br clear="all">--<br>Andrew Arnott<br>"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre<br>
<br><br><div class="gmail_quote">2009/5/14 Nate Klingenstein <span dir="ltr"><<a href="mailto:ndk@internet2.edu">ndk@internet2.edu</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
George,<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In the case of OAuth, some level of out-of-band establishment is required anyway. If when requesting an OAuth Consumer token and secret, I can also present the resources to be displayed during authentication, then I have a mechanism of establishing the trust necessary to "safely" provide greater UI customizations.<br>
<br>
Note that this doesn't preclude RPs from using the OP at any time. It's just if there isn't any trust the user at the RP will see the standard OP UI rather than a customized one (because the OP doesn't have any "trust" with the RP).<br>
</blockquote>
<br></div>
I think this is all consistent with what I wrote. My concern is that the requirement for bilateral trust establishment, which is one of those N(N-1)/2 kinds of problems. That's clearly unfeasible in our deployment environments, though it may be a more reasonable multiplier in yours. This is where I continue to see a strong roll for other trust establishment techniques.<br>
<br>
Also, the reliance on OAuth would mean that such a trust solution would not be available to those using OpenID alone.<br>
<br>
I really think we need a more cohesive solution for OpenID trust establishment.<br><font color="#888888">
Nate.</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
</div></div></blockquote></div><br>