OpenID – Part III – PingPong

That drawing is, hopefully, an illustration of how OpenID allows a site, Steve, to authenticate a user, Alice. Steve asks Alice for here OpenID URL and Alice reveals that. Steve uses that to fetch the associated page, hosted at Bob’s. Information on that page tells him about Alice. For example that page could be Alice’s blog, or home page, or even just her public account.

To be sure that Alice’s claim to her page at Bob is valid Steve extracts from that page a pointer to a OpenID server. That server is run by Victor. Steve then asks Alices browser to obtain a signed assertion from Victor in support of her claim to the page. When Alice get’s the assertion she passes it back to Steve.

None of this requires JavaScript, but elements of it can be made to appear smoother by it’s addition.

This drawing does not show how Steve came to trust Victor, nor even how he came to be able to validate Victor’s signature on the assertion.

OpenID doesn’t say very much about the format of the page Alice reveals to Steve. The page is HTML, and it needs to have a link to the Victor’s service point. Of course Alice can reveal lots of information on that page. Pointers to FOAF files, ICMB links, VCards, what ever. That’s up to her.

The page that Alice reveals is very likely to be public. Steve does not have an account relationship with Bob. Similarly all this traffic is HTTP, not HTTPS.

Hopefully this is reasonably accurate.

Here is the scenario in words.

1. Alice visits Steve.
2. Steve prompts Alice for her OpenID URL.
3. Alice reveals here OpenID URL to Steve.
4. Steve cleans up the OpenID URL Alice Revealed.
5. Steve Fetchs the OpenID page Alice revealed from Bob.
6. Bob normalizes the OpenID URL and redirects Steve.
7. Steve fetchs the actual OpenID from Bob based on Alice
   and Bob's input.
8. Bob returns Alice's OpenID page.
9. Steve extracts the OpenID service end point from that page.
10. Steve requests an assertion from Victor, via Alice, to prove
    that Alice controls the OpenID page she claims.
11. Alice asks Victor for the assertion Steve wants.
12. Victor checks that it's Alice who's asking.
13. Victor, now working for Alice, checks that Alice has authorized telling Steve anything about her.
14. Victor creates the assertion Steve needs, checking of course that Alice controls this OpenID url.
15. Victor signs the assertion.
16. Victor sends that assertion back to Alice.
17. Alice sends the assertion back to Steve.
18. Steve verifies the Victor's signature.
19. Steve studies the assertion and acts approprately.

19 thoughts on “OpenID – Part III – PingPong

  1. Xageroth

    OpenID has stated they don’t deal with trust. So as far as when Steve came to trust Victor, I don’t think that ever actually occurs. I’m basing this on my own assumptions since my project mirrors OpenID in many ways. I believe the basic premise is that finding ways to evaluate trust of individual identities is more important than trusting services because at the root of identity is the user and not the service.

    A simple analogy would be if you trusted your best friend Joe and you want to ask him for Dave’s phone number. If Dave lied to Joe about his phone number, does it really matter whether or not you trust Joe for that information?

  2. Pingback: thrashor

  3. WorldMaker

    Xageroth: OpenID, at the protocol level, does not support trust mechanics at the individual level. On the other hand that doesn’t stop each of the parties involved in an action from forming their own trust relationships at the server level. “I don’t allow anyone who uses as their auth server” or “I only allow people with IDs”. Both are possible scenarios you might see at the individual website address, just like how websites might not accept registrations from people with accounts.

    You think that individual user trust is more important, but I believe that a lot of that _is_ handled by the services you trust. Can you trust to not give spammers accounts? Can you trust to do any sort of email verification? Certainly there could be quite a bit of variance in the amount you trust each site, and you can always block individual identities (ie, smells, so I won’t let her post), but the point is that each party has to do it for herself or himself and there is no protocol level determination nor guarantee of trust.

    Your analogy breaks down a bit. OpenID is that when Dave comes to you, and you know him through Joe, and you ask Joe to verify that the phone number Dave just gave you is the same as the phone number Joe received. If Dave lies to one of you, you know automatically not to trust Dave if you trust Joe. Simple as that, and to answer your question it does matter here that you trust Joe’s information. In this case Joe isn’t vouching for the accuracy of the phone number, only that Dave gave him a number and it either matches or it doesn’t.

  4. Pingback: » Blog Archive » More on OpenID

  5. Pingback: Plains in the Dreaming » Blog Archive » OpenID Ping Pong

  6. Dag Arneson

    Francis, OpenID is secure even over plain HTTP. The above diagram is accurate if Steve already knows Victor, but if he does not then there is one more step that is not shown. After step 9, if Steve does not know about yet, he makes a request for an association with Victor by visiting the openid endpoint. Steve and Victor then use diffie hellman to negotiate a shared secret which they both store. Victor uses this association to sign the identity assertions he issues to Steve.

    Alternatively there is ‘Dumb mode’ when Steve is unable to store state. In this case Steve visits Victor’s openid endpoint in step 18 and asks for an assertion that the data he recieved from Alice’s browser was correct.

  7. Pingback: This Old Network » OpenID enabled claimID - almost here

  8. Lopo Lencastre de Almeida

    This is very interesting for remote administration (TAx Authorities, Healthcare systems, etc).
    We are going to look further on this to deal with remote identification in Care2x and Care3G.

    Thanks for the nice explanation and all comments.

    Best regards

  9. Pingback: Stephen Pascoe’s Blog» Blog Archive » OpenID and LID compared

  10. Cheryl

    First off, I’m a non-techie.

    I’m getting confused at steps 12-14. How does Victor check that it’s actually Alice who is asking and not just someone who knows Alice’s OpenID URL?


  11. Brian

    @Cheryl – As you pointed out, the basic problem to solve is how to verify if the person entering the URL is actually the person who OWNS the URL.

    Steve doesn’t actually know anything about the person entering the URL on his web page. The URL says to ask Victor, so Steve will actually make the request to Victor indirectly, by redirecting Alice’s browser to an authentication URL at Victor. Thus, Victor will receive Alice’s cookies in this redirected request, and these cookies may contain a token that represents Alice’s login session with Victor, if she has already logged into Victor once before. In this case, Victor knows Alice already, and also knows if the URL belongs to Alice. Thus, Victor can answer YES or NO and sign the answer using a shared key only Victor and Steve know. The signed answer is sent back to Steve and Steve can verify the signature came from Victor.

    If Alice has never logged into Victor before, Alice will not yet have a session cookie with Victor, and Victor will present Alice with a login page. Alice (or the bad guy using Alice’s URL) must now log into Victor with a username/password and get a session cookie with Victor before Victor can answer Steve with YES or NO.

    So you cannot simply pose as Alice by using her URL on an OpenID site, unless you know Alice’s username/password with Victor. If you are Alice, and you’ve already logged into Victor once, you can use your OpenID URL at any OpenID site without ever needing to enter a username/password again (until your session expires with Victor)

    Hope that clears it up.
    – Brian

  12. Charles Darke

    At or around stage 9 in the diagram. If Bob turned evil and wanted to log onto Trevor site (impersonating Alice) could Bob do this? That is, Bob would log on to Trevor and use any information previously given by Alice etc. to try to authenticate.

  13. Pingback: - Openid : une nouvelle vision décentralisée de la gestion de l’identité numérique.

  14. Pingback: The Security Roundtable » Blog Archive » The Security Roundtable for February 2007 - OpenID

  15. Pingback: How OpenID works |

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>