<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<br>It seems that there are a few different ways to address this issue.
Though because you are making
<br>login to your service dependent on an external web service (open id
provider); there is going to be
<br>that risk -
<p><b>1) Build in redundancy into the Open ID provider</b>
<br>Uptime and availibility is one of the things on which an OpenID provider
can differentiate from other
<br>OpenID providers.
<p>What we could do is enable the Open ID provider to clearly communicate
its SLA in
<br>a clear mannner to the end-user as well as relying party so that
the end-user can make an informed
<br>decision as well as the relying party can clearly request policies
around SLA of the ope ID provider.
<br>(This is similar to the PAPE - which is around security policies)
<p>Of course there are several techniques available today for open Id providers
to build in redundant
<br>and highly available services - this would be out of scope of this
discussion.
<p><b>2) Build in some redundancy into the protocol. </b>There has been
some discussion about this on the
<br>mailing list. Again I'm not sure that it is possible to build in redundancy
unless there is a smart client
<br>that is doing the failover if at the network layer.
<p><b>3) Relying Party provides- one-time/limited access</b>
<br>Of course the relying party may want to have some way to allow a user
limited access (one time
<br>access codes and such); after verifying the user's identity. There
are several techniques that people
<br>use including - sending one time access codes to registered phone numbers
(SMS), email addresses,
<br>challenge-response questions, etc. Most web-sites already have this
functionality today to support
<br>'forgotten password' scenarios.
<p><b>4) User can use another OpenID provider - </b>Relying party can let
the user register multiple OpenIDs
<br>i.e. aliases to access the service. Of course the issue here is additional
onus on the user.
<p>Note that of course the above approaches above are not mutually exclusive
but they could be used
<br>together.
<p>I don't know if there is a OpenID Relying Party best-practices document...
<p>Siddharth
<br>
<br>
<blockquote TYPE=CITE>
<br>Message: 2
<br>Date: Thu, 6 Dec 2007 18:10:13 +0000
<br>From: " Andr? Lu?s " ?andreluis.pt@gmail.com?
<br>Subject: Re: [OpenID] OpenId downtime
<br>To: "Dominick Accattato" ?daccattato@gmail.com?
<br>Cc: general@openid.net
<br>Message-ID:
<br> ?dc1a17860712061010k6d371e27j78cb2b9bf16df8c7@mail.gmail.com?
<br>Content-Type: text/plain; charset=ISO-8859-1
<p>That's why I believe it's a good practice for each user to have more
<br>than one provider and the consumer services allow to register more
<br>than one OpenID address for each of their account.
<p>I'm new to the list, so pardon if any of this have been argued against.
<p>Cheers,
<br>Andr? Lu?s
<p>On Dec 6, 2007 5:47 PM, Dominick Accattato ?daccattato@gmail.com? wrote:
<br>? What happens when an OpenId provider is down:
<br>? <a href="http://www.alexanderinteractive.com/blog/2007/09/disadvantage-of-openid-and-web-services.html">http://www.alexanderinteractive.com/blog/2007/09/disadvantage-of-openid-and-web-services.html</a>
<br>?
<br>? --
<br>? Dominick Accattato, CTO
<br>? Infrared5 Inc.
<br>? www.infrared5.com
<br>? _______________________________________________
<br>? general mailing list
<br>? general@openid.net
<br>? <a href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</a>
<br>?
<br>?
<br> </blockquote>
</html>