OpenID/OAuth hybrid - discovery

Dirk Balfanz balfanz at google.com
Tue Nov 25 07:10:24 UTC 2008


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

> Dirk Balfanz wrote:
> > I'm not sure I understand what the commotion is about :-)
> >
> > OAuth discovery (when it is done), will answer the question: given the
> > URL of a resource, where do I go to get access tokens for that resource.
> > The question answered by the XRD element described in Section 5 is "does
> > this OpenID endpoint support the Hybrid protocol". These two questions
> > are somewhat related, but clearly different. And, yes, the latter is not
> > nearly as exciting as the former.
> >
>
> What is a consumer intended to do with this information?
>

It could decide to combine an OpenID auth request and an OAuth request into
one hybrid request, instead of doing OpenID first, and then (once the user
is logged in) doing OAuth. This information also tells the consumer where
the auth-request endpoint of the Combined Provider is.


>
> Telling me that the OpenID provider also supports the OAuth hybrid
> protocol is not useful alone. It's not like I can just take any OAuth
>

Agreed.


> token in the world and feed it to this endpoint.
>
> More useful, I think, would be to have the OAuth discovery information
> *at the service endpoint* say that "the OAuth authorization URL for this
>

Agreed.

These are not mutually exclusive. When performing discovery on a
user-supplied identifier it's useful to say "the combined endpoint for this
user-supplied identifier is over there". (We'll also need to be able to say
"the request token you'll get from the combined endpoint can be exchanged
for an access token over here" - but that will be covered in the OAuth
discovery spec.) At the combined endpoint it would indeed make sense to say
where the other OAuth URLs are (although the combined endpoint needs only
one other OAuth URL - the access token endpoint).


> service is <some-url>, and the combined OpenID/OAuth endpoint for this
> service is <some-other-url>". The first part of this will presumably be
> catered for by OAuth discovery.


Yes.


> The second part seems like it ought to
> be an extension to OAuth discovery, though I don't have a good answer
> for what exactly it'd look like on the wire.
>

The second part is exactly what is defined in Section 5. It's part of OpenID
discovery (not OAuth), b/c the combined endpoint _is_ the OpenID endpoint
(an OpenID endpoint that happens to speak the OAuth extension).



> As currently speced, I'm not sure what problem that section is
> addressing or what value it provides. Perhaps for now it'd be better to
>

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.).

Dirk.



> take that part out of the Hybrid Protocol specification and defer that
> problem until it's clearer how OAuth discovery will work in general.
>
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20081124/a15f818f/attachment-0002.htm>


More information about the specs mailing list