[OpenID] Calling OpenID 2.0 editors (wasRE:ProblemswithOpenIDand TAG httpRange-14)

Thu Mar 13 15:39:29 UTC 2008

Noah Slater:
> On Thu, Mar 13, 2008 at 04:34:22AM +0200, Eddy Nigg (StartCom Ltd.) wrote:
>   
>> By using the param "claimed_id" as the authorized ID, it can confuse
>> some folks. Something like "auth_id" (from authorized ID) or
>> "confirmed_id" or "real_id" or "response_id" could have made it
>> clearer....just not something with the word "claim" in it...I guess this
>> is what happens.
>>     
>
> I am pretty sure I used non of this terminology in my original report.
>
> I will outline my use case using as little OpenID jargon as possible:
>
>    1. Find interesting blog post on <http://example.org/2008/01/plankton/>
>    2. Write comment to the blog post
>    3. Asked to provide OpenID to submit comment
>    4. Input <http://bytesexual.org/>
>    5. Press submit
>    6. The website dereferences my OpenID
>    7. My OpenID URI does a 303 redirect to <http://bytesexual.org/about/>
>    8. <http://bytesexual.org/about/> contains delegation information
>    9. The website delegates and takes me to <http://claimid.net/>
>   10. Authenticate at <http://claimid.net/> which takes me back to the website
>   11. My comment has been posted on the website
>   12. My name on the comment is a link to <http://bytesexual.org/about/>
>   13. ... time passes ...
>   14. Come back to the site, read a new post and want to comment
>   15. The comment form autocompletes my OpenID as <http://bytesexual.org/about/>
>
> Like I have said before, I don't know much about OpenID so I couldn't tell you
> which part of the OpenID stack is causing this problem or why but I do know
> enough about HTTP and URIs to see that there is a problem here.
>
> All this talk of XRIs, URNs and URLs is beside the point. What I consider to be
> my OpenID <http://bytesexual.org/> is a plain old URI and it is dereferencable
> via HTTP yet the semantics of HTTP are being broken as
> <http://bytesexual.org/about/> is explicitly not to be considered a replacement
> URI for the original one requested. It doesn't matter what the OpenID
> specification says, these facts can't be changed and the semantics can't be
> reinterpreted to fit some arbitary security model.
>
> In this specific use case do you still think that OpenID is behaving correctly?
OK, Noah, I think I got it this time around....

If I read and understand correctly, than this is a failure/feature of 
the implementation of your OpenID provider. It might be done by them 
also on purpose. Maybe the RP or OP is following specs 1.1 and not 2.0. 
In the case of the later, the OP should have provided 
http://bytesexual.org/ as your OpenID (at least this is what you believe 
is your OpenID anyway).

However the redirects performed by your OP aren't really relevant in 
this respect. The claimed_id returned by your OP is simply 
http://bytesexual.org/about/ and not http://bytesexual.org/. Guess they 
are the ones you should address then...

-- 
Regards 

Signer:  	Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber:  	startcom at startcom.org <xmpp:startcom at startcom.org>
Blog:  	Join the Revolution! <http://blog.startcom.org>
Phone:  	+1.213.341.0390

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080313/e01ea42d/attachment-0002.htm>