&gt;&gt; <span class="Apple-style-span" style="border-collapse: collapse; ">The idea of trying endpoint #2 first, and then failing back to #1 should NEVER be proposed or encouraged.</span><div><span class="Apple-style-span" style="border-collapse: collapse;">In a publicly documented standard, I agree with you.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse;">However, whitelists are common in actual practice.  We see them today in the consumer space, though the eventual goal is to minimize that approach.  In the case of Google Apps, most of the interest in this feature has come from SaaS vendors who are developing products that ONLY work for existing users of Google Apps, and that also require using the hybrid OAuth/OpenID integration with Google to access our APIs.  So by definition, the only IDP/OAuth-SP they can &quot;trust&quot; is Google Apps.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse;">&gt;&gt; The other thing that concerns me is how close we are to having a committee draft of XRD.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse;">We haven&#39;t formally announced it yet :-)  We keep delaying internally, but at some point we&#39;ll have to launch it and I would be surprised if we can hold off for longer then a few weeks given how many months we have already delayed.  But when the drafts get finalized, we&#39;re hoping to support it within a small number of days and remove documentation for the proof-of-concept approach.  The partners we have already worked with have read the warnings in our documentation that we will be switching the discovery mechanism once the standards gets solidified, so they are prepared to have to make that change on their side.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></div><div><br><div class="gmail_quote">On Thu, Jul 9, 2009 at 4:21 PM, Will Norris <span dir="ltr">&lt;<a href="mailto:will@willnorris.com">will@willnorris.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
On Jul 9, 2009, at 1:16 PM, Eric Sachs wrote:<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

So it sounds like this was actually intended to go to the board-private<br>
list, but since it is public I&#39;m going to throw in my two cents.<br>
<br>
</blockquote>
<br></div><div class="im">
Feel free to discuss it on the main mailing list.  The discovery discussions<br>
are not meant to be private.<br>
<br>
I recently posted a pointer in such a thread that says<br>
<br>
For nitty gritty details, see<br>
<a href="http://sites.google.com/site/oauthgoog/fedlogininterp/openiddiscovery" target="_blank">http://sites.google.com/site/oauthgoog/fedlogininterp/openiddiscovery</a><br>
</div></blockquote>
<br>
okay, that is helpful.  The only thing linked to in your post was a document on a google group that I couldn&#39;t access.  This looks very familiar, because we talked about this in depth on various XRI TC calls.<div class="im">
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But if the relying party is unable to discover an OpenID provider through<br>
normal discovery means, they make an API call to Google asking if Google<br>
hosts OpenID services for that domain<br>
<br>
</blockquote>
<br>
The doc above has more details, including defining a way for a domain who<br>
outsources their IDP (or RP in the case of someone like Janrain) to publish<br>
a single simple file pointing to that SaaS provider.  An RP could also<br>
choose to pole the SaaS providers directly, but that is a policy/UI decision<br>
for them, and by definition that type of one-off doesn&#39;t seem like it could,<br>
or needs to be, standardized.<br>
</blockquote>
<br>
<br></div>
The document you mention all but actually recommends that approach:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There are two locations where the host-meta document might be found:<br>
<br>
(1) <a href="http://example.com/host-meta" target="_blank">http://example.com/host-meta</a><br>
(2) <a href="https://www.google.com/accounts/o8/host-meta?hd=example.com" target="_blank">https://www.google.com/accounts/o8/host-meta?hd=example.com</a><br>
<br>
Google&#39;s endpoint will return a 400 on endpoint (2) if the domain provided has not outsourced OpenID IdP funcionality to Google. So one possible strategy for an RP could be to first try endpoint (2), and if that returns a 400, try endpoint (1), and if that doesn&#39;t yield anything, give up. Other strategies (fetching both endpoints in parallel, for example), are possible.<br>

</blockquote>
<br>
<br>
The idea of trying endpoint #2 first, and then failing back to #1 should NEVER be proposed or encouraged.  Quite the opposite, it should be strongly discouraged.  It&#39;s language like this that make this feel like a vendor-specific approach that the OpenID Foundation should have nothing to do with.  RPs should be instructed to ALWAYS attempt #1 first, otherwise the domain owner is no longer in control.<div class="im">
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But the more concerning matter is that the OpenID Foundation is being<br>
asked to endorse one specific vendor as THE fallback for OpenID discovery.<br>
<br>
</blockquote>
<br>
Sorry if it sounded like that is what we I was suggesting.  I was suggesting<br>
the OIDF could be supportive of the &quot;approach&quot; we are taking of working with<br>
the community these last 6-9 months to establish standards for these types<br>
of use cases.  Even our documentation specifies that the current<br>
implementation is just a proof-of-concept for how to do discovery when a<br>
SaaS provider is involved, and describes a method that does NOT require &quot;one<br>
specific vendor as the fallback for OpenID discovery&quot; though I agree some<br>
RPs may choose to do one-off polling of a few SaaS providers.<br>
</blockquote>
<br></div>
The other thing that concerns me is how close we are to having a committee draft of XRD.  Admittedly, no we&#39;re not there yet.  And part of that delay has been because we&#39;re making sure that we have a solution that all involved parties can live with, including Google.  But I get a bit frustrated when Google claims to be supporting the new standard (and I&#39;ll be the first to say how valuable their input has been), but appears to be putting all their resources behind an incompatible approach to the same problem... one that I&#39;m afraid will only lead to great confusion[0] if it gets any kind of widespread adoption.  If Google wants to throw it out there as a possible stop-gap solution their customers can use until the next version of OpenID Discovery is written, that is fine.  But I just don&#39;t believe it&#39;s the kind of approach the foundation should be endorsing when we&#39;re so close with XRD.<br>
<font color="#888888">
<br>
-will</font><div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
board mailing list<br>
<a href="mailto:board@openid.net" target="_blank">board@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/board" target="_blank">http://openid.net/mailman/listinfo/board</a><br>
</div></div></blockquote></div><br></div>