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