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

[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?

Thanks,

--
Noah Slater <http://bytesexual.org/>