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

John Panzer jpanzer at google.com
Wed Dec 2 19:21:16 UTC 2009


John- I can't tell if your profile path ID is an opaque Google-generated
string or a GMail namespace readable identifier :)

+Breno.  Not sure what the plan is here myself.

--
John Panzer / Google
jpanzer at google.com / abstractioneer.org / @jpanzer



On Wed, Dec 2, 2009 at 10:41 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> 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/6b507202/attachment.htm>


More information about the specs mailing list