Santosh, John - I agree with the logic of Santosh's proposal however. A timestamp is sufficient, and it's also necessary when you want to correlate against other real world evidence (timestamps on authored documents, dns registry dates, timestamped log entries). I'm not sure what's gained by making it more general - is it precisely to avoid unwanted correlation?
Also, since you only need to store one record at a time for an openid in a user Db, I don't think this needs to be part of the primary key - just a field that's checked against. Though personally I'd add a timestamp to my primary key indicating the local account creation date. Which brings me back to point #1 :). On Wednesday, December 2, 2009, John Bradley <[email protected]> wrote: > Moving to Specs. > Santosh, > This is currently supported in openId 2.0 by the fragment portion of the > claimed_id. > The spec doesn't specify the format of the fragment, so it could be a account > creation date. > This is the current method the large OP's are using to support identifier > recycling.Some recycle thousands of IDs per day. > That is one reason why some of the large OPs don't support openID 1.1 as > there is no identifier recycling support in 1.1. > I have found RPs (some large) who are not storing the fragment as part of > there primary key because they want to use the claimed_id for display. That > is a bad idea. > Making the OP responsible for account recycling via the positive assertion > works OK for the large OP. > It doesn't work for delegation. > Ideally v.Next would also support a way for the user to prevent someone else > from taking over your claimed_id if you loose control of your domain etc. > This is related to the question of claimed_id portability between OP. > RegardsJohn B.On 2009-12-02, at 1:32 AM, Santosh Rajan wrote: > I would like to first of all, apologies to all members of the community, for > having made comments that has caused distress on this list. My apologies to > all members. > > I am not aware if the idea of using account creation dates to preempt > recycleable identifiers has been considered before, and i thought it might be > a cheap way to preempt the problem, and worth looking into. > > All accounts have a logical creation date, a time stamp that in combination > with an account identifier will be universally unique. I think all providers > save this time stamp (or atleast the creation date) when the account is > created. Let us call this timestamp the "account timestamp". This timestamp > does not change through the life cycle of the identifier, and only changes > when a new account is created with the same identifier (recycled). > > 1) All OP's can return the account timestamp as an extra parameter with every > authentication response.2) Every time a user logs in at an RP, the RP can > verify that the timestamp has not changed. > 3) If the timestamp has changed, it means that this a recycled identifier, > and this is a new user. > > > -- > http://hi.im/santosh > > > > _______________________________________________ > general mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-general > > -- -- John Panzer / Google [email protected] / abstractioneer.org / @jpanzer _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
