I really don&#39;t think we&#39;re disagreeing here. There should and will be more places to discover OAuth endpoints, etc. But that&#39;s outside the scope of this spec. All we&#39;re saying in this spec is that if discovery starts from a user-supplied OpenID (not from a OAuth-protected resource, btw, which is the use case you&#39;re describing below), there is a way for the OP to signal to the RP whether it might want to try sending the OAuth extension parameters along with the auth request. There is no extra HTTP transaction.<br>
<br>Dirk.<br><br><div class="gmail_quote">On Mon, Nov 24, 2008 at 11:26 PM, Martin Atkins <span dir="ltr">&lt;<a href="mailto:mart@degeneration.co.uk">mart@degeneration.co.uk</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Dirk Balfanz wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
We&#39;re defining an OpenID extension. Consumer will want to know whether or not a given endpoint speaks that extension. That&#39;s all it&#39;s doing - just like AX or PAPE have a section on discoverability. It also gives consumers a way to look for the combined OpenID/OAuth endpoint (assuming that one day we&#39;ll have these massive XRD documents advertising all sorts of things - OAuth request token endpoints, portable contact endpoints, etc.).<br>

<br>
</blockquote>
<br></div>
I guess I&#39;m assuming that the OAuth service saying &quot;use that OpenID provider for hybrid OpenID/OAuth&quot; implies that the OpenID Provider supports the extension.<br>
<br>
However, I guess the following flow could arise:<br>
&nbsp;* User does something that requires OAuth.<br>
&nbsp;* Consumer does OAuth Discovery (to be defined) and determines, amongst other things, the URL of the OpenID Provider that will do the combined OpenID/OAuth bit.<br>
&nbsp;* Consumer does discovery on the OpenID Provider and determines that it doesn&#39;t actually support the extension.<br>
&nbsp;* Consumer falls back on the non-combined flow, or just tells the user that the service provider is broken.<br>
<br>
While it&#39;s nice to fail early in this case, the consumer still needs to deal with a bunch of post-authorization failure cases:<br>
&nbsp;* Provider claimed to support the extension but didn&#39;t actually return anything.<br>
&nbsp;* Provider claimed to support the extension but the approved request token doesn&#39;t actually work for some reason.<br>
&nbsp;* Provider claimed to support the extension but it turns out it doesn&#39;t support this particular sort of request token.<br>
&nbsp;* ...<br>
<br>
In most cases, the implication from the OAuth discovery step will be enough and everything will work out. I&#39;m not sure whether failing early in this one (unlikely) error case is worth the extra HTTP transaction(s) to find out whether the provider really supports the extension. It&#39;d be more efficient to just send a request to the OpenID provider with the extension arguments and see if you get back a response.<br>

<br>
</blockquote></div><br>