No New DB Field Requirement? (WAS: RE: Questions about IIW Identifier Recycling Table)

[Recordon, David]

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:johnny at sxip.com] 
Sent: Friday, June 08, 2007 10:15 AM
To: Recordon, David
Cc: specs at 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