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

[Drummond Reed]

> On Thursday, March 13, 2008 4:29 AM, Noah Slater wrote:
> 
> > 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 none 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?

Noah, as Eddy points out, if you consider this a problem, you can fix this
by instructing your OP to return <http://bytesexual.org/> as your
claimed_id. Since that was the original URL upon which OpenID discovery was
performed, this will meet the verification test that the RP is required to
perform if the OP returns a different claimed_id than the one the RP
submitted.

I continue to believe that when you say, " All this talk of XRIs, URNs and
URLs is beside the point...", you are missing the point that, when it comes
to identifying a real-world user, OpenID is dealing with a level of abstract
identifiers that operate on top of the layer of concrete identifiers used at
the HTTP protocol level. The fact that you can fix the problem you described
by instructing your OP to assert a different identifier than the one your RP
is ultimately redirected to is an example of how synonyms at the abstract
identifier level do not necessarily reflect redirects or other semantics at
the HTTP level.

BTW, John Bradley reminded me yesterday that when a URL is used as a OpenID
identifier, it can be BOTH an abstract identifier (of the user) and a
concrete identifier of some web resource (such as the user's blog or home
page). By contrast, when an XRI is used as an OpenID identifier, it is
always an abstract identifier for a resource, and must be resolved to one or
more concrete identifiers for specific representations of that resource.

=Drummond