URL relationship permanence

[Benjamin Yu]

Here's an idea to chew on...

Subject - A grouping of related information for a single entity, such as a
person.
Principal - One view of the subject.
Credentials - Additional security related attributes used for authentication.

I would imagine that the OpenID URL is both a Principal and Credential (As it
is used in tandem with the OpenID authentication protocol). This Principal
identifies the end user (Subject) the same way a drivers license (Principal)
and SSN (Principal) would.

Also, there is no limit to the number of OpenID URLs can be used by a single
person, as stated in earlier threads. Zack can have both
http://zackmorris.livejournal.com/ and http://zack-morris.com/

Consumers could provide Zack Morris the ability to link
http://zackmorris.livejournal.com/ to http://zack-morris.com/. This is indirect
since they're both really linked to a Subject created when Zack first used
http://zack-morris.com/.

Zack can then unlink http://zack-morris.com/ after he loses the domain.

I like Meepbear's idea of the local username (Principal). Either way, these
Principals must be created prior to losing the domain. And either way, it's up
to the service providers to support this function.

The drawbacks I see:
1. The Consuming application must provide this link/unlink support.
2. The "Linking" (Additional OpenIDs or Local Username) must be done prior to
losing the domain.

Besides this possible solution, I concur with Meepbear that the burden
falls on the individual to maintain his identity.

I would also add that the above is outside of the scope of what OpenID really
is meant to address. The above is Identity Management, OpenID is about
Authentication.

-Ben

--- Dro Kulix <dro at drocore.com> wrote:

> I can't deny that there's a point, though.  The way I see it, a major
> purpose of OpenID is to be able to leave comments on other community sites
> without becoming a user.  My personal site, for example, runs exactly one
> journal, and to ask for an OpenID for the ability to leave a comment seems
> reasonable, but to ask for a sign-up seems decidedly unreasonable (my
> journal isn't _that_ good).  So, in cases where only an OpenID (and no
> user account) is involved, the spec is perhaps a bit looser than we would
> like.
> 
> I would venture that getting signatures into the spec fairly soon would be
> a good start, but this is an issue that merits more thought.
> 
> -- Dro
> 
> > This is my understanding of the whole thing, so don't pay too much
> > attention
> > to it as I might be completely off the mark :).
> >
> > OpenID doesn't strictly confirm identity; it confirms ownership which is
> > something that we tend to identify with identity. In reality at any point
> > in
> > time whoever owned something yesterday isn't necessarily still the owner
> > of
> > it today.
> >
> > The closest analogy I can think of is your mailing address (e-mail address
> > works fine too). It is yours and yours alone, but only for as long as you
> > still live there. If you moved out and I move in right away, I can take on
> > your 'identity' to whomever considers your mailing address to be you.
> >
> > My point is that the burden of maintaining your 'identity' falls on you.
> > If
> > Zack's domain gets compromised or he looses his ownership of it then it's
> > his responsability to inform all the involved parties of that fact.
> > The sites in question would then simply add his old OpenID URL to the list
> > of URLs it will not accept as identity, preventing anyone from
> > impersonating
> > him.
> >
> > Another approach is mapping an OpenID URL to a local username. In this
> > case
> > Zack would have both his OpenID URL and a local account at the message
> > board. He can use his OpenID URL as his crendentials to post or administer
> > (which the site would map to his board username) but if his OpenID URL
> > should become compromised he simply logs into the board the
> > "old-fashioned"
> > way and removes the mapping of his old OpenID URL to his username, once
> > again preventing impersonation.
> > In this case the local account has a much higher trust factor than a valid
> > OpenID assertion so you would restrict things like password changes to
> > require a local login.
> >
> >
> >
> 
> 
>