Re: Making identities persistent?
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 us
RE: Making identities persistent?
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
Re: Making identities persistent?
On Wed, 2006-11-01 at 11:33 -0500, John Kemp wrote: 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. Isn't this was already covered in the spec? You accomplish this by creating an HTML page on some website you control with a http-equiv meta tag in it that points to your IdP. Then you use your own url as your Identity, even though ultimately the data is pulled from the IdP. So if you ever want to change IdP's you simply update your html page with the new server. And your Identifier never needs to change. 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?) Is there anything against an IdP implementing the delegate feature to forward to a different server? -Rowan ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Making identities persistent?
I'm afraid I still don't get it. As far as I am concerned the authenticated identifier is the tuple: (Identity-provider-Id, Identifier) If we want to have a single identifier there has to be a mechanism for establishing the scope of authority for each IdP over a specific subset of identifiers. There are only two potential mechanisms I can see for achieving this: 1) A lexigraphical convention 2) A signalling registry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete Rowley Sent: Wednesday, November 01, 2006 1:53 PM To: Rowan Kerr Cc: specs@openid.net Subject: Re: Making identities persistent? Rowan Kerr wrote: On Wed, 2006-11-01 at 11:33 -0500, John Kemp wrote: 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. Isn't this was already covered in the spec? You accomplish this by creating an HTML page on some website you control with a http-equiv meta tag in it that points to your IdP. Then you use your own url as your Identity, even though ultimately the data is pulled from the IdP. So if you ever want to change IdP's you simply update your html page with the new server. And your Identifier never needs to change. Except that the spec specifies that it is the derived identifier of the IdP that is used at the RP - which means a delegated identifier actually isn't used as an identifier. That is not quite the same thing. -- Pete ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Making identities persistent?
Pete, While the transaction with the IdP is about the derived identifier (sort of like that term actually), the RP uses the delegated identifier when referencing the user. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete Rowley Sent: Wednesday, November 01, 2006 10:53 AM To: Rowan Kerr Cc: specs@openid.net Subject: Re: Making identities persistent? Rowan Kerr wrote: On Wed, 2006-11-01 at 11:33 -0500, John Kemp wrote: 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. Isn't this was already covered in the spec? You accomplish this by creating an HTML page on some website you control with a http-equiv meta tag in it that points to your IdP. Then you use your own url as your Identity, even though ultimately the data is pulled from the IdP. So if you ever want to change IdP's you simply update your html page with the new server. And your Identifier never needs to change. Except that the spec specifies that it is the derived identifier of the IdP that is used at the RP - which means a delegated identifier actually isn't used as an identifier. That is not quite the same thing. -- Pete ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Making identities persistent?
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] 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#anchor48 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 http://openid.net/mailman/listinfo/specs
Re: Making identities persistent?
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]: 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] 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#anchor48 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 http://openid.net/mailman/listinfo/specs ___specs mailing listspecs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
