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: firstname.lastname@example.org 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 email@example.com http://openid.net/mailman/listinfo/specs