I believe it's possible to prevent impersonation for the use case where
the user instructs their IdP (OP) to inform the RP of the identifier
change. However, this will only work
if the RP remembers the IdP that last authenticated that OpenID
identifier and only allows this message from that IdP.
Thanks,
George
P.S. Functionally, this seems similar to the SAML ManageNameIDRequest
message.
Hallam-Baker, Phillip wrote:
Don't forget that the a more important constraint here is to prevent impersonation.
I don't see how one can switch between genuinely autonamous IdPs in the way suggested without allowing a rogue IdP to impersonate anyone they chose.
At what point do the synchronization mechanisms you build in exceed the complexity of PKI?
-----Original Message-----
From: John Kemp [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 01, 2006 11:33 AM
To: Hallam-Baker, Phillip
Cc: Stefan Görling; Shutra Zhou; specs@openid.net
Subject: Re: Making identities persistent?
Hello,
I think you need the ability for a user to change his
identifier at the RP (as George notes below) and also at the
IdP. In addition, it should be possible for the IdP to
providing OpenID "forwarding" if the user leaves for another
IdP (perhaps the user will even pay for a forwarding
service?)
We're not talking about persistence as such (a particular
users OpenID can surely change over time?), but more the
ability for the user to update her OpenID when she switches
from one IdP to another. At the IdP, this would I guess be
kind of like leaving a forwarding address, as the user is
"leaving" one IdP and moving to another. At the RP, the user
is telling the RP that he is using a new IdP.
So, I think George's (1) is a necessity, and agree that (2)
is a business decision, but certainly offers the ability for
an IdP to be "community-friendly" if it so wishes, and may
even be a good business decision.
Isn't this all about the likely /lack/ of persistence in a
particular OpenID though?
Regards,
- John
Hallam-Baker, Phillip wrote:
If we want identities to be persistent then we are going to need to
introduce a layer of indirection.
This normally gets me worried about patents and such. Fortunately
Multics did this, so did UNIX and VMS. Plenty of prior art.
If we are serious about decentralization then map the user
identifier
onto a randomly assigned machine readable GUID.
-----Original Message----- From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Stefan Görling Sent:
Wednesday, November 01, 2006 10:52 AM To: Shutra Zhou Cc:
specs@openid.net Subject: Re: Making identities persistent?
The reasons for raising this question was partly that I've
been doing
some research on how people use e-mail addresses and sad
to say, you
can not expect the user to make wise choices. And even so,
companies
go broke even the best ones. Services comes and disappear. In my
research over half of the population use non-portable e-mail
addresses tied to an employer, university, etc.
and is likely to only live a few years.
E-mail is not a stable address/identity identifier. We
must not rely
on it as such.
If we want an identity to be persistent, it must contain a
migration
feature, so that I can move all their trust relations from
one place
to another. This of course creates a number of other
issues such as
security and complexibility, but it is my sincere belief that the
issue should be addressed by the system and not only
delegated to be
dependent on wise user decisions.
Therefore, my +1 is on (1) below. I will try to read back
on what has
been said in the past on a 'change identifier' extension
and see if
there is anything I can do to help.
/Stefan
Yes, this is important thing I thought. We should privide a
spec for
the consumer to change their end user's OpenID URL,
optionally the end
user can use multiple OpenIDs in this consuemr. And this
case can be
expended as this, the IdP（OpenID Server） is closed down.
2006/10/31, George Fletcher <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
This is a good use case and I think important for both users and
IdPs (now OPs [OpenID Provider] per the latest "editor's
conference") to consider.
I see a number of options...
1. There has been some discussion regarding a "change
identifier"
extension that would allow you to change your identifier at the
relying party. This would solve the use case and is necessary
regardless of the other options.
2. The OP (in this case AOL.com) could continue to provide an
"identifier management" page that would allow the user
to specify
the OP of choice. This requires the OP to continue to serve the
XRDS doc or at least the indirection to a XRDS doc with
the new OP.
This is not that much extra overhead for the OP,
but it will
likely be a business decision as to whether to support
such a feature.
3. The user gets to choose their OP so they can ensure that they
don't get "locked in". This is the ideal behind user-centric.
However, in practice, it will take good education and
time for users
to understand the ramifications of their decisions.
Thanks, George
Stefan Görling wrote:
Hi everybody,
I'm trying to get a grip around your great work and have
one issue
that I'm not quite clear on, relevant to the discussion of using
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
identifiers, but also in a more general context.
Please let me know if I've simply missunderstood my own question.
http://openid.net/specs/openid-authentication-2_0-09.html#an
chor48 says:
"OpenID is decentralized. No central authority must approve or
register Relying Parties or Identity Providers. An End User
can freely
choose
which Identity Provider to use. They can preserve their
Identifier if
they switch Identity Providers."
Let us consider the case that I'm an AOL.com customer, and
they act as
an IdP providing we with an identifier. I use this
identifier for 3
years for identity management on most of the services I
use, due to
the huge success of the standard... However, I'm starting
to get fed
up with AOL and terminates my agreement with them. Is there any
procedure for me
to switch to another IdP? How is this done?
Best Regards,
Stefan Görling
_______________________________________________ specs
mailing list
specs@openid.net <mailto:specs@openid.net>
http://openid.net/mailman/listinfo/specs
_______________________________________________ specs
mailing list
specs@openid.net <mailto:specs@openid.net>
http://openid.net/mailman/listinfo/specs
_______________________________________________ specs mailing list
specs@openid.net http://openid.net/mailman/listinfo/specs
_______________________________________________ specs mailing list
specs@openid.net http://openid.net/mailman/listinfo/specs
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
|
