Thanks for researching the cause of the failure and communicating with the OP already. That should make things much quicker. The OP operator has an incorrectly configured OP. From the OpenID 2.0 spec section 11.2, we read:
If the Claimed Identifier is included in the assertion, it MUST have
been discovered by the Relying Party and the information in the
assertion MUST be present in the discovered information. The Claimed
Identifier MUST NOT be an OP Identifier.
From the last sentence, we get that the "static" XRDS that is returned from the user identifier must not be an OP Identifier, yet it is, and from elsewhere in the spec we learn that OP Identifiers take precedence over user identifiers (which is why being an OP Identifier is forbidden here). The OP should fix the XRDS document they return from user identifiers to omit the OP Identifier service endpoint.
Please forward the above to any faulty OP and ask them to correct their error.
The following is not supported, nor advised, as it causes your relying party to stray from the OpenID 2.0 spec, violating a "MUST NOT" clause, and it may introduce security holes in your application:
There is a way to configure a DotNetOpenAuth relying party to work even for these faulty OPs, the aforementioned disclaimer applies to this method. Add this snippet to your web.config file:
<dotNetOpenAuth>
<openid>
<relyingParty>
<security allowDualPurposeIdentifiers="true" />
</relyingParty>
</openid>
</dotNetOpenAuth>
If you used NuGet to install DotNetOpenAuth in your web application, that should be sufficient. But if you get errors about any of these tags not being recognized, you may need to merge this at the top of your web.config file:
<configuration>
<configSections>
<section name="dotNetOpenAuth" type="DotNetOpenAuth.Configuration.DotNetOpenAuthSection" requirePermission="false" allowLocation="true"/>
</configSections>
</configuration>