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

Marius Scurtescu marius at
Thu Aug 24 23:06:13 UTC 2006

On 23-Aug-06, at 11:55 PM, Martin Atkins wrote:

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

I don't see how the smart mode is in any better shape than dumb mode.  
As Johannes pointed out, once there is an association the smart RP  
will not make any calls prior to forwarding the user to the IdP.  
Pinging the IdP before every authentication request would add one  
extra call, and removing an extra call seems to be the whole reason  
behind associations.

Do I miss anything here?


More information about the yadis mailing list