Does an OpenID realm have to be the base URL of th

As a continuation of this question, there's an issue I'm having with dotnetopenauth.

Basically, I'm wondering if the realm specified in the RP has to be the actual base URL of the application? That is, (http://localhost:1903)? Given the existing architecture in place it is difficult to remove the redirect - I tried setting the realm to the base OpenId controller (http://localhost:1903/OpenId) and testing manually did generate the XRDS document. However, the application seems to freeze, and the EP log reveals the following error:

2012-10-10 15:17:46,000 (GMT-4) [24] ERROR DotNetOpenAuth.OpenId - Attribute Exchange extension did not provide any aliases in the if_available or required lists.

Code:

Relying Party:

public ActionResult Authenticate(string RuserName = "")
{
UriBuilder returnToBuilder = new UriBuilder(Request.Url);
returnToBuilder.Path = "/OpenId/Authenticate";
returnToBuilder.Query = null;
returnToBuilder.Fragment = null;

Uri returnTo = returnToBuilder.Uri;
returnToBuilder.Path = "/";
Realm realm = returnToBuilder.Uri;

var response = openid.GetResponse();

if (response == null) {
    if (Request.QueryString["ReturnUrl"] != null && User.Identity.IsAuthenticated) {

    } else {

    string strIdentifier = "http://localhost:3314/User/Identity/" + RuserName;
    var request = openid.CreateRequest(
        strIdentifier,
        realm,
        returnTo);

    var fetchRequest = new FetchRequest();
    request.AddExtension(fetchRequest);
    request.RedirectToProvider();
    }
} else {
    switch (response.Status) {
        case AuthenticationStatus.Canceled:
            break;
        case AuthenticationStatus.Failed:
            break;
        case AuthenticationStatus.Authenticated:
            //log the user in
            break;
    }
}

return new EmptyResult();

}

Provider:

public ActionResult Index()
{
    IRequest request = OpenIdProvider.GetRequest();

    if (request != null) {
        if (request.IsResponseReady) {
            return OpenIdProvider.PrepareResponse(request).AsActionResult();
        }

        ProviderEndpoint.PendingRequest = (IHostProcessedRequest)request;
        return this.ProcessAuthRequest();
    } else {
        //user stumbled on openid endpoint - 404 maybe?
        return new EmptyResult();
    }
 }

public ActionResult ProcessAuthRequest()
    {
        if (ProviderEndpoint.PendingRequest == null) {
            //there is no pending request
            return new EmptyResult();
        }

        ActionResult response;
        if (this.AutoRespondIfPossible(out response)) {
            return response;
        }

        if (ProviderEndpoint.PendingRequest.Immediate) {
            return this.SendAssertion();
        }

        return new EmptyResult();
    }

The answer to your question is "no". The realm can be any URL between the base URL of your site and your return_to URL. So for example, if your return_to URL is http://localhost:1903/OpenId/Authenticate, the following are all valid realms:

http://localhost:1903/OpenId/Authenticate
http://localhost:1903/OpenId/
http://localhost:1903/

The following are not valid realms, given the return_to above:

http://localhost:1903/OpenId/Authenticate/ (extra trailing slash)
http://localhost:1903/openid/ (case sensitive!)
https://localhost:1903/ (scheme change)

Because some OpenID Providers such as Google issue pairwise unique identifiers for their users based on the exact realm URL, it's advisable for your realm to be the base URL to your web site so that it's most stable (redesigning your site won't change it). It's also strongly recommended that if it can be HTTPS that you make it HTTPS as that allows your return_to to be HTTPS and is slightly more secure that way (it mitigates DNS poisoning attacks).

The reason for the error in the log is because your RP creates and adds a FetchRequest extension to the OpenID authentication request, but you haven't initialized the FetchRequest with any actual attributes that you're requesting.

I couldn't tell you why your app freezes though, with the information you've provided.