[OpenID] Multiple endpoints in a single XRDS document
Johannes Ernst
jernst+openid.net at netmesh.us
Thu Jul 17 20:22:29 UTC 2008
I believe that was one of the arguments traditional hypertext people
made in the beginning of the web: "how do we know that following a
link necessarily leads anywhere?" -- the same problem, essentially.
Did not prevent the web from being used, however ;-)
Worse is the OpenID-lost-and-lost-access-to-account problem that I
just wrote about re possible future work for OpenID:
http://netmesh.info/jernst/Digital_Identity/openid-whats-next-200807.html
On 2008/07/16, at 7:07, Andrew Arnott wrote:
> Agreed. Pinging in advance in any fashion probably isn't the
> answer. But it's a shame that, aside from frames which suffer from
> fear of phishing as I described, there's no way for an RP to recover
> after an OP fails. The user just needs to learn to click Back if
> that happens. But even then, what is the user to do? Logging in
> again will surely fail again..... so he leaves the RP site. To an
> RP that really doesn't want to lose users to this, they may want to
> seriously consider the extra checkbox saying "choose your provider."
>
> But then, 99.9% of OpenID users today don't have an XRDS listing
> more than one OP anyway. Most of them have yahoo.com or some other
> extremely reliable OP though, so it's mostly a non-issue I guess.
>
> Just ramblings as you can tell.
>
> On Wed, Jul 16, 2008 at 1:02 AM, James Tindall <james at atomless.com>
> wrote:
> Yes, a redirect does not solve the problem of an offline OP. I think
> you're right 'pinging' the OP prior to authenticating to ensure that
> it's online may be the only solution.
> It just seems unfortunate to have to add yet another RP to OP
> communication step just to cater for any, probably extremely
> infrequent,
> OP downtime?
>
> =james.tindall
>
> Andrew Arnott wrote:
> > As I understand it, checkid_immediate is an optional step the RP
> can take,
> > that was added for AJAX scenarios. In my mind, this is a useless
> feature as
> > checkid_setup also tends to be 'immediate' if checkid_immediate
> would have
> > worked, and if checkid_immediate fails, then the very next thing
> the RP
> > inevitably does is follow up with a checkid_setup request.
> >
> > As far as testing for OP-deadness, checkid_immediate is no good
> because it's
> > a redirect of the browser just as checkid_setup is. If the OP is
> dead, the
> > user gets a dead-end error page regardless of what the openid.mode
> is set
> > to.
> >
> > Now, assuming all OPs are alive, the idea of running through all
> endpoints
> > with checkid_immediate first to see if any happen to authenticate,
> and only
> > if that fails doing a checkid_setup on the first good OP in the
> list is an
> > interesting idea. It would serve the user as he/she would have a
> higher
> > likelihood of not being prompted for credentials, which is cool.
> On the
> > negative side, it means that if the user has 3+ OPs listed, he gets
> > redirected *4 times* before finally seeing his first OP's
> authentication
> > page if none of them are willing to checkid_immediate.
> >
> > On Tue, Jul 15, 2008 at 9:16 AM, James Tindall
> <james at atomless.com> wrote:
> >
> >
> >> I've not double checked what the spec has to say about this
> Andrew but it
> >> seems to me that if an association with the chosen OP exists and
> is alive
> >> then the RP should simply attempt authorization using
> 'checkid_immediate'
> >> and if that then fails the RP should try authentication using the
> next
> >> endpoint in the list?
> >>
> >>
> >>
> >>
> >> Andrew Arnott wrote:
> >>
> >>
> >>> Another thought: since a responsible RP only creates a single
> association
> >>> with an OP and stores it until it expires, and these
> associations often
> >>> last
> >>> days, if the user has an endpoint in the XRDS doc that points to
> an OP
> >>> that
> >>> is currently down, but with whom the RP has an existing, unexpired
> >>> association with, the RP shouldn't try to create an association
> with that
> >>> OP. Instead, it might say to itself "yes, I successfully have an
> >>> association with this OP, so I'll redirect the user to it", but
> the OP
> >>> happens to be down for 5 hours that day, effectively disabling
> the user's
> >>> ability to log in, in spite of the multiple OPs listed in the
> XRDS doc.
> >>>
> >>> So... perhaps OpenID can have a "ping, are you alive?" message
> in its
> >>> protocol. But then we're no better than "dumb" RPs having to make
> >>> multiple
> >>> hits to the OP instead of just one.
> >>>
> >>> Another idea that keeps occuring to me is that the RP can use a
> frameset
> >>> to
> >>> keep an RP frame around and have the OP authentication happen in
> another
> >>> frame (iframe or frameset would work). That way, the RP frame
> could have
> >>> something like "Is your Provider not responding? Click here to
> try your
> >>> next best choice..." or something to that effect. The problem
> with this
> >>> idea is that the URL on the browser will always be the RP, so
> the user
> >>> will
> >>> have one less way to confirm that this is indeed his genuine
> Provider and
> >>> not one of those notorious OpenID RP phishing attacks.
> >>>
> >>> Anyone have any idea how to solve this dead OP problem?
> >>>
> >>> On Tue, Jul 15, 2008 at 1:52 AM, James Tindall
> <james at atomless.com>
> >>> wrote:
> >>>
> >>>
> >>>
> >>>
> >>>> I've recently been writing an openid relying party library for
> the
> >>>> Kohana php framework and I think you're right, the way I've
> tried to
> >>>> handle multiple enpoints returned from the discovery phase is
> to first
> >>>> sort them by their priority values and then also filter out any
> that do
> >>>> not meet the (extension / security / openid-version)
> requirements set in
> >>>> the current relying party configuration and then finally
> attempt to
> >>>> establish an association with each endpoint in turn until a
> successfull
> >>>> association response is returned.
> >>>>
> >>>> I feel that all this is best done invisibly rather than
> requesting the
> >>>> user to jump through extra hoops. The user has after all -at
> some point-
> >>>> set the priority of the endpoints listed in the xrds and I
> suspect that
> >>>> most would not wish for further input during the process of
> >>>> authentication. My assumption being that the point of multiple
> endpoints
> >>>> is to hopefully cater for the requirements of as many different
> relying
> >>>> parties as possible and to have alternative/backup endpoints
> incase of
> >>>> errors or failures with any of the other endpoints in the list
> during
> >>>> authentication?
> >>>>
> >>>> =james.tindall
> >>>>
> >>>> Andrew Arnott wrote:
> >>>>
> >>>>
> >>>>
> >>>>> I'm curious how other libraries do (or plan to) handle multiple
> >>>>> endpoints
> >>>>>
> >>>>>
> >>>>>
> >>>> in
> >>>>
> >>>>
> >>>>
> >>>>> a single XRDS document. I see a few considerations, in order:
> >>>>>
> >>>>> 1. Enumerate the services in the XRDS-defined priority order
> >>>>> 2. Skip the services that do not expose OpenID endpoints.
> >>>>> 3. Skip the OpenID endpoints with Providers that do not
> quality
> >>>>> (whitelist/blacklist or advertised extension support
> >>>>> 4. Take the first endpoint that is left after these filters.
> >>>>>
> >>>>> But what about the rest of the endpoints listed? Here are some
> >>>>> possibilities:
> >>>>>
> >>>>> 1. Just use the first endpoint and trust it works.
> >>>>> 2. Try each one successively. That is, the RP should
> attempt to
> >>>>> establish an association with each one until it succeeds
> with one, and
> >>>>>
> >>>>>
> >>>>>
> >>>> then
> >>>>
> >>>>
> >>>>
> >>>>> redirect the user to that one for authentication.
> Redirecting the
> >>>>>
> >>>>>
> >>>>>
> >>>> user to
> >>>>
> >>>>
> >>>>
> >>>>> an unavailable Provider will result in a dead end failure
> page and the
> >>>>>
> >>>>>
> >>>>>
> >>>> RP
> >>>>
> >>>>
> >>>>
> >>>>> will lose the opportunity at this point to try the next
> endpoint.
> >>>>> 3. A variant on the last, except that in addition to
> skipping OPs that
> >>>>>
> >>>>>
> >>>>>
> >>>> do
> >>>>
> >>>>
> >>>>
> >>>>> not respond to association requests, allow the user to
> "fail" or
> >>>>>
> >>>>>
> >>>>>
> >>>> cancel the
> >>>>
> >>>>
> >>>>
> >>>>> authentication on the first provider and proceed to the second
> >>>>>
> >>>>>
> >>>>>
> >>>> provider
> >>>>
> >>>>
> >>>>
> >>>>> listed for another authentication attempt.
> >>>>> 4. Offer the user a list of his/her providers to choose from
> for
> >>>>> authentication.
> >>>>>
> >>>>> Have thoughts been written already on which of these are best
> and/or
> >>>>>
> >>>>>
> >>>>>
> >>>> common
> >>>>
> >>>>
> >>>>
> >>>>> in existing libraries?
> >>>>>
> >>>>>
> >>>>>
> ------------------------------------------------------------------------
> >>>>>
> >>>>> _______________________________________________
> >>>>> general mailing list
> >>>>> general at openid.net
> >>>>> http://openid.net/mailman/listinfo/general
> >>>>>
> >>>>>
> >>>>>
> >>>>>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080717/2d4832a9/attachment-0002.htm>
More information about the general
mailing list