views:

66

answers:

1

I am using the JanRain library, and implementing code very similar to their server example (essentially creating my own openid provider). I have it working, but when I try to return an identity different from the one specified to the consumer, I get the following error:

Request was for http://example.com/, cannot reply with identity http://example.com/openid/33

In this case, the unique ID/URL is http://example.com/openid/33, while the one specified to the consumer is http://example.com.

I am using something like this:

$request  =  $server->decodeRequest();
$request->answer( true, null,  $id_url, $request->identity );

I've tried switching around $request->identity and $id_url. I only get the error in the state shown above, and the other state works, but doesn't seem to return the right thing to the consumer. I'm using the OP Simple Registration test found here: http://test-id.org/OP/Sreg.aspx, and when I switch them it works, but I can't find my $id_url anywhere in the logs.

My guess is that I need to be telling the consumer something earlier in the process about the ID differing from the one specified by the end-user, but so far I haven't hit on the right thing to try. I know this is possible, because this is how yahoo's OpenID works.

Any ideas or suggestions are welcome. Thanks!

+2  A: 

You are confusing the endpoint URL with the claimed identifier or the OP-local identifier.

The workflow is like this:

  • User enters a user supplied identifier
  • Consumer performs discovery on it and and then it will either have:
    • The provider endpoint URL/version. In this case, the claimed identifier/op-local identifier will be http://specs.openid.net/auth/2.0/identifier_select
    • The provider endpoint URL, the protocol version, the claimed identifier (the identifier the user supplied) and the OP-local identifier

So you should only provide a new identifier if you got http://specs.openid.net/auth/2.0/identifier_select.

Artefacto
So in my case, the endpoint is at `http://example.com/openid`, and I've been specifying that with `<link rel="openid2.provider openid.server" href="http://example.com/openid/"/>`. Should I also be putting `<link rel="openid2.local_id openid.delegate" href="http://specs.openid.net/auth/2.0/identifier_select" />` on that page? I'll try that now. (And should I also replace that with the actual identifier if it is known? IE, if my user is logged in already?)
livingtech
@livin You can't do it that way. OpenID 2.0 spec, secion 7.3.3 "HTML-Based discovery is only usable for discovery of Claimed Identifiers.". You have to use XRDS.
Artefacto
@Artefacto Hmmm... I'm already writing out a header that points to a very simple (static) XRDS document with a `<Service>` tag, containing only `<TYPE>` and `<URI>` tags in it. If I add `<LocalID>http://specs.openid.net/auth/2.0/identifier_select</LocalID>` to that document, will that work? Is there any point (after discovery) where the XRDS is used and should be different? Thank you for all your help, btw.
livingtech
@livingtech: No, it won't work. You shouldn't specify LocalID at all, just use `http://specs.openid.net/auth/2.0/server` instead of `http://specs.openid.net/auth/2.0/signon` in the `<Type>` tag. See section 7.3.2.1 of the specification for details.
Mewp
Thanks @Mewp, it does seem like I was specifying the wrong thing there, but I'm STILL getting my original error. `Request was for http://example.com/, cannot reply with identity http://example.com/openid/33`
livingtech
@livingtech: are you sure that you have configured the library to use `identifier_select` ? (which I have no idea how to do with that library)
Mewp
@Mewp, I'm definitely NOT sure. It appears (looking through the library code), that I should not be getting this error if the request is specifying `http://specs.openid.net/auth/2.0/identifier_select`, so somehow the consumer request has `http://example.com` as the identifier specified in it. I guess the question becomes... is this my fault somehow?
livingtech
@livingtech: When an RP encounters an XRDS document with `<Type>http://specs.openid.net/auth/2.0/server</Type>`, it should send both `claimed_id` and `identity` set to `http://specs.openid.net/auth/2.0/identifier_select`. If it's set to `http://example.com`, then there may be a problem during discovery. Perhaps you haven't properly defined X-XRDS-Location, and the RP has fallen back to HTML discovery?
Mewp
This is useful info, thanks. Here is my XRDS doc: `<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)"><XRD><Service priority="0"><Type>https://specs.openid.net/auth/2.0/server</Type><URI>http://example.com/openid</URI></Service></XRD></xrds:XRDS>` (Sorry about the formatting...) Does it look okay to you? Another question: My base domain doesn't actually print the XRDS header. Only my endpoint does that (`http://example.com/openid`) ...is it too late at that point? (This could have been my problem all along.)
livingtech
Doesn't seem to have been my problem, since I tried just using my endpoint as the claimed-id, and still get the error.
livingtech
@livingtech: Yes, you have to include the header on the main site -- otherwise, how would the RP know where the XRDS document is? The document itself looks fine to me. Try removing the html tags so that html discovery can't be performed -- then you'll see if the XRDS document is found and read by the RP.
Mewp
accepting this answer even though my original issue is still unsolved. Thanks for all the help everyone.
livingtech