How do we know whether a service URI is available (related question)

Martin Atkins mart at
Thu Aug 24 06:55:12 UTC 2006

Johannes Ernst wrote:
> It's reasonably straightforward to determine whether a service URI is 
> available for things like server-to-server communication, e.g. by 
> setting a timeout.
> But what about the redirect operations? Let's say there are two service 
> URIs for a given identifier, one with a higher priority than the other. 
> A few days after having negotiating a shared secret, server 1 goes down. 
> Upon an attempted authentication, the relying party will be blissfully 
> unaware of the unavailability of that URL and redirect the user to a URL 
> that doesn't work, leading to a 404 or 500 or even "server not found" 
> exception in the browser.
> Is there something more intelligent that we can do? [I'm thinking of the 
> very confused user who has no idea about redirects and SSO etc. etc.]
> What about a very efficient ping prior to redirect from the RP to the 
> service URI?
> Or do I see a problem where there isn't one?

This was one of the main reasons why OpenID 1.1 didn't allow multiple 
providers with fallback: that the relying party can "see" the provider 
doesn't guarantee that the user can "see" the provider.

In practice, this only affects relying parties in "dumb mode" (I think 
this discussion happened before "smart mode" was invented), since we 
have to assume that the user can see it if the relying party can see it. 
(otherwise all bets are off!).

Perhaps "dumb mode" relying parties could be required to make a funny 
kind of association that doesn't really create any state but just says 
"Hey provider, I'm going to make a stateless query!" I guess then the 
provider could reply "Oh no you aren't!" and stateless relying parties 
can fail early before doing the redirect.

That's one extra request that has to be made in dumb mode vs. smart 
mode, however.

More information about the yadis mailing list