URL relationship permanence

[Xageroth Sekarius]

That may be true that it's not your problem what consumers choose to
do with OpenID users. Tho, if OpenID is intended to solve specific
problems, it should state so, and if it intentionally does not solve
others, it should state that as well and warn consumers to take
caution.

The issue, imho, would be easily (?) resolved (tho require what
someone mentioned before as heading more into identity management) by
using an internall UUID for every one-to-one, user to service,
interaction.

"http://*.somethingwonderful.com/" asks for
"http://zack-morris.com/"'s UUID and gets "999"
"http://*.acslater.com/" asks for "http://zack-morris.com/"'s UUID and
gets "555"

Each time those services ask for the users UUID they'll get those
numbers and internally they can assign properties to that. If
zack-morris.com ever changes hands the only way identity would be
stolen would be if access to those UUID's was also stolen. Next time
around:

"http://*.somethingwonderful.com/" asks for
"http://zack-morris.com/"'s UUID and gets "444"
Somethingwonderful checks internally and doesn't see a user matching
that UUID. The URL is purely a vanity at that point refering to a
system of internal machine-usable codes.

It's not a flawless solution, obviously, and requires a lot on the
part of identity host but that's my knee jerk solution.

On 6/30/05, VampWillow <tech at vampwillow.com> wrote:
> 
> > Really, that's misleading. OpenID does not prove I have ownership it
> > can only prove I had authority at least one point in time to modify
> > data at a URL for making assertions.
> 
> OpenID shows you are that URL at the point you say you are that URL. No
> more, no less. Taking the LJ implementation as an example, you are asked
> whether you want to authorise the relationship "just this time" or
> "permanently", and I would argue only the first of these is a reasonable
> use of OpenID (for some of your reasons, but also for others). There is
> clearly an issue though with what servers might presume from being given
> someone's OpenID URL but that isn't *neccessarily* OpenID's problem ...
> 
> > LID gets
> > around this problem by being the server as well and therefore the
> > assertions from the URL endpoint and assertions by the server are the
> > same.
> 
> The point of OpenID though is to remove that SPF. LID appears to be, in
> part, solving a different problem ...
> 
> Alison
>