This blog can't be viewed on LiveJournal. Instead see

OpenID Providers ignoring openid.identity

27th Oct 2008

Yahoo!'s OP and now it seems Microsoft's OP both ignore the value of openid.identity provided to them, and just return an assertion for whatever user's logged in. While this is technically valid if you think of the result as an "unsolicited positive assertion" as per the spec, it's a bit counter-intuitive. While it works okay for the sign-on case, it's not so hot for the basic "prove I own a URL" case: consumers attempting to do this find that they end up with an assertion for a URL that they don't care about.

I think the ideal behavior, both to avoid breaking this use-case and to make it clear to users what they're logging in as, is to tell the user they're logged in as the wrong identifier and prompt them for the credentials for the identifier they entered. Of course, if openid.identity is the special value /2.0/identifier_select then the current behavior is fine; in this case, the RP is saying "tell me a URL this user owns", not "does this user own this URL?".

I'd be interested to hear what advantages there are to ignoring openid.identity. I've not been able to think of any.


  • (comment with no subject)

    Hi Martin,

    To clarify the behaviour of the Microsoft OP, we actually do not ignore openid.identity at all.

    We see 2 scenarios here:

    1. If the coming openid.identity is, then we let user choose which OpenID Alias they want to use to sign-in and return back to the RP.

    2. If the incoming openid.identity is something else, we pre-fill and block the OpenID Alias in login screen from being changed. Naturally, we also provide a Cancel option for users to go to RP to change their claimed identity.

    So if the user entering a specific URI / alias at the RP, they can either sign-in to our OP and prove they own that Alias, or they must cancel if they can't / don't.

    We think we are doing the right thing here, but we welcome feedback and discussion from the community.

    Hope that helps to clarify the situation.

    - Jorgen Thelin
    By ext_130600 at 09:40 pm on 28th Oct 2008
    • (comment with no subject)

      Hi Jorgen,

      I think I was mistaken about the Windows Live ID OP. I must confess that I only experimented with it briefly and I may have made an error when I was testing.

      I notice that the directed identity endpoint declares openid2.provider in its HTML, which is not supposed to be declared for a directed identity endpoint. The endpoint is, however, using the Accept header to trigger sending back an XRDS document with the correct information in it, so I think perhaps this was the source of my confusion. Having tried it again now I see that it does work as expected.

      I apologise for posting misleading information. It may be worth considering removing the element from the HTML produced at that endpoint when no Accept header is sent; while no compliant OpenID 2.0 RP should see it, it is a little confusing to humans like me.

      (As a side note, I assume by the fact that you've managed to comment with your identifer that LiveJournal has upgraded their RP to support OpenID 2.0, which is good news. My blog only supporting 1.1 was a bit embarassing. ;))

      By Martin Atkins at 09:55 pm on 28th Oct 2008
    • test

      By ext_130748 at 07:44 pm on 29th Oct 2008