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
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: Editors Conference Call
Thanks David! ;-) Patrick, as you point out, Identity Provider is a well understood term in SAML and WS-*. Here is the definition from SAML 2.0 [1] Identity Provider: A kind of service provider that creates, maintains, and manages identity information for principals and provides principal authentication to other service providers within a federation, such as with web browser profiles. Per the definition, Identity Provider implies a federation or trust relationship between the IdP and RP. Additionally, IdPs often provide other assertions about the user. In OpenID Authentication, there is no trust relationship requirement between the IdP and RP, and the only thing the IdP asserts is a binding between the user and an identifier (OpenID URL or i-name). As people familiar with SAML / WS-* review the OpenID Authentication specification, there has been some confusion on exactly what the IdP does in OpenID. To make it clear that an IdP in OpenID is not the same as typical deployments in SAML, we decided to call it the OpenID Provider, which is more precise, and reduces ambiguity. -- Dick [1] http://www.oasis-open.org/committees/download.php/11886/saml- glossary-2.0-os.pdf On 30-Oct-06, at 10:27 PM, Recordon, David wrote: I'll let Dick explain since it was his proposal and I didn't really care about if we changed the name or not. ;) --David From: Patrick Harding [mailto:[EMAIL PROTECTED] Sent: Monday, October 30, 2006 7:47 PM To: Recordon, David; specs@openid.net Subject: RE: Editors Conference Call Dave, Can you please clarify how an OpenID Provider is 'very' different from the role of Identity Provider as defined in SAML or WS-*. Thanks - Patrick Rename Identity Provider to OpenID Provider (IdP - OP) to add clarity to the term since IdP has a very different meaning in the SAML and WS-* worlds -Original Message- From: [EMAIL PROTECTED] on behalf of Recordon, David Sent: Mon 10/30/2006 7:51 PM To: specs@openid.net Subject: Editors Conference Call This morning Dick, Josh, and I got on Skype for 2.5 hours to try and hash through all the remaining proposals. Unfortunately Brad couldn't join us, though I did talk to him about some of this stuff as well beforehand. - Authentication Age will be developed as an extension due to questions around what is the best way for it to work, what features does it need, etc - The field setup_url will be removed from a checkid_immediate response, rather the RP should fallback to a checkid_setup request to complete the transaction. It has been found that in the, albeit few, implementations of checkid_immediate this is the behavior for the setup_url anyway. - Support bare requests by having the field openid.return_to as optional in checkid_* requests. There is a worry of user's not knowing when they'll be redirected back and when they won't, though that will only be worked out by allowing this functionality. - Clarify that the openid.realm parameter should be used to uniquely identifier relying parties - There are some places where it could be clear in step-by-step instructions of what an IdP needs to do in various parts of the protocol, like is done in section 12 for rp's. Sxip will provide pointers to where this clarity can be added. - Rename Identity Provider to OpenID Provider (IdP - OP) to add clarity to the term since IdP has a very different meaning in the SAML and WS-* worlds - The spec won't speak to what a RP should do if it has an identifier like [EMAIL PROTECTED], worried about setting a confusing precedent of allowing this form of identifier for discovery. Users are used to entering, example.com in their URL bar to goto the site, so entering the same to login doesn't seem like to far of a stretch. All of OpenID has a user education challenge and this doesn't seem very different. - Spec will say in essence, RP's SHOULD give the text field a user enters their OpenID Identifier a name attribute with a value of 'openid_identifier', though if a RP wishes to support rich clients it MUST do so. - Dick will be writing a separate document discussing how RPs can advertise services, logos, etc - There cannot be parameters with the same name, make sure spec says this, we think it does. - Josh will be updating his delegation proposal patch to specify two identifiers for all transactions. This will create a consistent paradigm when dealing with delegation or when not. Goal is to have all of these changes made by end of day Wednesday. I doubt I've added enough detail in all places, so feel free to ask for clarifications or wait to comment on the next draft. --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ 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: Editors Conference Call
Hi Dick, It would be nice to see a clear definition of an OP in order to determine the exact differences between such an entity and an IdP, but, in the absence of such, some questions: Dick Hardt wrote: Thanks David! ;-) Patrick, as you point out, Identity Provider is a well understood term in SAML and WS-*. Here is the definition from SAML 2.0 [1] Identity Provider: A kind of service provider that creates, maintains, and manages identity information for principals and provides principal authentication to other service providers within a federation, such as with web browser profiles. Per the definition, Identity Provider implies a federation or trust relationship between the IdP and RP. And I guess there is no similar concept in OpenID? Like perhaps an RP adds a particular (I hate to use the word) trusted IdP to a whitelist of IdPs from whom it accepts assertions? Or vice-versa? Admittedly, such federations might not be as linked to static business agreements perhaps as in a typical SAML deployment, but it seems they would be necessary unless you base trust on public key-based mechanisms, or decide that you'll accept assertions from no-password.com (to quote from a discussion on [EMAIL PROTECTED]) and anyone else. I suspect the latter case will be unlikely, if OpenID is to be successful. Additionally, IdPs often provide other assertions about the user. This is sometimes called attribute exchange. In OpenID, is it then not possible for an OP to exchange attributes related to a particular OpenID with an RP? There seems to be an attribute exchange specification (http://openid.net/specs/openid-attribute-exchange-1_0-02.html) where it says (for example, in section 2) Fetch retrieves attribute information from an Identity Provider, while store saves or updates attribute information on the Identity Provider.. In OpenID Authentication, there is no trust relationship requirement between the IdP and RP., and the only thing the IdP asserts is a binding between the user and an identifier (OpenID URL or i-name). And on what basis does the OP assert this binding to an RP? Doesn't the OP typically authenticate that binding, or does it simply take the users identifier on blind faith, and assert away? As people familiar with SAML / WS-* review the OpenID Authentication specification, there has been some confusion on exactly what the IdP does in OpenID. To make it clear that an IdP in OpenID is not the same as typical deployments in SAML, we decided to call it the OpenID Provider, which is more precise, and reduces ambiguity. I guess until we see this precise definition, we won't be able to see the precise differences. From what I can tell so far, it seems to me that the differences between an OP and an IdP are not significant. - John -- Dick [1] http://www.oasis-open.org/committees/download.php/11886/saml- glossary-2.0-os.pdf On 30-Oct-06, at 10:27 PM, Recordon, David wrote: I'll let Dick explain since it was his proposal and I didn't really care about if we changed the name or not. ;) --David From: Patrick Harding [mailto:[EMAIL PROTECTED] Sent: Monday, October 30, 2006 7:47 PM To: Recordon, David; specs@openid.net Subject: RE: Editors Conference Call Dave, Can you please clarify how an OpenID Provider is 'very' different from the role of Identity Provider as defined in SAML or WS-*. Thanks - Patrick Rename Identity Provider to OpenID Provider (IdP - OP) to add clarity to the term since IdP has a very different meaning in the SAML and WS-* worlds -Original Message- From: [EMAIL PROTECTED] on behalf of Recordon, David Sent: Mon 10/30/2006 7:51 PM To: specs@openid.net Subject: Editors Conference Call This morning Dick, Josh, and I got on Skype for 2.5 hours to try and hash through all the remaining proposals. Unfortunately Brad couldn't join us, though I did talk to him about some of this stuff as well beforehand. - Authentication Age will be developed as an extension due to questions around what is the best way for it to work, what features does it need, etc - The field setup_url will be removed from a checkid_immediate response, rather the RP should fallback to a checkid_setup request to complete the transaction. It has been found that in the, albeit few, implementations of checkid_immediate this is the behavior for the setup_url anyway. - Support bare requests by having the field openid.return_to as optional in checkid_* requests. There is a worry of user's not knowing when they'll be redirected back and when they won't, though that will only be worked out by allowing this functionality. - Clarify that the openid.realm parameter should be used to uniquely identifier relying parties - There are some places where it could be clear in step-by-step instructions of what an IdP needs to do in various parts of the protocol, like is done in section 12 for rp's. Sxip will
Re: Editors Conference Call
Dick Hardt wrote: It would be nice to see a clear definition of an OP in order to determine the exact differences between such an entity and an IdP, but, in the absence of such, some questions: Dick Hardt wrote: Thanks David! ;-) Patrick, as you point out, Identity Provider is a well understood term in SAML and WS-*. Here is the definition from SAML 2.0 [1] Identity Provider: A kind of service provider that creates, maintains, and manages identity information for principals and provides principal authentication to other service providers within a federation, such as with web browser profiles. Per the definition, Identity Provider implies a federation or trust relationship between the IdP and RP. And I guess there is no similar concept in OpenID? Like perhaps an RP adds a particular (I hate to use the word) trusted IdP to a whitelist of IdPs from whom it accepts assertions? Or vice-versa? Is it technically possible? OK. Just checking. So an IdP/OP can choose whether or not to trust a particular RP, based on some out-of-ban criteria. And an RP can choose whether or not to trust the assertions of a particular IdP/OP? OK good. Yes. Just like it is technically possible for SAML to be user-centric. :-) Admittedly, such federations might not be as linked to static business agreements perhaps as in a typical SAML deployment, but it seems they would be necessary unless you base trust on public key-based mechanisms, or decide that you'll accept assertions from no-password.com (to quote from a discussion on [EMAIL PROTECTED]) and anyone else. I have not had a chance to wade into that discussion. I'd highly recommend it when you get the chance. I suspect the latter case will be unlikely, if OpenID is to be successful. And I do not. And that is the big driver why it should be OP instead of IdP. I think what you're trying to say is that OpenID won't depend on static trust relationships (like business contracts) between RPs and IdP/OPs - is that right? In which case, sure, I get that. But I do think OpenID will depend on there emerging a way of some RP trusting (or not) some IdP (and vice-versa). Whitelists and blacklists seem like a scalable and dynamic way of doing that, and would seem to be a reasonable way of minimizing the presence of rogue IdPs. Don't take my word for it though - look at the discussion on [EMAIL PROTECTED] Additionally, IdPs often provide other assertions about the user. This is sometimes called attribute exchange. In OpenID, is it then not possible for an OP to exchange attributes related to a particular OpenID with an RP? There seems to be an attribute exchange specification (http://openid.net/specs/openid-attribute-exchange-1_0-02.html) where it says (for example, in section 2) Fetch retrieves attribute information from an Identity Provider, while store saves or updates attribute information on the Identity Provider.. When I talk about assertions, I mean third party claims, not self asserted data. The OP is not verifying the accuracy of any of the attributes in attribute exchange. A claim by my IdP/OP /might/ be a claim by a third-party, no? And if the IdP/OP makes such a claim on my behalf (and is not under my direct control), won't it at least want to verify that the subject of the claim is also the user whose identifier it asserted in OpenID Authentication? In OpenID Authentication, there is no trust relationship requirement between the IdP and RP., and the only thing the IdP asserts is a binding between the user and an identifier (OpenID URL or i-name). And on what basis does the OP assert this binding to an RP? Doesn't the OP typically authenticate that binding, or does it simply take the users identifier on blind faith, and assert away? The OP authenticates the user (how the OP authenticates the user is out of scope of the spec). OK - so the user probably maintains an account with the OP, very much like a user would with an IdP? Unless the user runs her own OP. As people familiar with SAML / WS-* review the OpenID Authentication specification, there has been some confusion on exactly what the IdP does in OpenID. To make it clear that an IdP in OpenID is not the same as typical deployments in SAML, we decided to call it the OpenID Provider, which is more precise, and reduces ambiguity. I guess until we see this precise definition, we won't be able to see the precise differences. How about: An OpenID Provider acts on behalf of the user in responding to OpenID Authentication requests from a Relying Party. What more do we need in the spec then that? What about: An OpenID Identity Provider acts on behalf of the user in responding to OpenID Authentication requests from a Relying Party.? I guess you might want to add something about such an entity typically authenticating the binding between an OpenID and some subject/principal/user. - John
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
