OpenID/OAuth hybrid - discovery

Dirk Balfanz balfanz at google.com
Tue Nov 25 21:36:24 UTC 2008


I really don't think we're disagreeing here. There should and will be more
places to discover OAuth endpoints, etc. But that's outside the scope of
this spec. All we'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'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.

Dirk.

On Mon, Nov 24, 2008 at 11:26 PM, Martin Atkins <mart at degeneration.co.uk>wrote:

> Dirk Balfanz wrote:
>
>>
>> We're defining an OpenID extension. Consumer will want to know whether or
>> not a given endpoint speaks that extension. That's all it'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'll have these massive XRD documents advertising all sorts of things -
>> OAuth request token endpoints, portable contact endpoints, etc.).
>>
>>
> I guess I'm assuming that the OAuth service saying "use that OpenID
> provider for hybrid OpenID/OAuth" implies that the OpenID Provider supports
> the extension.
>
> However, I guess the following flow could arise:
>  * User does something that requires OAuth.
>  * 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.
>  * Consumer does discovery on the OpenID Provider and determines that it
> doesn't actually support the extension.
>  * Consumer falls back on the non-combined flow, or just tells the user
> that the service provider is broken.
>
> While it's nice to fail early in this case, the consumer still needs to
> deal with a bunch of post-authorization failure cases:
>  * Provider claimed to support the extension but didn't actually return
> anything.
>  * Provider claimed to support the extension but the approved request token
> doesn't actually work for some reason.
>  * Provider claimed to support the extension but it turns out it doesn't
> support this particular sort of request token.
>  * ...
>
> In most cases, the implication from the OAuth discovery step will be enough
> and everything will work out. I'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'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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20081125/09a604f6/attachment-0002.htm>


More information about the specs mailing list