[OpenID] Using Account Creation Date to preempt recycleable OpenID's in v.next

John Bradley ve7jtb at ve7jtb.com
Wed Dec 2 18:41:20 UTC 2009


Interesting,

I just tried my google contact page:
openid.claimed_id: http://www.google.com/profiles/ve7jtb
	openid.identity: http://www.google.com/profiles/ve7jtb
It is not supporting the existing method of identifier recycling via fragments.   
That wasn't required for the PPID type identifiers because of the way they were constructed from teh account information.

It is just my opinion, but I suspect google is creating a huge problem for itself if those pages are ever going to be recycled.

Is adding a account creation date parameter and revising the protocol seen as a way out of this problem?

They should have used generational fragments from the start.

John B.

On 2009-12-02, at 2:48 PM, John Panzer wrote:

> On Wed, Dec 2, 2009 at 7:47 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
> Hi John,
> 
> I thought and I might be wrong that Santosh was recommending sending a timestamp of the account creation at the OP as a way to detect account recycling.
> 
> It sounds like you are looking for a timestamp of the transaction.
> 
> That is contained in the Nonce if it is properly formatted and you want to store all or part of it at the RP.
> 
> 
> Not quite.   What I want to know is "when was this particular identifier last recycled?" (which in usually comes down to "when was this identifier last registered with this OP ", though delegation messes with that).
> 
> Why I want to know this:  Because I can store the value, and if it changes, I know that I'm dealing with a re-created account even if I didn't see a notification about an account deletion.  This is extremely useful to me as an RP because I can then take measures to protect private data because the person at the terminal is no longer the same as they were before.
> 
> Note that this also lets me see if an identifier is travelling backwards in time, which would indicate either an impersonation or an account recovery from an impersonation, both of which are very useful things to know about.  Fragments don't help at all there.
> 
> The Nonce doesn't help me as an RP here.
> 
>  
> The original discussion on account recycling had two proposals one using the CID from the XRDS and another I think from Yahoo (I may be wrong about that) with the current OP derived fragment.
> 
> I am guessing that the OP account creation date might be considered private or sensitive information.
> That is probably why they left it up to the OP to determine the format.
> 
> That's what I guessed.  I think perhaps this could be mitigated with fuzzing -- don't recycle an identifier more than once per year, and only give out timestamps on year boundaries or something similar.  And not having this info still leaves us vulnerable to incorrect correlations (e.g., thinking that someone said something on a mailing list a year ago because the archives don't store the fragment with the author's name).
>  
> 
> I can certainly see making the account creation date available via AX.   However making it optional won't work in the role of detecting account recycling if the new user doesn't disclose the attribute.
> 
> This was also discussed (I believe proposed by Breno) in the context of reputation of an identifier.  
>  
> 
> Requiring an attribute like that to be part of the base authentication protocol is probably not ideal.
> 
> I know that many RP's don't like having to strip the fragment from the claimed_id before using it for display.
> 
> On the other hand many of the openID's are encrypted string that convey no meaningful information about the user (Google etc).
> 
> True, though that can change (optionally) now that Google Profiles are OpenIDs.
>  
> 
> We need to look at the larger picture regarding what RP's are storing as identifiers.
> 
> 
> Agreed.  
> 
>  
> John B.
> On 2009-12-02, at 12:20 PM, John Panzer wrote:
> 
> > 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 <ve7jtb at ve7jtb.com> 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
> >> general at lists.openid.net
> >> http://lists.openid.net/mailman/listinfo/openid-general
> >>
> >>
> >
> > --
> > --
> > John Panzer / Google
> > jpanzer at google.com / abstractioneer.org / @jpanzer
> 
> 
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20091202/c22a04ef/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2468 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20091202/c22a04ef/attachment-0001.bin>


More information about the specs mailing list