Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

Walkthrough of a typical XRD/OpenID/OAuth use case

There is currently no provisioning mechanism for a service to insert itself in a user's XRD file.

Is it possible for a Consumer to find another service? Yes but only in a public way, because it's in the XRDS.

  1. The user visits a site he's never been before and gives his OpenID
  2. The site discovers where the user's OP is. To do so, it sends GET on the OpenID ID with accept:app/xrds+xml. There are 3 variants of this discovery step:
    1. HTTP header that tells the location of the XRDS document
    2. Returning the XRDS document itself
    3. Get HTML that is to be parse the head for looking for the tag that tells where the XRDS document is.
  3. The site parse the document to find the OP. The TYPE element defines whether the service supports OpenID2 or if it supports AX etc.This dicovery process is chainable so that a service can then retrieve the XRDS of a service that will describe things like the fact that it supports OAuth etc. This chaining needs to be trusted (need to sign etc.).There are 2 modes of thinking with respect to an XRD:
    1. My XRDS has all the endpoints in there for all my services
    2. All supported extensions are pointers at the service- those pointers are where the real OAuth pointer (for instance) can be requested.
  4. Do an XRD discovery on, say, twitter.com. The result will contain, for instance, links to the OAuth endpoints (request token, authorize etc.)

Some privacy concerns with the XRD model:

  • When the site I visit needs to access another service (e.g. my calendar service), it retrieves my XRDS and as a result gets information on all the services I use
  • Multiple identities: I want to find your calendar to put in an entry and, doing so, I can see all your services.
  • I want to show some services I use to a set of people only

How do you protect this? We should enable identity-restricted metadata discovery. This amounts to changing the result of the XRD request based on identity and sign it on the fly (if needed).

Another issue: all those operations are front channel so that this becomes very painful for the user as soon as we get passed the 1-site interaction level.

Potential areas of investigation

  1. Having a way for the OP to generate an OAuth access token for all the sites that do accept that OP (e.g. Yahoo! would generate an OAuth token, about the user, for Hiking.com to present it to another site like Twitter)?
  2. Using the interaction service to get consent to generate the token.
  3. Having a DS co-located with the OP that can generate tokens, we have an opportunity to apply policies there.
  4. Federation might be a contributing factor in the authorization decision too (e.g.
  • No labels