How do I identify an OpenID provider as requiring Directed Identity?

Question

I am trying to extend the LightOpenID PHP library to "discover" that an identity provider requires Directed Identity. This should be easy as the library is beautifully well written and wonderfully clean but I don't know how to identify these types of providers. A couple things I've tried:

• I looked through the OpenID specs on the subject but came up empty handed.
• Looked through the PHP OpenID library but couldn't figure out how this info was gathered during the discovery.
• Dumped all the data (headers and content) that came from the servers by injecting some code in LightOpenID but didn't see anything helpful.
• Searched Google and Stackoverflow, naturally.

How do providers identify themselves as requiring "Directed Identity" authentication? Surely there is a carefully defined specification for this... somewhere.

Anyone know where I can find more on this?

Answer 1

EDIT: What I describe a above is the identifier select mechanism. While directed identity requires identifier select, and sometimes is indeed used to refer to identifier select, the two terms are distinct. See this article. Directed identity cannot be detected.

A directed identifier is an opaque identifier which is unique for a given site. The same OpenID URL is continually returned to a given consuming site, but no two consuming sites are ever given the same OpenID URL for a user. Directed identity protects against collusion.

ORIGINAL

I don't get why you linked to "5.1. Direct Communication" in the OpenID spec. As I understand it, "directed identity" is when the OpenID provider guides the user through selecting an identifier which they can use to identify themselves (see here under "Directed Identity").

For instance, to identify with your google account, you don't directly give the relaying party the identifier you claim to own (though you can), you give

https://www.google.com/accounts/o8/id

and then Google generates an anonymous identifier specific to the OP, like

www.google.com/accounts/o8/id?id=aitodwer

which is the actual claimed identifier.

The OpenID provider does not "require" directed identity, but it may not support it. What determines whether directed identify will be used or not is whether the user enters an identifier he claims he owns or enters a provider URL. Although the provider may not support directed identity, it always supports the non-directed kind, even if, as in the case of Google, you cannot know a priori what your claimed identifier will be (Google generates one per Relaying Party). This is because the Relaying Party must be able to perform discovery on the claimed identifier (and maybe perform direct verification if the relaying party is stateless). (well, it's technically possible the provider would forbid authentication requests without identifier_select, but I don't think any does that)

You can easily detect this is happening. The user enters the "user supplied identifier" to the relaying party. After it performs discovery on that identifier, the relaying party will either have:

• The provider endpoint URL and protocol version only ("Directed Identity"). In this case, the relaying party will use the special value http://specs.openid.net/auth/2.0/identifier_select as both the claimed and the OP-local identifier.
• The provider endpoint URL, the protocol version, the claimed identifier (the identifier the user supplied) and the OP-local identifier (the OP-local identifier is an identifier that's specific to a certain endpoint – for instance, I could set up www.mydomain.com to result in the discovery of several OpenID providers, each one with a different OP-local identifier)

Here's how the XML will look in both cases:

Directed identity (example from Google – note the inexistence of an LocalId element)

<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)">
    <XRD>
        <Service priority="0">
            <Type>http://specs.openid.net/auth/2.0/server&lt;/Type&gt;
            <Type>http://openid.net/srv/ax/1.0&lt;/Type&gt;
            <Type>http://specs.openid.net/extensions/ui/1.0/mode/popup&lt;/Type&gt;
            <Type>http://specs.openid.net/extensions/ui/1.0/icon&lt;/Type&gt;
            <Type>http://specs.openid.net/extensions/pape/1.0&lt;/Type&gt;
            <URI>https://www.google.com/accounts/o8/ud&lt;/URI&gt;
        </Service>
    </XRD>
</xrds:XRDS>

Non-directed identity (example from the spec)

<Service xmlns="xri://$xrd*($v*2.0)">
  <Type>http://specs.openid.net/auth/2.0/signon&lt;/Type&gt;
  <URI>https://www.exampleprovider.com/endpoint/&lt;/URI&gt;
  <LocalID>https://exampleuser.exampleprovider.com/&lt;/LocalID&gt;
</Service>

Note that directed identity has the disadvantage that the Relaying Party must verify the claimed identifier in the assertion, making necessary one more discovery (see here).