OpenID feature coverage
SourceForge.net is an OpenID relying party. We've prepared this page to provide details on our OpenID implementation.
Delegation OpenIDs
Unfortunately, the SourceForge.net ZF OpenID client does not yet support XRDS or Yadis-based discovery. This is being addressed with ZF.
Users can add HTML discovery elements to their delegation page to work for SourceForge.net.
This is a delegation block for Verisign, verified to work with the existing SourceForge.net implementation:
<link rel="openid.server" href="http://pip.verisignlabs.com/server" /> <link rel="openid.delegate" href="http://username.pip.verisignlabs.com/" /> <link rel="openid2.provider" href="http://pip.verisignlabs.com/server" /> <link rel="openid2.local_id" href="http://username.pip.verisignlabs.com/" />
i-name support
The SourceForge.net ZF OpenID component doesn't fully support XRI & i-name discovery at this time. An issue has been filed in the ZF tracker.
Field prepopulation
During account registration, the number of fields that can be pre-populated is dependent on the ID provider. In some cases we are unable to prepopulate the full set of fields in our registration form.
It might be that all of the fields weren't completed, or the id provider doesn't account for everything (e.g., time zone, language, country, etc.). If these things are not correct, that means the ID providers are not adhering to the specification (registration extension: http://openid.net/specs/openid-simple-registration-extension-1_0.html).
http vs. https
SourceForge.net follows the specification on this, i.e., normalization: http://openid.net/specs/openid-authentication-2_0.html#normalization_example. Hence, an http OpenID is different than an https OpenID. If the selected provider offers both, SourceForge.net suggests using https. Both may be used, but SourceForge.net considers them as two separate OpenIDs.
