Re: No New DB Field Requirement? (WAS: RE: Questions about IIW Identifier Recycling Table)
It is more complex having to use two fields to uniquely identify a user in a DB then one. DB queries are more complex and there is more opportunity for the developer to make mistakes. Given a goal of OpenID is to be simple, one field is better then two. -- Dick On 8-Jun-07, at 10:14 AM, Johnny Bufu wrote: On 8-Jun-07, at 10:02 AM, Recordon, David wrote: I'm confused as to why a RP having to not create a new DB field is a requirement when looking to solve this problem. RP's implementations already need to change to upgrade from 1.1 to 2.0 and this has never been a requirement in the past. It certainly is nice that storage changes wouldn't be needed, but I don't see it as something that should be a requirement. My feeling was that, all other things being equal, some bits of code (stripping the fragment for display purposes) which ideally would go into the library, were preferred to requiring a schema change (to store the separate token) for the RPs. Not a requirement, but a strong preference. Johnny ___ 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: No New DB Field Requirement? (WAS: RE: Questions about IIW Identifier Recycling Table)
I agree that all things equal, it is reasonable to look at. I think a lot of this in terms of where stripping versus identifier storage happen depends a lot on the library and application. In Rails for example the library manages the store for associations and nonces, and the application has to modify a table to store the identifier. In the stripping case, you'd then have to create a method in your application for when you call User.identifier which strips the fragment. In the second field case, you'd then have two fields in your database to work with, also from the application level. So just not sure if there really is more or less complexity from this standpoint between the two approaches. --David -Original Message- From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Friday, June 08, 2007 10:15 AM To: Recordon, David Cc: specs@openid.net Subject: Re: No New DB Field Requirement? (WAS: RE: Questions about IIW Identifier Recycling Table) On 8-Jun-07, at 10:02 AM, Recordon, David wrote: I'm confused as to why a RP having to not create a new DB field is a requirement when looking to solve this problem. RP's implementations already need to change to upgrade from 1.1 to 2.0 and this has never been a requirement in the past. It certainly is nice that storage changes wouldn't be needed, but I don't see it as something that should be a requirement. My feeling was that, all other things being equal, some bits of code (stripping the fragment for display purposes) which ideally would go into the library, were preferred to requiring a schema change (to store the separate token) for the RPs. Not a requirement, but a strong preference. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
No New DB Field Requirement? (WAS: RE: Questions about IIW Identifier Recycling Table)
I'm confused as to why a RP having to not create a new DB field is a requirement when looking to solve this problem. RP's implementations already need to change to upgrade from 1.1 to 2.0 and this has never been a requirement in the past. It certainly is nice that storage changes wouldn't be needed, but I don't see it as something that should be a requirement. Can someone shed some light on this for me? Thanks, --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Thursday, June 07, 2007 5:03 PM To: [EMAIL PROTECTED] Cc: specs@openid.net Subject: Re: Questions about IIW Identifier Recycling Table On 6/7/07, David Fuelling [EMAIL PROTECTED] wrote: Over the last few days I've been thinking about your Identifier Recycling proposal[2], in addition to other proposals (Tokens, etc). Assuming I understand things correctly, it seems as if a hybrid of the public/private token approach would seem to garner the most checks, per the IIW grid. Not sure if my idea is technically correct or not, so please let me know if what I'm proposing falls short anywhere. Here goes I'm not sure I understand what's public about this. If I understand it correctly, from the relying party's perspective, the user's account is keyed off of the pair of the identifier and the token. This sounds like URL + private token in that table. Am I missing something? This approach was rejected at IIW because: 1. An extra database field is required (whether or not the data is transmitted using attribute exchange) 2. There is no obvious way to tell if a user is the same user across sites (The identifier contains a secret portion) 3. Concern about depending on a secret for a user to be able to sign in to a site (David's Wordpress issue) I'm not sure which of these issues were the basis for rejecting this approach. To me, the biggest problem with it is (2) Josh ___ 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: No New DB Field Requirement? (WAS: RE: Questions about IIW Identifier Recycling Table)
On 8-Jun-07, at 10:02 AM, Recordon, David wrote: I'm confused as to why a RP having to not create a new DB field is a requirement when looking to solve this problem. RP's implementations already need to change to upgrade from 1.1 to 2.0 and this has never been a requirement in the past. It certainly is nice that storage changes wouldn't be needed, but I don't see it as something that should be a requirement. My feeling was that, all other things being equal, some bits of code (stripping the fragment for display purposes) which ideally would go into the library, were preferred to requiring a schema change (to store the separate token) for the RPs. Not a requirement, but a strong preference. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Questions about IIW Identifier Recycling Table
The difference I see is that the current secrets can be renegotiated. If we're working with non-public fragments then they cannot be. If we're working with public fragments, then I'm less concerned. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Friday, June 08, 2007 10:29 AM To: [EMAIL PROTECTED] Cc: specs@openid.net Subject: Re: Questions about IIW Identifier Recycling Table On 6/7/07, David Fuelling [EMAIL PROTECTED] wrote: If the token is publically viewable, then losing it is not an issue. I do not share David's concern about depending on a secret, since both the relying party and the provider already need to store secrets. Josh ___ 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: Questions about IIW Identifier Recycling Table
On 6/8/07, Recordon, David [EMAIL PROTECTED] wrote: The difference I see is that the current secrets can be renegotiated. If we're working with non-public fragments then they cannot be. If we're working with public fragments, then I'm less concerned. I understand your concern, but I don't share it. There will be times that secrets are lost, but I think that the benefit of protecting users from identifier loss is more important than the cost of requiring a reliable provider. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Questions about IIW Identifier Recycling Table
On 6/7/07, David Fuelling [EMAIL PROTECTED] wrote: I'm not sure I understand what's public about this. If I understand it correctly, from the relying party's perspective, the user's account is keyed off of the pair of the identifier and the token. This sounds like URL + private token in that table. Am I missing something? Maybe I don't understand the difference between private and public tokens. My proposal used private information to create a public token that can be sent via AX (thus the hybrid term). Am I understanding the difference between private/public tokens incorrectly? I think I see how we're using the term differently. The token only protects your identifier if the relying party does not ever display it. If the relying party did display it, anyone who gained control of your identifier in the future could just send that (reusable) token along with an assertion in order to gain access to a relying party. Since the relying party needs to keep the token secret, I was calling it private. It's shared between the provider, the user, and the relying party, but it's secret from anyone else. I think it's also important to note that the transport mechanism for the token (using attribute exchange, as an extra field or as a fragment) is independent from whether the token should be shared. I think using attribute exchange for this core feature is a non-starter, since it would create a dependency on the attribute exchange in the authentication spec. This approach was rejected at IIW because: 1. An extra database field is required (whether or not the data is transmitted using attribute exchange) If the AX database schema is architected properly, then the addition of a new AX attribute should not necessitate a new database column. If this were the case, then AX would not really be feasible (how would an RP deal with a new AX attribute?). If you have an existing application and you are adding OpenID support, in order to support the token, you would have to alter your schema. When creating a new application, it's not a big deal. I also expect that few relying parties will support *arbitrary* attributes, since the relying party will not be asking for attributes that do not have specialized uses anyway. Perhaps this deserves clarification on the wiki page. 2. There is no obvious way to tell if a user is the same user across sites (The identifier contains a secret portion) Good point. Although, let's assume that RP's display fragment-enabled OpenID's in the following manner, which overcomes the Fragments are Ugly problem: a href= http://me.example.com#1234;http://me.example.com/a Users will not be able to easily distinguish that the OpenID is owned by a different user without hovering over the URL in their browser. That said, computers will be able to, since the actual HREF is what counts, I assume. Has this been discussed wrt to fragments. There has been some discussion about it. It's a tough issue, and it's one of the reasons that I asked the (surprisingly controversial) question about whether we can just add the token to some part of the URL, if it's going to be publicly available anyway. If it's a visible part of the URL, both users and software agents will be able to tell the difference between identifiers. In the discussions that we have had about this issue so far, we have concentrated on a user gaining access (either on purpose or accidentally) to resources that were controlled by the previous owner of their identifier. For example, a user could sign in to a photo sharing site and see someone else's photos. A related issue is that of a third party mistaking resources controlled by the previous owner of a URL as being controlled by the current owner. For example, a potential employer does a search for the user's identifier and finds photos of some illegal activity, without the uniquifying token as a visible part of the URL. 3. Concern about depending on a secret for a user to be able to sign in to a site (David's Wordpress issue) I think DR had a problem with anything that could be lost, thereby preventing access to an RP. Both Fragments and Tokens seem to suffer from this problem, since in the Fragment scheme, if I or my OP forgets what my fragment was, I won't be able to login to an RP without recycling my account (or forcing an account recovery procedure). Seems like the odds of my OP losing my fragment information are pretty slim. Identically, the odds of my OP losing my recycling_password are pretty slim, too. What's more, If *I* lose my recycling password, why should I care? Only the OP needs to deal with it, and perhaps the OP can just show me that password in an account settings page when I login(?) If the token is publically viewable, then losing it is not an issue. I do not share David's concern about depending on a secret, since both the relying party and the provider already need to store secrets. I think
Re: Questions about IIW Identifier Recycling Table
Hi David, The idea was to list as columns the things potentially affected by this change and important enough that we cared. In the end we chose 'URL + public fragment' as the one with the most check marks. See below my comments; maybe others can correct / fill in the gaps. On 5-Jun-07, at 1:36 PM, David Fuelling wrote: I wasn't at IIW, so please bear with me. In reference to the wiki at http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling, can somebody clarify what some of the terminology means? Specific questions are below. 1.) For URL+Fragment, what is the distinction between private and public? 2.) Ditto For URL+Token (I assume this means a public vs. private token?) Public: the RP presents the full identifier (fragment included) to third parties. Private: the reverse of the above. Not sure if this also covered the case (mentioned the day before the meeting) of the OP generating custom fragments for each RP. 3.) What does DE mean in the Does not require change to DE? Delegation. Corrected the wiki. 4.) In the Stolen OP account header, it appears that all 4 of the proposed methods have problems. However do we really want an identifier to be recycled if an account is stolen ( i.e., what if an account is only stolen for a brief period, but then recovered?) Rather, neither of the for proposed methods help you if your OP account is stolen, so this column doesn't make a difference. 4.) What is Active Recycling? Not 100% here, but I believe the user / OP can choose when to recycle an identifier. 5.) In the New DB Field header, doesn't an OP/RP need a new DB field in the fragment scheme, in order to distinguish between the id and the current fragment? Or does the OP/RP simply store the whole URL (fragment included) and parse as necessary? Corrected this one to One identifier / New DB field as it shows in my picture. The RP can dynamically strip the fragment when it needs to display the identifier, and keep it in full (including the fragment) for the rest of the cases. 6a.) What is MO in MO Strip Fragment? 6b.) What does the MO Strip Fragment header mean in general? No strip fragment == there is no extra work required for stripping the fragment. This is kind of a mirror of the previous column (one identifier), but dynamically stripping the fragment was considered better than requiring a new DB field for the tokens (so this mirrored column pair was regarded slightly in favor of fragments vs tokens). The lost domain shows as lost domain when owning OP in my picture. This was considered less important (and smaller in size on the whiteboard). I also don't remember why private fragments/tokens don't help here, or why the public token does. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Questions about IIW Identifier Recycling Table
Hey Johnny, Thanks for your clarifications and answers to my questions about [1]. Over the last few days I've been thinking about your Identifier Recycling proposal[2], in addition to other proposals (Tokens, etc). Assuming I understand things correctly, it seems as if a hybrid of the public/private token approach would seem to garner the most checks, per the IIW grid. Not sure if my idea is technically correct or not, so please let me know if what I'm proposing falls short anywhere. Here goes To make Identifier Recycling Happen: 1.) The OP should send the RP a Unique hash value as an attribute in AttributeExchange. This unique value should be the hash of : + nonce + op_secret_password + user_supplied_secret_password + rp_url. For example, SHA256[1393k3k3939k + op_recycling_password + my_recycling_password + http://example.com; ]. In this scheme, each RP will receive (via Attribute Exchange) a one-way hashed value that is unique to the OP/RP/OpenId/User combination. This value cannot be forged so long as the recycling passwords for the OP and User are not compromised. (Note that the user's recycling password should probably be different from the actual login password). 2.) When an account should be recycled, the OP should force the new user to supply a new recycling password, which will change the hash received by a given RP. This is the signal to the RP to use a different/new account on the RP side, despite having seen the OpenId before. 3.) This scheme would also protect against an OP domain expiring, and getting picked up by a malicious new owner. In this case, the OP recycling password will not be known/valid, and the the new domain owner won't be able to make auth assertions for existing RP accounts that were served by the previous OP owner. 4.) To protect legitimate users from lost recycling passwords, an account recovery mechanism will need to be in place at a given RP, so that if the RP thinks the account should be recycled, the end-user has a way to prevent this (perhaps via email, SMS message, or some other mechanism). This is a problem anyway with the other approaches. In the end, this approach seems to receive a Check under all of the headers on the IIW grid Does not require change to delegation == Check Lost Domain when owning OP == Check Active Recycling == Check Consistent 1.1 == Check (Assuming 1.1 OP/RP's can use AX -- is that true?) One identifier / New DB Field == Check (all data is stored in the AX mechanism). No Strip Fragment == Check Fragments Can be used by other mechanisms (FOAF, etc) == Check [1] http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling [2] http://openid.net/pipermail/specs/2007-May/001767.html ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Questions about IIW Identifier Recycling Table
On 6/7/07, David Fuelling [EMAIL PROTECTED] wrote: Over the last few days I've been thinking about your Identifier Recycling proposal[2], in addition to other proposals (Tokens, etc). Assuming I understand things correctly, it seems as if a hybrid of the public/private token approach would seem to garner the most checks, per the IIW grid. Not sure if my idea is technically correct or not, so please let me know if what I'm proposing falls short anywhere. Here goes I'm not sure I understand what's public about this. If I understand it correctly, from the relying party's perspective, the user's account is keyed off of the pair of the identifier and the token. This sounds like URL + private token in that table. Am I missing something? This approach was rejected at IIW because: 1. An extra database field is required (whether or not the data is transmitted using attribute exchange) 2. There is no obvious way to tell if a user is the same user across sites (The identifier contains a secret portion) 3. Concern about depending on a secret for a user to be able to sign in to a site (David's Wordpress issue) I'm not sure which of these issues were the basis for rejecting this approach. To me, the biggest problem with it is (2) Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Questions about IIW Identifier Recycling Table
Hey Josh, Thanks for your message and great points. See my thoughts/questions inline. On 6/7/07, Josh Hoyt [EMAIL PROTECTED] wrote: On 6/7/07, David Fuelling [EMAIL PROTECTED] wrote: Over the last few days I've been thinking about your Identifier Recycling proposal[2], in addition to other proposals (Tokens, etc). Assuming I understand things correctly, it seems as if a hybrid of the public/private token approach would seem to garner the most checks, per the IIW grid. Not sure if my idea is technically correct or not, so please let me know if what I'm proposing falls short anywhere. Here goes I'm not sure I understand what's public about this. If I understand it correctly, from the relying party's perspective, the user's account is keyed off of the pair of the identifier and the token. This sounds like URL + private token in that table. Am I missing something? Maybe I don't understand the difference between private and public tokens. My proposal used private information to create a public token that can be sent via AX (thus the hybrid term). Am I understanding the difference between private/public tokens incorrectly? This approach was rejected at IIW because: 1. An extra database field is required (whether or not the data is transmitted using attribute exchange) If the AX database schema is architected properly, then the addition of a new AX attribute should not necessitate a new database column. If this were the case, then AX would not really be feasible (how would an RP deal with a new AX attribute?). 2. There is no obvious way to tell if a user is the same user across sites (The identifier contains a secret portion) Good point. Although, let's assume that RP's display fragment-enabled OpenID's in the following manner, which overcomes the Fragments are Ugly problem: a href= http://me.example.com#1234;http://me.example.com/a Users will not be able to easily distinguish that the OpenID is owned by a different user without hovering over the URL in their browser. That said, computers will be able to, since the actual HREF is what counts, I assume. Has this been discussed wrt to fragments. 3. Concern about depending on a secret for a user to be able to sign in to a site (David's Wordpress issue) I think DR had a problem with anything that could be lost, thereby preventing access to an RP. Both Fragments and Tokens seem to suffer from this problem, since in the Fragment scheme, if I or my OP forgets what my fragment was, I won't be able to login to an RP without recycling my account (or forcing an account recovery procedure). Seems like the odds of my OP losing my fragment information are pretty slim. Identically, the odds of my OP losing my recycling_password are pretty slim, too. What's more, If *I* lose my recycling password, why should I care? Only the OP needs to deal with it, and perhaps the OP can just show me that password in an account settings page when I login(?) I'm not sure which of these issues were the basis for rejecting this approach. To me, the biggest problem with it is (2) I agree that #2 is a problem with the token approach. However, the fragment approach doesn't solve the problem of a new OP domain owner being able to make auth assertions for OpenID's that were created for a previous owner (See my proposal #3). This seems to be an edge case, but its effects are much more devastating than people not being able to visually (or otherwise) determine who owns a given OpenID. Maybe the solution is use both approaches at the same time? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Questions about IIW Identifier Recycling Table
I wasn't at IIW, so please bear with me. In reference to the wiki at http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling, can somebody clarify what some of the terminology means? Specific questions are below. 1.) For URL+Fragment, what is the distinction between private and public? 2.) Ditto For URL+Token (I assume this means a public vs. private token?) 3.) What does DE mean in the Does not require change to DE? 4.) In the Stolen OP account header, it appears that all 4 of the proposed methods have problems. However do we really want an identifier to be recycled if an account is stolen ( i.e., what if an account is only stolen for a brief period, but then recovered?) 4.) What is Active Recycling? 5.) In the New DB Field header, doesn't an OP/RP need a new DB field in the fragment scheme, in order to distinguish between the id and the current fragment? Or does the OP/RP simply store the whole URL (fragment included) and parse as necessary? 6a.) What is MO in MO Strip Fragment? 6b.) What does the MO Strip Fragment header mean in general? Thanks! David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
